4 Reasons Why Bugs Are Good For You

Every once in a while I read something along the lines of: “most developers just want to write new features, they don’t want to work with maintenance and bug-fixing”. If that’s true, then most developers are missing out on the fun and benefits of finding and fixing bugs.

Each bug can teach you something

Feedback is one key to developing better products. It’s one of the primary tenets of agile development. Unit testing and iterative development are both techniques to provide feedback faster. With unit testing you get feedback on whether the code works, and with each delivered release you can hear what the customer thinks of the new features. A bug report is another form of feedback on your code.

There can be many different causes of a bug. Some possibilities are: a simple coding mistake (like a nested if-statement where you end up in the wrong branch), or a faulty assumption on your part (maybe the incoming messages don’t always have certain fields present, so you got a null pointer exception), or there is a missing requirement (you should have answered the message in a different way if a given parameter is present), or the customer is using the software in an unanticipated (but correct) way, leading to bugs.

In each of these cases, you can learn something about how to code, about your product, or about the domain it operates in.

For example, when I developed VoIP products at Tilgin, there was a case where we received a faulty message that caused our software to loop indefinitely. The messages contained elements encoded using tag-length-value (TLV) parameters, where the length value was the total length of the element. This way you can skip unused or unknown elements by jumping forward “length” number of bytes. In this case, the length value was zero, so after the skip we pointed to the same element we pointed to before the skip, causing an infinite loop.

Before this bug, my code carefully checked length values for too big values that would cause a read past the end of the message buffer. However, up until then, it had never occurred to me that a length of zero could be just as bad.

Your Own Code Becomes Easier To Debug

When you spend time trouble-shooting problems and fixing bugs, it doesn’t take long until you want to make your own code as easy as possible to debug. It is frustrating not having all available information presented.

One extremely common problem is exceptions that don’t include dynamic information. For example, suppose there is code that expects a value to be in the range 0 – 20. How many times have you seen an exception that just says “Illegal value”? That doesn’t tell you much if you are trying to find a bug. If for instance 21 was received, it should say something like “Illegal value: 21, not in range 0 – 20”.

It helps to include the allowed range, and it definitely helps to include the current value. The current value could be 21, or -128, or 65535. All of those could give you a clue as to what caused it, which you don’t get from a plain “Illegal value”.

Even Steve McConnell breaks this rule in some places in the excellent book Code Complete. For example, in chapter 15 there is an example where an unexpected type of character is detected, but the error message doesn’t include the character in question.

Every time you find and fix a bug, you need to ask yourself: is there anything in my code I should do differently in order to eliminate bugs like this in the future? Is there anything I should be doing to make trouble-shooting this kind of bug easier in the future? This is very fertile ground for improvements.

Both You And the Customer will be Happy

As I mentioned in Why I Love Coding, one of the joys of programming is making something that is useful to other people. You get the same kind of kick out of fixing a bug, but on a different time scale. Delivering new features usually takes a while, but a bug-fix can be done in an hour. Each fixed bug makes you feel you are accomplishing something, and that’s a great feeling.

It’s a bit of a paradox that fixing a bug will make the customer happy. If there wasn’t a bug in the first place, there wouldn’t be a need to fix it, so why should they be happy? However, my experience is that they are happy to receive a bug-fix, especially if it is solved quickly. Everybody knows that there will always be bugs. What matters is that somebody is ready to fix them quickly when they are discovered.

Solving Problems is Fun

Many programmers enjoy solving problems, like mathematical puzzles, programming challenges, Sudoku or crosswords. Even reading murder mysteries feed into this: you look at the clues and try figure out how it happened.

Debugging and fixing bugs is the same. Each bug is a new mystery to figure out. Often your first reaction when seeing a new bug report is: that’s impossible? How could that happen? That’s when you start looking for clues. What do the logs say? Any error reports from the system? What else happened in the system at this time? Was anything changed recently – new software, configuration changes, traffic disturbances? Let the figuring-out begin!

These are four reasons I like debugging and bug-fixing so much. What is your experience?

10 responses to “4 Reasons Why Bugs Are Good For You

  1. Hi Henrik,

    I totally agree that solving bugs makes the person learn something new.

    However, it’s important to document what you did to solve a bug – programmers usually have many tasks and solving an identical bug in a month may take the exact same time if it’s not documented.

    Thanks for sharing!

  2. Pingback: Why Software Bugs Are Good For You | My Daily Feeds


    No programmer would disagree, but that was never the question. Without bugs, we’d still be solving problems.

    The *relevant* question is whether it’s more fun to solve old problems again, or solve new problems for the first time. I, for one, never find the former more fun.

    Losing one’s car keys is a puzzle, too, but that doesn’t mean it’s fun, or good for me, or will make me happy.

    • Good point Pete! However, you could argue that you are not really solving the old problem again, since if it was solved properly the first time, there wouldn’t be a bug 🙂

  4. Pingback: Programming blogs that don't suck - Methodical Programmer

  5. This is a very interesting article.
    According to my experience, most programmers don’t like(hate) bugs in their own code, but ok with bugs in others code, as long as those bugs are not assigned to them for fixing.
    But I like bugs because every time I fixed one, I became a better programmer than whom I was before fixing it.

  6. Pingback: Von Bugs, Fehlern und Chancen: Wie Sie Bug-Tagebücher als Lerninstrument nutzen - JAXenter

  7. Can I translate your blog to my chinese blog?and the more chinese coder can learn something from you.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s