How can we recognize a good piece of software?

Program Quality

Conrad Weisert, November 2, 2007
©2007, Information Disciplines, Inc.

NOTE: This article may be reproduced and circulated freely, as long as the copyright credit is included.


"Any program that works is better than any program that doesn't work."

- a manager's cliché from the 1960s.

What is a "Good" Program?

I ask that question at the beginning of my advanced programming courses and in various management seminars. If the participants need prompting I rephrase it like this:

Given two computer programs that are said to do the same thing and have similar user interfaces, how do we judge which of them is "better"?

The participants usually quickly agree on the following obvious criteria; a good program:

  1. exactly conforms to its specification (correctness)
  2. executes fast (time efficiency)
  3. consumes minimal memory (space efficiency)
Is that all? Hardly. We've omitted the most important one:
  1. exhibits high internal quality (flexibility, maintainability)
Why is that one so important? Over the lifespan of a typical computer program maintenance will account for a major share of cost. We modify software in order to correct bugs, to respond to new insights or user demand for enhanced functionality, and to comply with changing business, legal, or environmental conditions.

Maintainability not only affects direct cost but also has a huge impact on system reliability. A program that's hard to maintain is also prone to bugs, often bugs that are maddeningly hard to diagnose.

Discouraging trend

Although that last criterion, internal quality, was the focus of the structured revolution a generation ago, it often gets forgotten today in the press of arbitrary deadlines, extreme short range goals, and process-driven fad methodologies. We're seeing just as many really atrocious programs today as ever. And the very notion of quality assurance has gotten distorted so that some naive young managers think it means little more than thorough system testing. Many recent graduates of computer science curricula are unaware of quality issues, presumably because their instructors and mentors were.

Measures of quality

So, how do we assess the quality of a program, of an individual module, or of a whole system of programs? Are such measures too subjective to evaluate accurately?

Of course, assessing software quality depends on competent judgment, but it's not hard for mature professionals. Here are some of the important quality criteria that can be judged by examining program design and source code:

Those criteria ought to be non-controversial. We haven't said who should make the judgments, when during the development process they should be made, or how quality ought to be enforced. Those are issues for separate articles.

We can confidently assert, however, that an organization's written methodology guidelines and its internal professional education programs must strongly support quality in all development activities.


Return to IDI home page
Technical articles

Last modified November 3, 2007