Section 5.7. Diagnosing Review Problems

5.7. Diagnosing Review Problems

Many organizations rely on their testers (or, in worse cases, their users) to find the bulk of the defects in the software they produce. When the defects are caused by simple coding errors or typos, they are easy to correct. Unfortunately, very few defects are caused by simple coding errors or typos. Most defects are introduced before a single line of code is written. Sometimes a programmer misunderstands the design; at other times, the entire team fails to take a stakeholder's needs into account and fails to build a needed feature into the software. Waiting until after the software is built to discover these problems results in an enormous amount of work to fix defects that should have been caught before a single line of code was written.

5.7.1. Problems Are Found Too Late

There are many problems that can be avoided by having the team adopt vision and scope documents, project plans, software requirements specifications, and other project documents. But what happens when the team doesn't catch an error in one of these documents until the software is built?

One of the most common causes of project failure is that requirements contain a defect that is not caught until much later in the project. Trying to fix that defect after the software is built can be so costly that it can destroy the project entirely. For example, suppose that a team member writes a use case document to describe a critical feature. The document is emailed around to the team, and everyone reads it. However, some of the readers are very busy, so they only skim it and see that it looks about right. Others see problems, but don't want to embarrass the author by bringing them up. A few think that they found very obscure problems and don't want to embarrass the other readers who they think would not have come up with the problem.

Some teams try to find defects by mailing documents around to the team, with no real expectations of what the team is supposed to do with each document. After the author mails the document out, usually nobody responds to the email for a few days. Responses trickle in over the course of the following week. Some of them point out serious flaws, but most of them do little more than point out typos and minor wording changes. In the meantime, the designers start their work to avoid sitting around doing nothing. Eventually the user interface, architecture, and software are built. The product is passed down to the QA team, who start testing the build. They haven't been a part of the development of the software at all, and have only been talking to the users and stakeholders, putting together a test plan to ensure that the software does everything that they expect it to. Within a few days, the QA team discovers a problem: there is a feature that does not work the way the users need it to work.

When this happens, the entire project team is brought together in a meeting, and a split quickly forms. The QA lead and stakeholder insist that the software is broken. The requirements analyst, design lead, and programming lead insist that there is nothing wrong. They finally start going through the documents and find that the software does, indeed, meet all of the requirements laid out in the relevant use case. But the use case is wrongit does not describe what the users need the software to do. It's clear to everyone present that fixing the problem will be a major endeavor, and that the project will be delayed for a very long time. The team built software that was solid, well-built, and functionalbut they built the wrong software.

If the project team had inspected the use cases, this could have been avoided. Everyone with a stake in the projectincluding QA team memberswould be invited to the inspection meetings , and each inspector would have a better idea of what to look for during the inspection process. It costs the same to build the right software as it does to build the wrong software. A few hours of searching for and fixing any problems with the use case document would have saved the team weeks or months of rework.

5.7.2. Big, Useless Meetings

Having a project fail due to a problem in a document that isn't caught until late in the project is traumatic for a team. It's especially bad for the person who wrote the document. Once a team experiences this problem, everyone feels especially motivated to do something about it. In many cases, the solution that seems most obvious to the team and the project manager is to distribute the responsibility for creating the document. The last project was a mess because the team missed something; there's no way that they will let this happen again.

The project manager calls a meeting to get everyone together at the very beginning of the project. He takes no chances, inviting everyone who might possibly have some small input into the project and impressing upon everyone just how important the meeting is. An entire afternoon is blocked out for a standing-room-only session that's supposed to let everybody have a voice in the design of the document. Unfortunately, it ends up having the opposite effect.

Everyone has something to say, and nobody wants to let any stone go unturned. The big meeting seemed like a good idea on paper, but it quickly gets bogged down in details that only one or two people care about. The meeting goes nowhere. Nobody knows what they are supposed to do, and there's no real leadership or direction. Long after meeting fatigue sets in, no progress has been made. Stakeholders are arguing about the minute details of the day-to-day business of the organization, while designers are caught up in potential design problems, programmers can't decide on which tools to use, and, through all of this, nothing is written down. The team adjourns the meeting, having made no progress. After a few tedious marathon meetings, the project team gets sick of waiting and decides to do things the way that they've always been done.

Had the team held an inspection meeting, a deskcheck, or a walkthrough, everyone would have understood his or her role. The reviewers would have been more carefully selected. A single lead author would have had the responsibility of generating the document. Each reviewer would have had a well-defined role, reading the document and bringing up specific defects. Each defect would have been discussed by people with some knowledge to address it, and the responsibility for finding the errors would rest with the people capable of fixing them.

5.7.3. The Indispensable "Hero"

Sometimes a programming team has one "hero " who seems to stand out above everyone else. If a technical problem comes up that nobody can solve, and it looks like the deadline will be blown, the hero will often take the problem home on Friday night, work all weekend, and come in on Monday morning with a solution.

It seems like the hero is good for the team. But there are some serious downsides to his heroics. He's a constant scheduling problem for the project manager, because it seems that no project can be completed without him. He's constantly over-allocated, and there are entire programming teams who cannot move forward because they are waiting for him to finish a project. Meanwhile, he is constantly working 70-hour weeks, and the entire team is afraid that he will burn out or leave the organization.

In some cases, the hero is inadvertently keeping the rest of the team from advancing, either professionally or in the organization. It seems that the hero wrote the core of every code library. Only he knows the details of critical architecture pieces. The hero is tired of people talking about him getting hit by a bus, which seems to come up at least once in every architecture or code planning meeting.

The most difficult problem to deal with in this situation is maintenance. Because of his peculiar over-allocation problem, there is an increasing amount of code that only the hero is able to maintain. This is usually because he was called in to write the most difficult part of the code. Sometimes it is algorithmically difficult, and he's the only one with enough experience to do it. At other times, the coding task relies on a library that he wrote and that only he knows how to use. In either of these cases, if that code needs to be updated, the hero is the only person in the organization who is familiar with it.

Code reviews and pair programming can help alleviate the dependence on the hero. When he writes a piece of especially tricky code, he can hold a code review. If a group of programmers inspects that code, they will be able to maintain his code. In future projects, they'll be able to draw on what they learned in the review session. This will help the entire team's professional development. What's more, the hero is often not much more advanced than everyone around him; he may just know a few tricks that the rest of the team can begin to pick up. Pair programming can be especially helpful if the hero is teamed up with another senior programmer. Sometimes the "hero" status is merely a matter of perceptioneveryone just "knows" that he's the best programmer around. Pair programming can help everyone on the team realize that they have other people who are just as valuable. For the true hero, sharing his skills with others will help him earn real respect from the team. Team members will be able to continue to learn from his experience, and he will be able to share and teach the team. The team, in turn, will come to see him as a role model and a leader, instead of just a hero who swoops in to fix their problems.