The Problem Isn't Always THE Problem

[article]
Summary:

When things go awry, sometimes the first problem you see is not The Problem but just a product of its symptoms. But if problems can hide behind other problems, how can you learn to spot the true culprit at the source of your dilemma? Elisabeth Hendrickson shares some lessons she's learned about "The Problem."

Some time ago, I was acting as a QA manager in a troubled organization. We were experiencing quality problems: the software was shipping with more defects than we wanted and was becoming less rather than more stable with time. I felt quite certain I knew what the problem was. "We don't have any coding standards," I fumed. "We don't have any guidelines to help developers make good decisions about the tradeoff between improving performance and bullet-proofing. We don't have any documentation on how to use our own APIs" (Application Programming Interface).

I took the opportunity to bend the ear of a friend in the industry, Brian Lawrence, over a friendly lunch one day. He cocked his eyebrows at me quizzically (a Brian Lawrence trademark) and asked a simple question: "Are you sure that's the problem?"

At first, I was defensive. "Of course that's the problem!" I grumbled. But Brian was right. The lack of coding standards was a problem, but it wasn't The Problem. There were a number of reasons for our quality problems. The most important of those problems was a lack of requirements and design analysis, rather than a lack of coding standards.

It's Not the Problem?
I often fall into the trap of thinking that the first problem I see must be The Problem that needs to be solved. Perhaps the problem I spotted is indeed worth correcting, but I almost never manage to spot the true critical issue at first glance.

At one company, I thought that The Problem was a lack of unit tests. I started beating the drum for better unit tests. Some of the developers agreed with me and encouraged me. Others politely ignored me until I went away. Still others rolled their eyes whenever I started my "Unit Testing Is Your Friend" stump speech.

Then I attended a meeting in which we were discussing bugs in a particular area of the code. The developer responsible commented, "Oh, good. I was wondering when you guys were going to start finding those bugs." I was shocked. The developer already knew about the bugs. He didn't need better unit tests; he needed time to fix the bugs. He knew he wouldn't get that time until the test group found the bugs themselves.

I had found a problem: in some cases the unit tests were insufficient. However, that wasn't The Problem. In this case, the deeper problem was that developers didn't get time to fix the bugs they found. As far as management was concerned, until a tester found it, it didn't exist.

No, It's a Symptom
In a meeting toward the end of another project, a developer began talking about some changes he'd made to the way a particular feature worked. "Wait," I interrupted. "I thought we were in code lockdown phase. Now you're telling me that you've added functionality. What's going on here?" Three weeks to ship and we were still changing the way the software worked. "Poor change control will sink us!" I thought.

However, it turns out that the changes the developer was making were part of the original plan. The problem wasn't feature creep or poor change control, it was that the schedule said we were supposed to be done with the feature, so development claimed to be "done" while still implementing functionality outside the process. What we really needed was a more honest schedule, not a better change control process.

About the author

Elisabeth Hendrickson's picture Elisabeth Hendrickson

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.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03