* 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.

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

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.