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.
Pages
About the author
The founder and president of Quality Tree Software, Inc., Elisabeth Hendrickson wrote her first line of code in 1980. Moments later, she found her first bug. Since then Elisabeth has held positions as a tester, developer, manager, and quality engineering director in companies ranging from small startups to multi-national enterprises. A member of the agile community since 2003, Elisabeth has served on the board of directors of the Agile Alliance and is a co-organizer of the Agile Alliance Functional Testing Tools program. She now splits her time between teaching, speaking, writing, and working on agile teams with test-infected programmers who value her obsession with testing. Elisabeth blogs at testobsessed.com and can be found on Twitter as @testobsessed.
