Monday, April 9, 2012

An Ode to Debugging

The first code that I wrote had no bug. It was almost copied verbally from a reference material and printed "Hello World!". More I entered into the world of coding, more bugs appeared and slowly it became a part of life. So much so, that I can write a small post (as this one) on the experiences and a big post (as one outlined here and to appear in future) on the philosophy of bugs.

The origin of the term "bug" came from a moth, which was trapped in an electromechanical early-age computer (see here ). That led to the term "debugging", which means getting rid of the bug.

Bugs are of such importance that there are entire new subjects on discovering and killing the bugs formally (aka formal verification) much before the software is actually executed. Bugs control, in a sense, both the fame and fall of a product. While a high number of bugs may create poor user experience to kill the product prematurely, naughty product companies remain happier when you license a product and face a bug. That forces you to get newer products and pay renewal fees. This led to the famous phrase depicted below.


Bugs represent another thing to me, the truth. Truer the software, less the number of bugs. The pursuit of truth is hard, to say the least. We lazy dwellers of the world, remain happy with our half truths and thence, bugs keep appearing. It takes relentless effort to claim that what you wrote in a piece of software to be "true". It comes in the way of practicality, some will say. Of course, so does the truth. Who said truth is practical ?

Hopefully, there exists such devoted seekers of truth. Like, Donald Knuth. Knuth is known to be the first mathematician to take computer science seriously. He started writing his magnum opus, the art of computer programming and soon got frustrated with the then state-of-the-art typesetting software. He took a break and wrote Tex. Tex had as few bugs as possible and Knuth famously said that "I believe that the final bug in TeX was discovered and removed on November 27, 1985. But if, somehow, an error still lurks in the code, I shall gladly pay a finder's fee of $20.48 to the first person who discovers it. (This is twice the previous amount, and I plan to double it again in a year; you see, I really am confident!)". Well you can say that your design is error-free if no one uses it. But, Tex is the de facto standard for documentation work in scientific community. By extending this, it is easy to claim that the piece of software carries the signature of your mind. Just like the handwriting analysis, one can read a code and decipher, to some extent, how you think.

Let me end the note with two bug stories. I was a rookie software developer struggling with a performance bug for few days in a small company. Performance bugs are different from functionality bugs. Functionality bugs lead to wrong results. Performance bugs are trickier. Those consume huge memory or execution time. In my case the execution was more than 10 hours. Fixing it requires me to run it for hours and checking where the memory consumption goes up or where it gets stuck in a large function. The horror continued for one week or so when, a helpful senior offered me to have a look into the code. I readily agreed. He glanced through some header files and asked me to just check if a particular define value is set to 10. I found and removed it. Believe it or not, the code ran, without error, in 15 minutes. He tried to reduce my shock by explaining some technicalities. It had to do with a particular backward compatibility mode, required for some very old machines. He just remembered the define value, by sheer luck. He also mentioned the name of an old colleague, who introduced that define in an arbitrary manner. He took my shock in a philosophical view and told me - "See, this is the result of bad work, Karmafal. But, no one knows who is suffering for whose bad deeds. The arrow of work and result is quite complex, just like it is in the illusory world around us." I remembered it every time I had to hand over a piece of code to another colleague.

The second story is a more optimistic note about bugs. I was toiling on my own field i.e. trying to discover a bug that I added sometime back in the code. After some effort, I went to a senior colleague to explain the problem. He had his fair share of knowledge about the code as well, contributing some designs from time to time. He laughed heartily at me after hearing the problem report. I was curious. He said - "I can fix that, I do not know how but, I can corner it with test inputs and then see for myself inside to code to destroy it. Actually, I take such fixes for my breakfast." That was a freeze-frame moment for me. A bug for breakfast. He just taught me to enjoy debugging and I enjoyed it ever since at least as much as I enjoyed coding.

4 comments:

  1. Looks like you are quite senior now who is being served regularly with nice breakfasts, but is suffering with a stomachache due to a little too much appetite .. ;-)
    Not sure.. you motivate me or demotivated... should I be happy to debug, or miss a experienced senior...!
    Well, I can just hope that the plate for your breakfasts now-a-days is not called PD...!

    ReplyDelete
  2. @B work without expectation, if could be done, gets the beauty.

    ReplyDelete
  3. Hey Professor, so if philosophically, 'bugs' in the software are like 'bad deeds' in real life, then what's the equivalent of a 'debugger' in real life?

    ReplyDelete
  4. @the Rhymer..the Rambler, the flow of Karma is beyond my comprehension. We cannot say why we suffer sometimes :-) . We all feel the way in life and we feel similarly in software, too. Isn't it ? Just fix the bug and be merry that you are leading the world to a cleaner future :-)

    ReplyDelete