On Quality Code: Less is More

August 3, 2007

This morning Signal vs. Noise linked to a post by Paul Stovell called We are what we repeatedly code:

The best developers I know write great quality code every time they touch an IDE. This is because they realize that writing good code is something you have to practice, something that you have to do over and over again to be able to do right. They realize that writing great code is something you do all of the time, not something you save for a party trick.

I agree with him on this. But what exactly is “quality code”? Paul uses an example of a small, throw-away tool he wrote recently:

I could have written the tool as one huge Main method in a console application. Yet, instead, it’s all nicely factored. There are base classes, adapters to reduce the dependencies on the outside systems, encapsulation, interfaces, a couple of occurrences of the strategy pattern, and even the odd XML-doc comment thrown in here and there. Hell, I even gave the DLL a fully qualified company namespace.

I get what he means: write every piece of code as if it will ship. But I can’t agree with any definition of quality that is measured by the amount of design patterns you use. All the things he described — encapsulation, interfaces, design patterns — are all well and good when used appropriately, but their abundance, or even mere presence, does not indicate quality code, any more than the presence of salt and pepper indicates a good soup.

I’m reminded of my first co-op term at IBM on the SWT team. Steve Northover, the SWT technical lead, has a couple of golden rules. One of them is “that which obscures my code is bad”. Encapsulation, interfaces, the adapter pattern, the strategy pattern…all ways of solving specific problems, but also ways of obscuring your code. So many people seem to believe that adding more structure will produce better results. We see a similar pattern in government (endless bureaucracy), education (standardized testing), and business (meetings, reports, yearly reviews, middle management). These things begin with the best of intents, but often end up causing more harm than good.

In software development, there’s a growing movement of people who believe that “less is more.”