When we talk about quality we may think of a fine piece of furniture or the quality service we receive at a fancy restaurant but what does quality mean in the context of software? I find that when we talk about the domain of ideas, and software is in the domain of ideas, that we often use metaphors which are based upon the physical world and are not always accurate.
In the physical world the notion of quality has to do with fine craftsmanship and longevity. We talk about quality workmanship and in the physical world quality always comes at a premium.
But quality in software is different. Think about it, we’re talking about things that don’t have any mass. The costs in most businesses are the cost of goods and the cost of production. If we build things, physical things instead of virtual things, then much of our costs would be involved in the acquisition of materials, the creation of our products, and their distribution.
We have none of this and software. Once we build the thing our production and distribution is essentially zero. Of course, that doesn’t mean that our cost of doing business is zero, far from it. The software industry has many other costs that are required of it, such as ongoing support. But in terms of production and distribution, which is often the largest cost in every other industry, in the software industry those costs are negligible.
So how does the notion of quality translate into the world of software? In my experience, true software quality is about achieving the same ends as physical quality, which is longevity, durability, and fitness of purpose. But these are squishy words and so we really have to understand what makes quality in software. In my experience, the ultimate goal in software development and the thing that we have largely ignored as an industry is to write software that is durable and has longevity. In other words, write software whose cost of ownership is as low as possible.
I say that the cost of ownership for the software we write is of paramount importance because this is where industry spends the most money. It’s been well documented that on average it costs five times more after software is released than it costs to create it in the first place. It costs half as much to fix defects after release and twice as much again to make minor enhancements. As an industry we write software that is expensive to fix and difficult to change.
The five CLEAN code qualities that I’ll discuss over the next seven blog posts reflect things that we can see and understand in our code. We can see when they are lacking or when they are present in code. I find this much more helpful than the so-called quality factors. I like to call them the “-ibles.” For example, reliable. If I tell you that your code needs to be reliable I haven’t helped you very much because I haven’t told you how to do what I’ve told you to do. The CLEAN code qualities our actionable. I call them qualities but they are actually quantitative because we can see them in our code and we can know what to do to improve them.
In my next blog post, I’ll discuss some quality practices that we can do to improve the CLEAN code qualities.
See you next time.
Note: This blog post is based on a section from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
Previous Post: « Why Practice 5: Create CLEAN Code
Next Post: Share Common Quality Practices »