Today I had an interesting discussion with a colleague. He was upset over some technical detail in his last project, and I said that it wasn’t a technical problem, it was a people problem. This ticked him off, and we got into a big debate about what are people problems and what are technical problems.

My take on this is that most often, we as techies focus a lot on the technical problems, and work hard to solve these. But as Jerry Weinberg tells us, “No matter how it looks at first, it’s always a people problem”.

What does that mean? It basically means that technical problems are symptoms of people problems. And solving the techie problem is like taking pain killers for a brain tumor. Maybe it will give you a bit of relief in the short run, but you’re still far from well.

So how can you as a consultant/developer/concerned party get to the cause of the problem? I like using the “5 whys“. This will lead you to the root cause of the problem you’ve encountered. Solving this will prevent whatever symptom you ran into from recurring. Let me show you an example:

Our customers are complaining that our software has lots of bugs.

Now, instead of just sitting down and fixing the bugs, let’s try to find the core.

1: Why are we shipping a product with lots of bugs? Because our code base is really hard to change and verify.
2: Why is our code base hard to change and verify? Because the regression tests (lots of them) are all manual.
3: Why are the regression tests manual? Because we have no time to automate it.
4. Why don’t we have any time to automate it? Because our project deadlines puts a lot of pressure on us.
5. Why do we have so tight dead lines? Because our product owner believes that putting the team under pressure produces better software.

We have now gotten to the real issue. Fixing any of the intermediate steps might help, but as long as the product owner has this attitude, new problems will crop up.

To me as a developer, it is always easier to stay close to the computer. That’s my comfort zone. But taking a step back, asking a few questions and not immediately firing up the IDE allows me to be a lot more effective. It helps me and the rest of the business more than trying to solve the incident. The underlying issue is probably harder to change than the symptom, but the rewards are also bigger.

If you find that the root cause is actually a process problem, Kevin Rutherford has a nice write up about this interesting discussion. Maybe I’ll share my feelings on the topic in some future post. Suffice to say is that it’s not very easy to tell the two apart.

Edit: I stumbled upon this after writing this post. Ken talks about how people problems are very common in software projects, still no-one spends any time or effort training software people on the soft-skills required to solve these problems.

Posted by Andres on Monday, March 12th, 2007 at 23:37.