De|Bug|er

We are living some where in starting to mid-point of technology revolution, still a long way to reach ‘apogee’. But the effect of technology is enormous, from fast food ordering system to NASA Space Shuttle orbiter maneuvering controlled by technology.Every-where and  every-one depends on technology in one way or other. Just look back a decade ago, the nightmare we faced during Y2K era, we were thought world going to be standstill. But thanks to ‘Sang-Froid Debuggers’ emerges from various part of world to make our life easy by providing timely solutions. 

Whether we like it or not, since technology is immature, no bible like guide to develop code, no process (if we have one, people tend to hide behind it) the systems we develop comes with some risks. One of the main risk involves are A)Manual intervention to avoid some possible bugs B)code issues hence system acting weird when some conditions met.

The risk (A) can be mitigated easily but what about (B), to make things worse, most of time the system’s knowledge base may not even exist when some bugs appears.In my experience, there were some bugs took 12-18 months to fix it,of course from very legacy code. But i think we have to do somethings creatively to decrease process time.

Here are some steps to become Sang-Froid Debuggers(assume new developer on a old legacy system without any knowledge base around)

1. Code Psychology : 

One of the most and foremost way of finding and fixing is, understanding developer’s psychology in terms of how s/he writes code,his/her thinking pattern and his/her deviation from “standard” way. The best of doing it is by reading code from left to right, for software developers reading code is most productive than documents.

2. Team Enthusiasm : 

Next level to become ‘Sang-Froid Debuggers’ is understanding teams enthusiasm,of course we may not know until we found some design documents or some real time stories from current co-workers. First of all what i mean by team enthusiasm, (please read 2 nd para first 2-3 lines) due to that each team try to develop system different ways. Some of them very enthusiast towards open source. If that's the case, try to understand, how tightly the system integrated with open source components and start documenting each one’s known issues. Based on my experience, most of the “late hard to fix bugs” were from open source components, mainly we don’t know how to use it.

3. Raising Flags

We all want to fix bugs which are assigned to us by only us but sometimes we need help from others. It is better to ask help from others whenever we needed. I knew some horror stories like one guy took 3 months to troubleshoot an issue, he couldn’t but the other guy did it with in 3 hours. It was not because the first guy was bad, second guy experienced the same or similar issue elsewhere.

4. Early detection and prevention

If we did better work on points 1 and 2, smart developers can sense the system vulnerabilities, start documenting it and start enlighten others.Start some brainstorming for prevention of unwanted bugs from legacy system.