A few months ago, I wrote about process rarely fixing the real problem. I remembered that post because of an issue that was reported to me, and Tac Anderson wrote a timely post about the same idea. He phrases the question a little differently by asking if you are solving problems or fixing problems, and he includes an interesting definition of both:

Solving a problem is what people do when they figure things out for the first time. When you solve a problem you create a solution. The next time you solve a problem you’re applying the solution to the problem to fix it.

Tac’s post is geared towards PR & marketing, but the idea is somewhat the same in software development. Software is never completely correct the first time it is written. There are always problems (issues, defects, bugs or your favorite term) after the initial release. Some of what software engineers do every day is problem solving in the traditional sense.

So, what happens when a defect is found? The software engineer will need to dive into the code and fix the problem. In this case, it could be that the defect occurs because a fundamental assumption of the code was violated. As an example, let’s say we have a method that takes a list of tweets (those Twitter message things). A fundamental assumption of this method would be that the list does not contain a null value when the list is not empty. So, if someone is passing a list with a null value to the method, how do you fix the defect? In many places, the originator of the error will need to fix their code to handle the situation. This type of “defensive code” litters your source code with various if (object != null) type of statements. This will ensure that you no longer throw a null pointer exception.

However, what if the fundamental assumption of the method is supposed to be true? The symptom of the problem is the null pointer exception. In this case, the source of the issue is really the calling method. It could be true that the calling method is actually passing a list that is a parameter to it. So, you would need to trace the issue back to the real source of the problem. This is diagnosing the disease instead of just treating the symptom.

Granted, my explanation is about software, but this type of process can really be applied to almost any industry. Are you fixing a problem to make it quickly go away? By doing that, the problem may go away in the short term, but it may reappear several times over the long term. If you look at this in terms of time, you may provide a short term fix within 30 minutes. However, every time that you need to fix the problem requires 30 minutes. Think about the long term savings if the long term solution only requires 2 hours.

If you put an hourly rate on this ($50/hr), the returns become more obvious. Let’s say the problem occurs once per week. If you choose the short term fix, you will have incurred 30 minutes for each of the 13 weeks. A simple calculation, 13 * (30/60) * 50, gives you a total cost of $350. If you choose the long term fix that is a one time cost of 2 hours, your total cost is only $100.

Obviously, this little example does not add up to big dollars, but you can quickly see why short term fixes tend to be more expensive. So, are you treating the symptom or solving the problem?

http://static.zemanta.com/readside/loader.js