Reassessing quality measurement of enterprise software

I’ve been wondering for some time how to assess the quality of enterprise software. Or any software, I suppose, or any artifact. But I’ll stick to my humble domain.

A software engineering textbook I have on bookshelf has a chapter on “Quality Management,” chapter 24 of 28 in total. It links quality to how well a program fulfills its specification, while noting that specifications are almost always impossible to nail down in complete and unambiguous detail.

The textbook does not define quality. It presume we all know what quality means. A quick look at a dictionary shows that quality means something like the degree of excellence, and carries an implication of comparison to a standard. The textbook assumes that the standard is the specification.

But the spec can’t be the standard. There’s no way that something that is necessarily ambiguous in certain aspects, and incomplete in others, can be a standard by which one can honestly measure anything.

No plan survives first contact with the enemy–so said General Patton. I imagine Patton would have said that something has quality so far as it helps win the war, even if it stinks and looks like it came from a latrine.

Several outstanding business generalists have told me more or less the same thing about the software they rely on. Software quality is how well a particular implementation produces value, not how well it conforms to spec or best practices. Spec and best practices themselves should be shown to deliver value.

What does all this entail? Certainly, software must be thought of in functional terms, as part of a larger system. As far as details of what measuring that fitness might look like, I’m working on it…

Comments are closed.