Lately I’ve been thinking about what makes quality software code. A bunch of things popped into my head. Use more patterns, better abstraction, better separation of concerns, etc. But somehow I wasn’t satisfied with them, because each of these ideas or a combination of them does not necessarily make for quality code. I?m looking for something deeper, a principle, to guide its use. Even before scrounging around for a principle or two (if possible), there needs to be a clear understanding of what quality is. I turned to “The Timeless Way of Building,” written by Christopher Alexander, for guidance. He coined the phrase “quality without name.” It’s without name because it’s hard to describe and even harder to create, but if we are in the presence of it, we know. An effort to explore and try to understand this quality is hard but not impossible.
If we know quality, then why is it so hard to describe? Because we all perceive it differently. For example, my girlfriend and I went to an open house. We walked in; we knew it was a quality house. What she noticed was the wood floor. I noticed that the floor did not squeak and that they had used rich materials. The real estate agent boasted about the built-in sound system and other gadgets. So, three people have three ways to describe why this is a quality house. In software, there are as many ways to describe what quality is as there are bugs in it.
When there are many ways to describe ?quality,? the word loses its meaning. Rather than trying to describe or name quality using external perceptions, we should instead examine our internal perceptions of quality. How do we know we are in the presence of quality? Simply put, we feel it. We are attracted to it and it is uplifting. These are the true unifying points that make the word ?quality? regain its power.
For the next blog, I will explore how placement of code, objects, and group of objects affects quality.