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.
- a manager's cliché from the 1960s.
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:
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.
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.
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:
Modularity has been seen as a highly desirable software property for a half century, despite a lack of consensus on exactly what it is. The following three properties comprise a broad and somewhat oversimplified definition of modular structure:
Note that modular program structure is independent of both the programming paradigm and the methodology that produces it. Object-oriented programs, procedural programs, functional programs, etc. should all be organized in a highly modular fashion, as should software developed under agile or incremental approaches.
The program mustn't be over-specific, but should be able to handle a range of conceptually similar problems. On the other hand, it mustn't be so general that it's either inefficient or burdensome to use.
The YAGNI ("you aren't going to need it") principle promoted by so-called agile methodologies refers to adding features not to broadening scope. In particular, there should be no missing or fragmentary capability that a reasonable user would expect.
Alignment, indentation, pagination, choice of data names, and appropriate commentary must conform to enlightened good practice. The program reader must not have to simulate a computer in order to determine exactly what a given routine does, nor should a reader have to consult separate design documentation.
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
Last modified November 3, 2007