A good design is one that does not suck.

-- Anonymous

A good design is one that can be easily understood, easily modified, everything is said OnceAndOnlyOnce, and does exactly what is needed and nothing more.

-- GuillermoSchwarz

Good design is when there is nothing left that can be taken away.

''And at the same time, the system does everything that is needed. See KeepItSimple. Compare this with PluggableArchitecture.'' -- GuillermoSchwarz

''- Do we need to state that? If the system doesn't do everything that is needed, you obviously took away too much.'' -- AnonymousDonor

----

This reminds me of something said about writing, that you know you're done when there are no more words you can get rid of. Is this another example of WritingProgramsIsWriting?

In this respect, software design is like any creative endeavor. Very seldom do you sit down to work and just have inspiration strike, and when that does happen it's because you're drawing on experience. To create anything well, first you have to organize your thoughts, then you have to work it and rework it until it comes out a work of art.

There are things that can interfere with good design:

* Writing without rewriting. (Compare RefactorMercilessly and IterativeDevelopment.) When you write a paper, you start with a first draft and then go back and rewrite and rewrite again. Many writers continually rewrite while they're writing, to keep it clean and keep their thoughts organized. In either case, it's the only way a writer will get his work published. Programmers are the only ones who regularly get to publish messy work. The end result is that you can't tell how the design works unless you already know.

* Trying to swallow too big a piece. (Compare DoSimpleThings.) I once fell into this trap myself. Many years ago, I spent a lot of time designing a framework for self-diagnostic applications. The thought process was valuable, and so was the introduction to the document I produced. But it was a BigDesignUpFront, and most of what I wrote was useless. It wasn't until I sat down and started designing and implementing a real system that the framework came together. (I finally was able to complete it.)

* A related issue: Obtuse code. (Compare SelfDocumentingCode.) Not exactly bad design. (Or do the artistic merits of our work count as "design?") I worked with a software engineer who seemed to hate any variable or function name longer than 4 characters. He was brilliant, boiled complicated problems down to simple sequences, used basic algorithms in powerful ways, like tiny bullets propelled at great speeds. His code was concise, graceful, awe-inspiring, like a great work of literature, written in ancient Sumerian. It was awe-inspiring only after you figured out how to read it.

-- TimKing

----

There are two ways to do a design:

	1 So simple that there are obviously no deficiencies.

	1 So complex that there are no obvious deficiencies.

-- CarHoare

See TwoWaysToDesign. I read number 1 as follows: A good design is simple enough so that you can always see why you took a DesignDecision. You can always trace back a DesignDecision to a requirement, therefore if the requirement changes, you can always undo that DesignDecision and the design is kept clean and simple (or LeanAndMean). -- GuillermoSchwarz

----

See: GoodDesign, GreatDesign, DynamicClassification, BigReductionUpFront .