Beautiful Teams

Solving Problems As a Team

It would have been easy to blame the developer, Fred, who had integrated his feature. But that wasn't the team's culture. There was a rousing chorus of "brain-dead code" at our meeting. I suggested we do a quick root-cause analysis at our team meeting, to see what had gone wrong. I was sure we had several issues at work, and it would be worth our while to see what was happening. The team agreed.

The team discovered several things had occurred (see the following figure):

• No one had looked at the code before it was checked in.

• The team was no longer using their multiple levels of check-in.

• "Too many" people had checked in on the same day.

• No one had added anything to the regression test suite to check for new features.

Figure 27-1. Root-cause analysis diagram.

Dan took the lead. "OK, what do you guys want to do?"

Fred replied, "Look, we all know how I can be." Everyone except me nodded, grinning. "I really want someone to review my code each and every time. I'll write unit tests, especially since we don't have testers, do we, JR?"

I replied, "Nope, we don't. Unit tests are a great idea. They aren't the same as system tests, but they should prevent this problem."

Dan said, "But we're not done yet. Just code review and unit tests aren't going to be enough. We're going to have to go to multiple levels of check-in, like we did on the last project."

I replied, "You don't ...