Still banging on about Quality

The last couple of blog entires have been a public investigation - personal think - about software quality - see What is Software Quality? and Software quality? Thanks to all those who have provided feedback and comments, they’ve all contributed to my thought process.

I think I am moving towards some kind of conclusion. I’ll write up that conclusion for Xanpan and post it elsewhere too. Right now I’d like to add some more thoughts and hint at the conclusion.

I’m starting to think it is easier to talk about how to achieve high quality and about the benefits of quality than it is to actually define quality itself. Without actually defining what quality is or what the benefits of quality are then talk of how to achieve it is unlikely to be more than opinion.

I think that defining quality is one thing, and we also need to recognise that there may be multiple ways of achieving that end point. I might not agree with all those ways, I might even think that some are misguided but I will recognise that mine is not the only way.

So far my definition of “Software Quality” has focused on two aspects: defects and maintainability (and particularly extendability).

That is a small view, Tom Gilb and Jerry Weinberg’s suggestions are much wider. Tom would - I think - say my two aspects are but two “qualities” among many. For example: speed performance, ease of use and conformance to specification might all be part of quality.

I’m now thinking of quality like an onion. Defects and maintainability are at the core of the onion, and defects is probably the core.

You, your organization, your team, your customers might choose to added additional qualities to this definition which you are quite at liberty to do. For example, this might be your onion:

I believe this model is entirely compatible with Gilb’s concept of quality as qualities and Weinberg’s “Quality is meeting some person’s requirements.” (Thanks to Mark Nilsen for this).
Points here:

• Quality is multifaceted and finding a single definition to satisfy all situations is tough. (Even if we had such a definition it might be too abstract or academic to be meaningful in everyday work.)
• Each organization/team/project/product could benefit from defining what they take to be quality. (And I would suggest that few actually do this and that this resulting difference in individuals opinion on “what is quality” is the cause of much friction and mis-aligned aims.)

Quality is itself a statement of values - not necessarily financial value, its as much about personal values. That said financial value should neither be ignored or belittled - after all, most software is developed for commercial reasons, profit is not a dirty word.

Thus let me make another statement I believe is true:

Quality results in business benefit - money saved, money made, happier customers, business aims realised

Once we accept this the statements like “Quality is free”, “High quality save money” and “Quality sells” become axiomatic. The aim of “high quality” is to produce one of these business benefits.

Consequently statements like “We can’t afford this much quality” and beliefs like “Lower quality is acceptable to customers, is faster and saves money” are the result of a mismatch in different individuals understanding of what is quality.

For example: one person believes customers are happy with buggy software as long as it is available soon while another believes that customers want bug-free software later. When such mismatched occur using the word “Quality” is itself a problem because it means different things to the different parties.

That might all be too circular for some, sorry about that, I wish it wasn’t but I suspect that is the nature of the beast.

Now back to my definition and the inner layers of my onion. I think defects and maintainability are at the heart of the onion and need to be present in every definition of software quality because…

Defects: the research I have seen (Jones and elsewhere) and personal experience (as a developer,manager and customer) tells me that defects (bugs) are not a good thing - whether absolute defects or common defects. My experience and intuition tell me Jones is right when he says: “projects with low defect potentials and high defect remove efficiency also have the shortest schedules, lowest costs, and best customer satisfaction levels.”

Maintainability, changeability, and its half-brother extendability, is life. Software which can’t change can’t live.

At a basic level if you have maintainability you can fix defects and you can add any other quality you like. If your software is maintainable but not performant you can change it to have the performance you want. If your software is hard to use but maintainable you can change it to be easy to use.

If your software lacks maintainability, changeability, you will find it hard - expensive but perhaps not impossible - to make any of these changes. When software lacks maintainability it is not soft.

Lets agree to call software which is not (easily) changeable (maintainable) sclero-ware.

Definition: Sclero-ware - software which is not practically changeable.
(Where practically is context dependent.)

“But” you might ask, “are there not some examples of software which does not need to be maintained?”. “Surely,” you say, “there is some software which does its job and it is done. Defects might be core of the onion but maintainability is just another quality you might, or might not want.”

While this I can follow the logic here I am lacking an example. Do you know any? Indeed I suspect there are no such examples.

Because: successful software is used, and because it is used it needs to change.

Software needs to change because the world changes: Windows 8 replaced Windows 7 which replaced Vista which…. the Euro replaced the Deutschmark which replaced Reichsmark, the 747 replaced the 707 which replaced the Queen Mary and Queen Elizabeth I, telephones became mobile, telephones replaced iPods which replaced Discman which replaced the Walkman and along the way iPods replace Hifi systems, Banks replaced Building Societies, Debit cards displaced cash, ….

Must I continue? - the world changes.

Software which is not used does not need to change.

Software which is not used is the past. It is dead. Look here, SourceForge has plenty of dead software projects you can download, try one (here’s a page of examples.)

Successful software lives, it changes, it moves on.

So yes, software which did its job and is no longer used doesn’t need to change. You don’t need to change if you are dead.

Also, “maintenance” starts a lot sooner than is many people recognised. Maintenance starts the day after coding, not the day after the “project” ended. If you need to go back a fix a bug - at anytime! - you are maintaining. If your software lacks maintainability you are going to have a hard time getting any bugs out (and I suspect if it is not maintainable you probably have a lot of defects).

To summarise: I consider software quality to be a function of high maintainability and a low number of defects. I focus on these to attributes because I believe these are invariant. I am happy for add more qualities in a given context.

I accept there are different views on the best way of achieving these qualities. For example:

• The approach I was taught in the 1980s and 1990s involved detailing what was required, perhaps writing a logical specification, engaging in a design process intended to minimise defects and maximise maintainability, then coding and finally testing the software. Some people call this “Waterfall”, I prefer “Traditional”.
• The approach I advocate today involves setting a goal, identifying small pieces which can help build towards the goal, setting tests, engineering to those tests and repeating the process again and again and again. Some people call this “Agile”, I believe there are actually three styles better called “Iterative”, “Incremental” and “Evolutionary”.

And I believe that if you lack quality - you have a high number of defects and sclerotic code - sclero-ware - you will fail every time.