What exactly is software quality?

Erwin van der Koogh

That is what I would like to find out today. If you ask a group of developers what it is, the only thing they will agree on is that it is important. Managers will tell you they want high-quality software, but only because it is politically correct to do so. They are more than willing, and usually even eager, to trade in this mysterious quality for more functionality or performance when it is needed.
And who can blame them? What is the business case for something you can not even explain?
We know beautiful code when we see it, but how do we write beautiful software? And the even better question, why would we care?

If you start looking around for a better definition of software quality you come across a bunch of lists of "things". With one of the most comprehensive ones being ISO 9126. These "things" include:

  • Maintainability
  • Testability
  • Usability
  • Reliability
  • Security
  • Performance
  • Consistency
  • Understandability (My new favorite English word)
  • Portability
  • Refactorability (Close second)
  • andsoonandsoforth..

How can we as developers and architects be so passionate about something this huge and complex? Does anyone get up in the morning hoping they can write some nice secure, reliable and portable code?

Those are all requirements and/or acceptance criteria. That means that "our" software quality is either not present on the list, or just a subset of it. The quality we find so hard to sell. We can sell security, reliability and portability to our managers if they need them. Even usability is becoming much easier to sell these days as users do not let you get away with crap designs as much as they did a couple of years ago.

Taking away the requirements/acceptance criteria leaves us with mostly touchy-feely stuff. But it seems to be very important touchy-feely stuff.
After talking, discussing and brainstorming with a lot of people over the past couple of weeks it finally dawned on me that the software quality is about understanding code. Beautiful code is code that is easy to understand. And with that comes a host of other advantages:

  • Bugs will be easier to find
  • Refactoring is possible
  • Changes are going to be easy to make
  • Security is going to be a lot easier to do
  • Audits are going to be a breeze.
  • Etc..

But all these things have no bearing on the now. A lot of things will be easier in the future, but with no concrete evidence of how much easier things are going to get in the future, how are we ever going to sell it? I do not know the answer to that yet.

Which leaves the following follow-up questions:

  • How do we measure understandability objectively?
  • What is the relationship between understandability and possible future productivity gains?

If you have any pointers or answer to the above questions, please share them in the comments.

So as of today I do not care about software quality anymore. All I am going to care about in the future is the understandibility of code.
Hmm..maybe a better blog title would have been "Code Quality is dead, long live Understandability"

Comments (5)

  1. Lars Vonk - Reply

    November 5, 2008 at 12:49 am

    Hi Erwin,

    Interesting topic, I have some remarks though:

    - You say the ISO 9216 requirements have nothing to do with 'our' software quality. I disagree here; you mention refactorability, testability, Understandability, readability and so. These have everything to do with software quality, in fact that is even what you state later on in the blog when you say "Refactoring is possible" etc. Or am I misinterpreting your statement?

    - You also mention you need to sell beautiful code. Why do you need to sell it as separate thingy? Whenever you write code, you need to write it at the most beautiful way possible at that time, right? That's what craftsmanship is all about IMHO.

    There is a very good book available about this topic:
    Clean Code by Robert C. Martin. (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882). I highly recommend it explains the why's and the how's to write beautiful, clean, understandable code. Mandatory reading for all programmers.

  2. Erwin van der Koogh - Reply

    November 5, 2008 at 1:04 am

    Hey Lars,

    What I meant that the whole package ISO 9216 is not "our" software quality. I have edited the post for clarify.

    Re your second comment:
    In one of my recent assignments I came across an application that was already legacy code while the project wasn't even finished. Deadlines were missed already and deadlier deadlines were on the way. What I found hard to do was to convince (project) management to invest time in cleaning up the code instead of building new functionality.

    So you need to invest time to make/keep your code beautiful. How do you justify that investment?
    Thanks for the book reference, it's on my to-read list. I hope I'll find some answers to that question in there 🙂

  3. Kurt Häusler - Reply

    November 5, 2008 at 12:52 pm

    Excellent post, too many people think software quality and fixing bugs are the same thing. Bugs are merely a symptom of software quality, and shouldn't be directly fixed. Instead pay back the technical debt that the bug points to.

  4. Kurt Häusler - Reply

    November 5, 2008 at 2:33 pm

    I forgot to try and answer the questions:

    * How do we measure understandability objectively?

    Firstly, while I think understandability is important, I don't think its the number one quality indicator. Some developers do not understand a lot of quality-enhancing design principles for example the S.O.L.I.D Principles, the Law of Demeter, Persistence Ignorance, Gui patterns like MVC and MVP, and Domain Driven Design. For many developers the most "understandable" code is a quick drag n drop app where database fields are bound directly to gui controls for example, and everything is in a single "god" class. This type of understandability does not however represent good design.

    Agile development has a concept that the simplest workable design is the best. But I find in practice that leads to significant code debt at a high rate of interest. I prefer to phrase it, the simplest, testable, refactorable design that works is the best. Because even if we choose to incur some technical debt by disobeying certain design principles, we can do so at a lower rate of interest by ensuring that such designs can at least be improved later if needed.

    In a similar sense, I would suggest that the most understandable design could be the best, provided it too is testable and refactorable, and obeys as many of the laws of good software design as possible.

    To answer the question understandability and software quality in general cannot, except in highly controlled domains, be measured objectively. The best we can come up with are subjective evaluations.

    * What is the relationship between understandability and possible future productivity gains?

    I would prefer to answer the question "What is the relationship between software quality and possible future productivity gains".

    In this case the relationship is technical debt management. By monitoring technical debt in a project we can come closer to estimating the true cost of software, including paying back the technical debt and interest in the form of increased costs of maintaining software with technical debt, and therefore the productivity of the project can be measured in the same way as actual features.

    Technical debt has been a hidden item in software projects for far too long.

  5. Enrique - Reply

    June 22, 2013 at 2:55 pm

    BTW guys, ISO 9216 doesn't exist... is ISO 9126
    Cheers!

Add a Comment