If ever there was a convoluted, misunderstood term in software development, it’s the word “quality.” To some people, quality in software is software that does the right thing. Others say it’s software that’s free of defects. Still others say quality software is software that runs fast. All these things are good but they’re not necessarily the cause of quality but rather the effect of it.
The great Gerald Weinberg, for whom I have deep respect, says “Quality is value to some person.” With all due respect, “value” is value to some person. Quality and value are related but I don’t think they’re the same thing.
Let’s start by looking at what quality is in the non-software world. It’s often easier to visualize things in the physical world and then we can see if our insights apply to the virtual world. So what is quality in the non-software world?
In the physical world, quality has to do with longevity and durability. We are willing to pay a premium for products that are built to last and are a better fit for a purpose. We pay more for a Lexus than a Yugo and generally speaking, the quality of a Lexus makes for a better driving experience and a car that should last longer than a Yugo.
In service, we also have the notion of quality, like at a fine restaurant. We say we’ve receive quality service when our wants and needs are addressed as they happen. Quality services is about seeing from the customer’s perspective and addressing their needs.
Conceptually, quality in software isn’t that much different. The goals are similar, increase the longevity of the product and address the wants and needs of users as they happen. However, the way in which we address these things are different in software. There are no physical materials in software so quality has to come from a different source than in physical goods. In fact, quality in software is conceptually more similar to quality in service than quality in goods.
Why do we consider the service at one meal to be higher quality than another? I think the key here is that quality service takes the customer’s perspective. This is also an important element of quality in software.
In software, I generally think about quality on two levels: does the software do the right thing and does the software do the thing right. Doing the right thing is doing what the user wants. We find out by asking the user. This is why Agile provides many opportunities for feedback so the team can determine of they are on track as they’re building a system.
Doing the thing right is about building software that’s maintainable and extendable. This is an absolutely critical part of quality that is far too often overlooked, the extendability of software.
Software quality has to do with understanding but not just the needs of our customers. We also must understand the nature of software and the nature of change so we can design solutions that won’t be obsolete as the needs of the user change.
I’ve learned from experience that if software is used then it will need to be changed, users find better ways of using our software, and so software must be written to be changeable in order to drop the cost of ownership and extend the lifetime of the code we write. Following good design principles and practices are core to writing changeable code that ultimately costs less to maintain and extend. And that is one of the central goals of Agile software development.
