thus forcing all changes to go through her. Because we were very late in the process, Sharon was to review all changes before checking them in-enforced code inspection.
I heard a rumor that one of the developers was checking in code on his own, without going through Sharon. That developer's area was also currently the most bug-ridden. "Aha!" I thought. "Here's the problem!"
"Sharon, I heard that Bob is checking in changes without going through you. Is that true?" I asked in a meeting.
Sharon looked at me, then looked away guiltily. "Well, I'm pretty overloaded and I don't understand what that code does anyway. So I gave Bob permission to check in his stuff without going through me."
I'd found a problem all right. Bob's code was so complex that the manager of the department, a fine developer in her own right, didn't understand it. The problem wasn't unmonitored changes; it was the complexity of the design.
Solve Symptoms; Keep Looking for Problems
In each of these stories, I really had found a problem. However, I hadn't found the real problem. I'd found symptoms. So if problems hide behind problems, how can you spot The Problem?
- Open up your mind to other possibilities. Ask yourself, "What if the problem I see didn't exist? What other problems might be at work here?"
- Talk with others about what you're seeing and hearing that's telling you there's a problem. Listen carefully to their responses. Often people
who are not part of the problem have the greatest insight into what might
be going on.
- If the problem you noticed is simple enough to address, fix it and see
what else crops up.
You might even find out that The Problem is a lack of definition of the problem(s).
For more information on defining the problem, see Are Your Lights On? by Gerald M. Weinberg and Donald C. Gause.