On Assessing The Quality of Software

/via http://geek-and-poke.com/geekandpoke/2008/2/4/the-art-of-programing.html

“How do we build quality software?”
It’s a pretty simple question to ask, but one in which the answer can take pages.

For starters, what do we mean by Quality? We could get into the whole definition of Quality, and go off on a digression about the false dichotomy of separating Truth And Quality, about the need to fuse Rationality and Romanticism, and then end up wandering off and reading Zen and the Art of Motorcycle Maintenance all over again.

Mind you, that would be my attempt at ignoring the original question (See? Thats why I could never be a politician!), and we can’t have that, can we?

The thing about Software Quality is that so much of it falls into a “I know it when I see it” category (with apologies to Oliver Wendell Holmes). Everybody has their own take on what it actually is, though you can extract some commonality — things like modular code, consistently written, strong test coverage, etc.
That said, without going too far down that rabbit-hole, a strong precursor for quality software would be quality people. In short, if you have quality people, you’ll probably have quality software.

That isn’t just me begging the issue — it’s more about how so much (everything?) we do when we build software is make compromises.
You see

1. Business conditions determine the constraints associated with your project
2. These constraints are invariably things that your people really have very little control over
3. These constraints have existed, and will exist forevermore. Ok, not the same constraints. But some constraint will replace the current one. Forevermore
4. If you have a quality software team, then they will build to current (and anticipatable future) constraints.
5. And to the extent that they can’t anticipate future constraints, they’ll build the software so that it is adaptable.

Or, to put this slightly differently, Software quality is inextricably linked to the constraints under which it is built. You can take this one level higher, and say that even the quality of the people you have are a constraint.
(And yes, of course there is the mythical environment in which the Perfect Development Team had infinite time and infinite choice in developing the Perfect Application. I also have a bridge for sale in Brooklyn…)

The bottom line here is that to really understand the quality of your software, get to know the people who built it, and what their constraints were. What crises occurred, whether there were deathmarches, which requirements changed late, and so forth. You’ll get a much better understanding of where things stand, then if you just read the code!