The Adventure of the Noble Engineer - The Art and Science of Software Debugging

For folks who are not familiar with Sherlock Holmes, the title paraphrases the story "The Adventure of the Noble Bachelor," an adventure where a gentleman is faced with the disappearance of his bride under mysterious circumstances. Not much unlike the software engineer who lovingly crafts her code, only to find it go rogue and do something completely unexpected.

Having established my credentials as a Sherlock Holmes nerd, let's get to the topic at hand. Like any other aficionado of Holmes, a good mystery to be solved gets me all excited. Looking at our world through this lens, some of the complex software issues that we see can throw up enough intrigue for Holmes to throw on his long coat and deerstalker cap and call out to his trusty partner, "Come, Watson! The Game's afoot!"

"The clues"

In all crime scenes, the perpetrator leaves clues, and Holmes wants to be there first before the flat-footed Lestrade and his team from Scotland Yard come and trample over everything. And so it is with software, gathering the clues in the form of logs and traces before they get trampled over time. Here, the perpetrator, the engineer who has written the code, ideally leaves clues willingly and intelligently. But the software detective better have a virtual "Holmes" on the scene, collecting data when it encounters anything suspicious (read as logs, events, or traces), lest the clues be overwritten and lost forever.

"Repro?"

Holmes could hardly ask for a murder to be committed again for him to solve the crime! Instead, he would recreate the sequence of events in his mind, working from the clues he observed. Well-written code should similarly provide enough clues to allow our software detective to recreate the issue in their mind and possibly simulate the conditions so as to test the theory.

"You see, Watson, but you do not observe."

Everyone is capable of seeing the same clues, but a good detective is able to focus on relevant aspects and put pieces together to construct a theory of what might have happened. For our software detective, gleaning out what went wrong requires thoughtful introspection and analysis—imaginary pipe in hand—poring over hundreds of logs, filtering out relevant information from the clues offered, and reconstructing the sequence of events of what might have happened.

"Knowledge and Tools"

Watson, shortly after meeting Holmes for the first time and trying to guess his eccentric roommate's profession, assesses his abilities as being very proficient in Chemistry, having a good knowledge of Anatomy, having practical knowledge of law, and being an expert boxer and swordsman. In other stories, Holmes would display his knowledge of soil type across London to identify where a person had been merely by looking at their shoes. The point here is that Holmes used his knowledge and the tools of his time to be at the top of his game. Our software detective, similarly, needs to be proficient not only in the code she writes or maintains but also in modules that the code interacts with as well as the system architecture as a whole. It is also important to be proficient in using the tools available, whether to debug difficult issues like memory or stack corruption or to profile a piece of code to improve performance.

"When you have eliminated the impossible, whatever remains, however improbable, is the truth."

Debugging a software issue can take us down many rabbit holes. It is important to have a way to eliminate the different possibilities one by one so that we can focus on the real reason for the failure. Elimination requires creating and testing hypotheses and finding proof in the clues available on whether a hypothesis is impossible or improbable.

"The Curtain Rises."

In the final scene, Holmes takes great pride in explaining the details of how he solved the mystery to a bewildered but admiring audience, basking in the glory of a job well done. Even the great Holmes required admiration and recognition to keep him going! Engineers solving complex software problems need to be accorded the recognition and super-elite status they deserve. Writing good code is tough; solving complex software issues is a whole order of magnitude tougher.

At the end of a day of intense code making and breaking and introspection while taking puffs out of our philosophical pipes, the smoke begins to clear, revealing a whole new perspective on software engineering. Putting our pipes down and walking over to the window to gaze over the endless skyline of this exciting world, it is for us to embrace the chaos and take it head on, because, after all, "It's Elementary, my dear Watson."

#debugging #software #elementary #sherlockholmes