The secret of producingsoftware with the minimum number of bugs at the lowest cost has been known forsome time: structured walkthroughs. While other techniques and technologieshave all had their proponents and successes, nothing has delivered significantimprovements in quality improvement at a lower cost than organizedwalkthroughs.

Awalkthrough is a simple process. The developer prepares a readable copy of hisor her work and sends it to the other participants in the walkthrough. Theyreview the material prior to getting together for the walkthrough. At thewalkthrough, the developer leads the group through the material, and allmembers contribute to the list of suggestions, issues, and concerns. Ifproblems are found, solutions may be suggested, but resolving the problemsremains the responsibility of the developer. After the walkthrough, thedeveloper returns to his or her desk and acts on the suggestions. The developerproduces a report that addresses each issue on the list produced at thewalkthrough. The action on an item ranges from describing why the item doesn’tneed to be addressed to a new set of code.

It’shard to understand why a process that’s so simple and so successful isn’t usedmore. Part of the problem, of course, is that so many of us are lonedevelopers. Even where we do work in teams, we might not have a group largeenough to perform a walkthrough. In general, a walkthrough requires a minimumof three people, and, to be successful, none of these people can have input tothe appraisal of the person whose material is being reviewed. If it’s your bosswho’s pointing out your code’s deficiencies, the process usually fails. Perhapsthe Internet will allow us to collaborate to eliminate these problems.

Moreoften, there’s a belief that the benefits that result from walkthroughs don’toffset the cost. The developer could spend an hour preparing the material forreview. The other participants could each spend another hour reviewing thematerial prior to the walkthrough session. The session itself could run two orthree hours. Assuming that the walkthrough consists of the developer and tworeviewers, that adds up to 12 hours. Managers and programmers both tend to balkat the loss of time, especially as the project gets closer to the finaldelivery date. It’s considered a better use of the project’s time to pump outpoor-quality code than to ensure that the code that’s going into the project isworth using.

Mostcompanies’ evaluation processes emphasize this problem. When walkthroughs areeffective, 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 thereand say, “See, that’s our benefit.” Comparison with other projectsthat don’t use walkthroughs is difficult to do since those projects are,obviously, different. If projects are assessed on delivering the most code orfunctionality in the least time, then walkthroughs are difficult to justify as,presumably, the review time could have been spent writing code. Only whentesting time and service costs after delivery (bug fixes) are factored in dothe benefits of walkthroughs appear.

Thereare social and political issues also. Unlike the bad old days, most developersnow produce code with an eye to the person who will have to maintain it. As aresult, there’s a lot more readable code being produced than in the early daysof programming where cryptic variable names and obscure, too-clever code werethe norm. Someone once described those early programs as love letters from theprogrammer to the computer, full of details that only the two lovers wouldunderstand.

I knowthat I still regard my programs as my offspring, and, like any other parent, I don’tlike to be told that I have ugly children. I still have a lot of ego investedin my code. Holding my code or design documents up for review seems too painfulto consider. Yet there are benefits. In the March 1999 issue’s “AccessAnswers” column, I had what I thought was a swell solution formulti-tasking in Access. A friend pointed out a possible problem with thetechnique that I was using, and the resulting discussion led to a whole newsolution (which I can use in another column). I’m sure that you’ve had theexperience of fighting with a problem, asking a friend to look at it, andhalfway through the explanation realizing what had gone wrong and fixing it.Walkthroughs are like that, only better.

If youwant to learn more about how to perform walkthroughs and the benefits thatresult, try reading Handbook of Walkthroughs,Inspections, and Technical Reviews: Evaluating Programs, Projects, andProducts, by Daniel P. Freedman and Gerald M. Weinberg (Dorset House, ISBN0932633196). It’s a great book, and it addresses the whole field from benefitsto the social and political costs.

Now I’m going to take this editorial down to my wife so that she can review itbefore publication.