If you are a software developer, invariably you would have come across some nasty bugs that wouldn’t just disappear so easily. They are elusive and hang around for days (or weeks), as if they are nagging at you. Remember those countless hours of debugging, stacked up coffee cups, working late nights – you are transformed into a workaholic.

When you are solving bugs, you either add new code or modify existing code. And, in the process, always run the risk of injecting new bugs, inadvertently. Thanks to Murphy’s law, these show stoppers show up exactly at the wrong time, threatening to derail the release. Again, the hapless developer is at the centre of the storm.

This is when those marathon debugging sessions start. Management does not leave any stone unturned in motivating the developer. “You have a golden opportunity knocking your door. This is your time to prove yourself. I am sure you will embrace this and live up to it. You will be a Hero! And your future glorious!” they would say. Not to mention, the poor developer falls prey yet again.

All pumped up, he sets off to squash the bug; nothing is difficult anymore. To start with, he inspects the logs. But, that wouldn’t reveal anything interesting. He inserts breakpoints at some obvious locations and checks the values of those global variables. They are just fine. Now, what about those third party libraries we are using. “I know that is where the bug is. My suspicion is true. Those laggards have a dubious reputation. Last time, it was there code that caused a lot of problems”.

He walks up to his manager to share his revelation, hoping that would be received well. “Well, just heard from quality folks that this feature was working on build dated 27-Sep. I think we used the same version of those libraries then. Didn’t we?” quips the manager. “Geee… You are right!”, he utters and walks back thinking to himself “How stupid I was. This isn’t as easy as I had thought”.

Now, free of inebriation, his sanity is restored. “I think we might have missed out on this one during the design”. He walks to the drawing board, to draw those architectural diagrams, hoping that would help him. As if that wasn’t all, the quality engineer drops in to provide some more 'interesting' piece of information. “The feature works perfectly with the current build, in the virtual machine. But, somehow the problem is seen only on physical machines” she says, with a sparkle in her eyes (that she might have just helped solve the mystery). Soon, the manager drops in with the latest update from the on-site team. “The problem is not seen in the current build on the physical machines running on Operating System X, while it is still observed on Operating System Y. Unfortunately, most our customers are running on Operating System Y. Good Luck!”.

No doubt there is a lot of information exchanged, a whole lot of such experiments conducted. These are only serving to add more variables to the equation, taking you further away from solution. Not knowing what to do next, he is on the verge of losing sanity. Not seeing anything that would come to his rescue, he digs deep, employs all those cool tools he had at his disposal. Several days of intense debugging, rewriting certain pieces of code, analyzing memory snapshots and CPU performance statistics at various intervals reveal that memory is getting corrupted. Further, analysis revealed that the thread from that third party library was populating the buffer faster than expected. The result was shared with the management. The third party admitted that the thread priority was changed in the last release. They promise to deliver a fix the next day.

Come next day, the problem is solved. Everybody is happy. Those 'MBA-Gods' in the top management, are all praises for the globally distributed effort to solve the crisis. Not to forget, “Good Job Done, Keep it up!” the gods blessed the developer!