Good Design

I searched the Wiki for a basic principles of "good design" and didn't find it. (There's GreatDesign, but I'm just looking for "good," or even "good enough.") With a level of hubris that risks unleashing the wrath of the gods, I now present mine. There's one saving grace: nothing here is terribly original, nor should it be. -- JimShore (signing my name up here rather than down below, so people will modify what's below)


Before we define the characteristics of good design, we have to be clear on what a good design is. This question alone could tie up a committee for years, so no attempt to come up with an answer that pleases everyone; just an answer.

This implies a few things. The following is unapologetic in its belief that TheSourceCodeIsTheDesign... or, at least, the design is in the source code. There's also an implied belief that context matters; a design that's good for one team isn't necessarily good for another.

Here are the thoroughly-disclaimered implications.

The characteristics above are ideals. Real-world designs aren't likely to achieve them. But better designs come closer. Good designs come close enough that the software is easy to maintain. To determine the quality of the design, observe it being maintained. Experienced designers will have opinions on the quality of the design but it's all speculation until the rubber meets the road.

There are some common approaches for achieving a good design:


We Are All Students of Change

The biggest problem agreeing on GoodDesign is estimating future change patterns. Almost every design makes assumptions and trade-offs with regard to handling future changes with the least amount of pain. Time is often the only way to test if a design weathers changes better. Prior experience can give us some some guidelines, but I find that different people have been burned in different proportions in different things. So, they tend to focus on some change patterns more in some areas and less in other areas than I would, based on my experience. Person X may have been chewed out for a problem handling change type A in the past, but person Y chewed out about change type B. These experiences shape our probability and cost estimates for various changes. Not that this is "bad", for there is no alternative because we each only live one lifetime. -- top


Counterpoint

I think the above list of one misses the most important aspect of GoodDesign: The software has to work. It has to solve the problem it was designed to solve or accomplish the task it was designed to accomplish. If the software doesn't work, it doesn't matter how maintainable it is, nor how elegant its design, nor how spectacular its performance. Conversely, the real world is chock-full of terrible, ugly, "expensive" and completely revolting programs that, nevertheless, solve the problem they set out to solve better than anything before or after.


See GreatDesign, GoodArchitecture, PropertiesOfGoodLanguages, LevelsOfSoftwareSuccess

EditText of this page (last edited February 16, 2014) or FindPage with title or text search