What Quantifies Good Software Design: Quality With a Name

My buddy Jim Shore has produced a very important article that, in my opinion, really moves forward the discussion of what constitutues good software design from an abstract sense to some concrete observable elements. What do I mean by abstract? When I used to hang around Ward's Wiki and the Patterns Community 1996-2001, I used to here the term QWAN a whole lot. QWAN means "Quality Without a Name", and it comes from the influential writings of Christopher Alexander in his book The Timeless Way of Building, which has had profound impact on the Patterns Community. It is supposed to describe good design as "elegant" or "pretty." Some might say it has "Quality Without a Name" (QWAN)--an ineffable (that means "indescribable," kids) sense of rightness in the design. Most of the time it leads to all sorts of metaphysical discussions about Budhism and abstract discussions that don't work for me and left me wanting. There are other issues too, which Jim tackles in his new essay "Quality With a Name," that has the following abstract:

I'm the kind of person that likes logical frameworks and structures. When I think about design, I can't help but wonder: "What's the intellectual basis for design? What does it mean to have a good design?"

That's when I run into a problem. Many discussions of "good" design simply focus on specific techniques. These discussions often have undisclosed assumptions that one particular technology is better than another: that rich object-oriented domain models are obviously good, or that stored procedures are obviously good, or that service-oriented architecture is obviously good.

With so many conflicting points of view about what's "obviously" good, only one thing is clear: "good" isn't obvious.

Other folks describe good design as "elegant" or "pretty." Some might say it has "Quality Without a Name" (QWAN)--an ineffable (that means "indescribable," kids) sense of rightness in the design. The term comes from Christopher Alexander, a building architect whose thoughts on "patterns" formed the inspiration for software's patterns movement.

I have a lot of sympathy for QWAN. I, too, will describe a design as "elegant" or "pretty." In college, I had a professor, Dr. Lum, who liked the phrase "truth and beauty." Good design is Truth And Beauty.

There's just one problem. My QWAN is not your QWAN. My "Truth And Beauty" is your "Falsehood And Defilement." Us software folks seem prone to religious wars, which makes it worse. (Emacs vs. vi, anyone? How about Windows vs. Linux or domain models vs. stored procedures?)

QWAN is just too vague. I want something better.

Thats it in a nutshell. QWAN is just too vague. I want something better too. Jim brings the question to where it belongs: keeping software clean, minimizing the time to create, modify, and maintain it. That's where the cost is, the cost curve that we talk about flattening. So he emerges at a definition that works for me:

"A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance. "

Read the whole thing, especially the attributes of great design:

Great designs:

• Are easily modified by the people who most frequently work within them,
• Easily support unexpected changes,
• Are easy to modify and maintain,
• and Prove their value by becoming steadily easier to modify over years of changes and upgrades.

and

Universal Design Truths

The Source Code is the (Final) Design

Don't Repeat Yourself

Be Cohesive

Decouple

Clarify, Simplify, and Refine.

Fail Fast.

Optimize from Measurements.

Anyway, read the whole thing carefully as it's got a lot of meat and then let's discuss it. What do you think? What came up for you reading it?