Don Lancaster has a great article on Elegant Simplicity in engineering: http://www.tinaja.com/glib/elesimp.pdf
He argues that ElegantSimplicity
is discovered, not created, and gives many examples.
The topic of "Elegant Simplicity" was raised on the XP mailing list by John Carter, who claimed that it is objective and that experienced people agree on what is elegantly simple, though not on why. SimpleDesign
is one of the rules of XP, though XP does not require elegant simplicity.
People often confuse simplicity and the QualityWithoutaName
. The QualityWithoutaName
is about life, and life is not simple. ChristopherAlexander
says that the QualityWithoutaName
is also objective. Both ElegantSimplicity
and the QualityWithoutaName
are good. The QualityWithoutaName
is generated, while ElegantSimplicity
is is discovered. They are similar in some ways, but not the same.
Lancaster says that elegant simplicity comes when you have removed everything that you can. John Carter said that it is easier to tell why something doesn't have it than to say why it does. ChristopherAlexander
says something similar about good design. It is easy to tell a bad design, because something about it doesn't fit right. A bad design will have many things that fit right, but people focus on the defects. A good design is one with no defects, everything fits right. It is hard to say why it is so good -- it is just that there is nothing wrong with it.
If the QualityWithoutaName
is a life quality, and ElegantSimplicity
is something different, then I have a hard time understanding why the former is created
and the latter is discovered
. If I were to set out to make one of each, I have more confidence in making ElegantSimplicity
than something life-like, but I could be wrong.
My real question falls out of the comparison of these two species of things. Is there any such thing as creation, or is that the name we give to things made by a very complex web of discovery and selection that may be only partially conscious? Is there any such thing as raw, generative intelligence? Can we really tell the difference between discarding bad ideas early and never having them in the first place? -- WaldenMathews
The above description of good design reminds me of an old joke:
- Q: How do you make a statue of an elephant?
- A: Start with a big block of marble, and chip away everything that doesn't look like an elephant.
- How do you make a good design? Start with a bad design, and fix all the defects.
Maybe this sounds like I'm trying to trivialize the comments above, but I'm not. Actually, I agree: there is no recipe for making a good design, but you can always identify something that's wrong with a bad design and fix it, thereby making it better.
One of the less rewarding aspects of creating an elegantly simple design is that it makes the problem look easy - anybody else examining your solution is apt to conclude that there was nothing very hard in the first place. If they don't, it probably wasn't simple enough ...
From the Scheme 48 user guide (http://www-swiss.ai.mit.edu/~jar/s48-user-guide.txt
The name derives from our desire to have an implementation that is simple and lucid enough that it looks as if it were written in just 48 hours. We don't claim to have reached that stage yet; much more simplification is necessary.
Hmm. That's not what it says now (on s48.org):
The name `Scheme 48' commemorates our having written the original version in forty-eight hours, on August 6th and 7th, 1986.
Old writer's adage: You aren't done editing until you're left with a blank page.
Chip away everything that doesn't look like David.
See also: PerfectionIsAchieved
Hmm. I'm certain this has been addressed elsewhere on this Wiki, but can someone elaborate the above concept as applied to client demands for feature-rich applications? It seems that users want more and more instead of less. What do we provide, and how?
If everything is free, why not ask for the world?
Clients have "clientic license", i.e., the license to ask for inelegance and to revel in it when they get it. But you, as a designer, signed on for a more difficult lot. You have to make the watch work with only half its original parts. On the outside, it may be feature rich, but look inside and you'll find only one lever.
Alternatively, teach the receptive client to perform ten different tasks with the same simple tool, and discard all the rest. You can visualize it, but you risk gross misunderstanding in this undertaking.
It's possible to boil solutions to such a thick essence that they become too dense for anyone who wasn't there for the whole boiling. Elegant simplicity stops somewhere short of this unseemly end. Simplicity and density (Alexandrian density) go hand-in-hand. Fewer parts, more roles and relations. Smaller but also more ambiguous. When ambiguity is just right, it's done.
See also: AnticlimacticSimplicity