What is Quality?

Quality is value to some person.

I would like to show how to apply this often-cited quote from Jerry Weinberg in order to distinguish whether or not to code beautifully (or elegantly) or build a mess. In order to start I will distinguish between externally perceived quality of your software and internal structural quality of the code.

The externally quality of your software is the factor how the end user perceives your software. Bulky user interfaces with complicated workflows can be valueable to someone, most prefer easy to use user interfaces with easy to learn or even intuitive workflows. Therefore your end user will not care much about how beautifully you coded your application using test-driven development or not, using latest design patterns or not, refactoring as you went to ship it. Isn’t it?

No, it is not. Here again it depends on the context of your software and it’s use and the situations your users want to use it. If the business model has a high coupling to laws like tax systems and these laws changes, it actually may be the case that a product of high quality today becomes a mess tomorrow, since I have to recalculate the taxes myself using a calculator. Since quality is timely value to some person quality may disappear if it is not maintained.

Here comes internal quality into play. If you have built a mess with your code, you make yourself unable to react to market or law situations. Ward Cunningham, Martin Fowler and others called this concept Technical Debt. Sure, it might be that you can overcome this situation with another mess, thereby disabling you for the next adaptation you are going to make. In the end you are running into the situation where your code base can no longer with todays needs, since you brought in flaws in yesterday urgency.

Alistair Cockburn came up with a two-phased approach to describe this situation: The Cooperative Game. The initial goal of the game is to deliver working software. This related to the external quality of your software as it is perceived by the customers today. The second goal of a cooperative game in software development is to adapt the system to tomorrows needs. This related highly to the internal structural quality of your code base. No end consumer will take care of this – today – but he will be unhappy to pay for your Technical Debt in terms of later delivery, higher costs tomorrow.