Sunday, December 15, 2013

Software troubleshooting "at source"

The title of this post is inspired by the Indian tax department's primary mode of tax collection -  "Tax Deduction at Source" commonly known as TDS. The word source takes the meaning of "point of origination" and shouldn't be confused with source code that software is built with. 

In his book "The Road Less Travelled", the author Dr. Scott Peck narrates an interesting experience. I don’t remember the exact details and the context where it was used but this is how it roughly goes. One a busy day morning, Dr. Peck's car refused to start. The author is by no means a car "expert" and more importantly he had scripted a mental block inside him that solving such problems are beyond him. Yet, on that particular day he decided to give a shot and find out what is wrong. He applies his time and his common sense to identify the problem and goes on fixing it. The decision to take quality time to look at the problem ended up solving it! He overcame something that would have otherwise damaged his day and in the process he found out an important natural principle. Solving problems in life may require only common sense for most of it and one has to apply his time to do that.

All of us face problems. Problems could pop up during our work or outside. To which we seem to have an innate tendency to react with frustration. If a gadget doesn't work, we get frustrated or sad, bang the keyboard with our heads or throw up our hands in the air. We form typical defence mechanisms to justify the frustrations. Some of them are like, "I don't have the expertise", "this is not in my domain", "I don't have the time and I am supposed to be doing something else". The emotional reaction to the problem typically makes solving it more difficult. How about just stopping and thinking briefly about the problem at hand and decide to spend some time in solving it? Our elementary knowledge of science, "time" and the gift of intelligence should suffice. Studies suggest that at least 50% of the issues can be solved this way. (Well, I made the figure up but I hope you agree with what I am getting at.)

Software now is a major part of our everyday lives and like life, software also has no scarcity of problems! The natural principle of problem solving mentioned in the above story applies to software problems just as much.

Generally, the person who is most affected by a bug, the biggest stakeholder in it is the one who finds it in the first place. The onus on making others understand the bug is primarily their responsibility. To communicate the problem well, it has to be defined well and this requires time, effort and energy. Looking at the problem carefully and some preliminary investigation might lead to a solution and even if it doesn't it could give valuable leads to the person who attempts to solve it for you.

There is a general misconception among software users that what they invest in troubleshooting bugs is not worth it and that those are someone else’s problems to solve. There is nothing farther from truth. Troubleshooting is a life skill and not a single moment of time that you invested in it is ever wasted. If you start exercising the troubleshooting "areas" of the brain on one part of your life, these "areas" get efficient on all others. You will be astounded to see how much difference you can make to yourself and others if you start enjoying the process of troubleshooting. It helps in the long run; I can assure you, the world will never run out of demand for problem solvers.

This is the premise of a talk that I intend to develop on the topic of “Troubleshooting at source”. In addition to a detailed argument to change the attitude of software users as outlined above, I intend to cover some key techniques that we software developers use to identify problems and fix them.