Software Quality

Well, let’s start here.

Everybody, as they say, is talking about it, but nobody is doing anything about it! Software – our particular discipline – is often criticized as producing systems that “almost work.” Is there any way out of that particular swamp?

Quality is easy to define. Systems should do what they are supposed to do and do it flawlessly. Part of the problem is just that last word. Flawlessly. Without a flaw. So we are trying to define something as the lack of something else. Sometimes there is a very fine line between a “bug” and a feature.

The other problem lies in “supposed.”

The specification of what a system is “supposed” to do is partially a communication problem – technologists are notorious for understanding problems in terms of their prospective and previous solutions rather than in their customers’ world view. Listening with an open mind is a crucial skill for any problem solver … so as not to solve the wrong problem.

The drive to produce minimum viable products (MVPs) has seemed to have set us back. As has agile, but that is a topic for another time. The mistake that some folks make is to confuse “minimum viable” with “barely functional.” Or, worse, buggy as a horse-drawn cart. An MVP is not (should not be) a prototype … it should be a fully-functional, if limited, solution that is able to grow and evolve in predictable ways.