What exactly is software quality?

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. Then only all kinds of software for mechanic shops can function efficiently & can run their online business successfully.
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"