Common Sense Problem Solving

Today a colleague came to my desk and said Microsoft Calculator application has a bug. It can divide 2704 by 51 but it cannot divide 2704 by 52. I opened the calculator on my desktop immediately to check this. 2704/51 gave me some result. But when I did 2704/52, it didn't give me any result. I clicked on ‘=’ again, now it showed ‘1’. I was so confused, why should Microsoft Calculator have a silly bug like this? My colleague said maybe it was implemented by a developer like me :) I was almost convinced that there was a real bug until someone from business walked in and explained 2704/52 = 52. That’s why it appeared like I am not getting any results.

I felt so embarrassed. It was very different to feel this side of the fence. Occasionally our users think that there is a problem with the system, business confirms the bug and prioritizes it, and IT even estimates it. A stereo typed developer by now will be putting a nice big band aid thinking that there is a boo-boo in the system. A common sense developer will be scratching his head wondering what to fix when there is no real boo-boo. I have to admit that I have done this mistake once before. I worked on a fix for weeks before we realized it was never broken in the first place. It is often hilarious to see IT going back to business to explain their own business process to them.

I am training myself to apply common sense to problem solving before digging into thousands of lines of code for answers.

Another issue I frequently encounter during problem solving is when the solution is presented to me before the actual problem. Let’s say the original problem is at point A, the solution as perceived by business is at point B. Based on the solution at point B, the problem as perceived by me is at point C. Plotting all these points on a graph will reveal a nice love triangle. Trust me, problem solving in this case becomes as adventurous and many times as unsolvable as a love-triangle. As a lazy developer, I hate to read design documents. On most of the rare occassions that I did read such a document, I have noticed solutions being stated as requirements.

I am training myself to never listen to solutions before I understand the actual problem.