Good vs. "good enough" ... pretty much determined upon arbitrary preferences ... which may differ from designer to designer.
No, not arbitrary at all, actually.
Once again, it all depends upon what the purpose is for the design. The purpose might be a demonstration of how something which does not conform to what might be considered "obvious design" can still be functional and successful.
I think I went enough out of my way to explain how good/bad design is NOT evaluated based on functionality of the end product...
But again, ... you are depending upon a human definition of good design,
Human designs, are the only ones we have actual examples off. So it's the only one I can talk about.
... which can be different for every designer/consumer.
Not really. Any software engineer worthy of the name will agree on what is good and bad design of software applications.
Your own point here makes the case that, certainly, it is different for the average end user.
It seems my point went over your head, because one of my points, was that the end product (or consumer) is not the standard against which good/bad design is evaluated.
Having designed software as well, I know that one article of good design ... is to design in such a way that future engineers have the easiest/clearest path to making modifications and/or corrections.
That is indeed one of the parameters, yes.
Note that this parameter is all about the BUILD UP of the code, and NOT of the functionality of the end product! An ugly 1000 line method can have the
exact same output as an elegantly refactored collection of 10-line methods.
In fact.... in some cases, "good design" (according to the best practice rules of coding) might even result in a performance hit!
And again, we come to that point where "good design" and "usability of the end product"
are two different things.
But if it is anticipated that there will be no others working on the coding, that purpose is not as relevant.
False. If there are bugs that you need to fix several months later, you might want to have a clear and neatly design codebase instead of a spaghetti, to find that line where it messes up.
To effectively critique design, one must know ALL of the intended purposes of the design ... or at least, a good measure of the design intent.
Not necessarily.
Take the laryngual nerve. I have NO CLUE what it does. But I DO know that it is
absurd that it goes from the back of the brain, all the way down into the chest, loops around the aorta, only to go back up again to end up 2 inches from where it left.
It doesn't matter what the purpose of the nerve is. The fact is that it needs to go from point A to B and that it takes a ridiculously long detour. This is a waste of resources.
If I'm designing a software patch that is only intended to last until the hotly anticipated next complete software release, it may be foolish to waste resources upon making the design as if it was going to be the next release.
So let's just hope that nothing goes wrong with the patch then.
I agree with an earlier sentiment on the thread that it is difficult for any man/woman to critique a design which has been successful for many times longer than anything designed by any men/women to-date ...
Organisms were designed by the blind process of evolution.