The secret of producing software with the minimum number of bugs at the lowest cost has been known for some time: structured walkthroughs. While other techniques and technologies have all had their proponents and successes, nothing has delivered significant improvements in quality improvement at a lower cost than organized walkthroughs.
A walkthrough is a simple process. The developer prepares a readable copy of his or her work and sends it to the other participants in the walkthrough. They review the material prior to getting together for the walkthrough. At the walkthrough, the developer leads the group through the material, and all members contribute to the list of suggestions, issues, and concerns. If problems are found, solutions may be suggested, but resolving the problems remains the responsibility of the developer. After the walkthrough, the developer returns to his or her desk and acts on the suggestions. The developer produces a report that addresses each issue on the list produced at the walkthrough. The action on an item ranges from describing why the item doesn't need to be addressed to a new set of code.
It's hard to understand why a process that's so simple and so successful isn't used more. Part of the problem, of course, is that so many of us are lone developers. Even where we do work in teams, we might not have a group large enough to perform a walkthrough. In general, a walkthrough requires a minimum of three people, and, to be successful, none of these people can have input to the appraisal of the person whose material is being reviewed. If it's your boss who's pointing out your code's deficiencies, the process usually fails. Perhaps the Internet will allow us to collaborate to eliminate these problems.
More often, there's a belief that the benefits that result from walkthroughs don't offset the cost. The developer could spend an hour preparing the material for review. The other participants could each spend another hour reviewing the material prior to the walkthrough session. The session itself could run two or three hours. Assuming that the walkthrough consists of the developer and two reviewers, that adds up to 12 hours. Managers and programmers both tend to balk at the loss of time, especially as the project gets closer to the final delivery date. It's considered a better use of the project's time to pump out poor-quality code than to ensure that the code that's going into the project is worth using.
Most companies' evaluation processes emphasize this problem. When walkthroughs are effective, the benefits are the absence of problems: shorter testing cycles, fewer bugs in production, and so forth. It's hard to point to what's not there and say, "See, that's our benefit." Comparison with other projects that don't use walkthroughs is difficult to do since those projects are, obviously, different. If projects are assessed on delivering the most code or functionality in the least time, then walkthroughs are difficult to justify as, presumably, the review time could have been spent writing code. Only when testing time and service costs after delivery (bug fixes) are factored in do the benefits of walkthroughs appear.
There are social and political issues also. Unlike the bad old days, most developers now produce code with an eye to the person who will have to maintain it. As a result, there's a lot more readable code being produced than in the early days of programming where cryptic variable names and obscure, too-clever code were the norm. Someone once described those early programs as love letters from the programmer to the computer, full of details that only the two lovers would understand.
I know that I still regard my programs as my offspring, and, like any other parent, I don't like to be told that I have ugly children. I still have a lot of ego invested in my code. Holding my code or design documents up for review seems too painful to consider. Yet there are benefits. In the March 1999 issue's "Access Answers" column, I had what I thought was a swell solution for multi-tasking in Access. A friend pointed out a possible problem with the technique that I was using, and the resulting discussion led to a whole new solution (which I can use in another column). I'm sure that you've had the experience of fighting with a problem, asking a friend to look at it, and halfway through the explanation realizing what had gone wrong and fixing it. Walkthroughs are like that, only better.
If you want to learn more about how to perform walkthroughs and the benefits that result, try reading Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products, by Daniel P. Freedman and Gerald M. Weinberg (Dorset House, ISBN 0932633196). It's a great book, and it addresses the whole field from benefits to the social and political costs.
Now I'm going to take this editorial down to my wife so that she can review it before publication.