Henrik Warne is a software developer in Stockholm, Sweden. He has been programming professionally for more than 20 years. Henrik is a DZone MVB and is not an employee of DZone and has posted 19 posts at DZone. You can read more from them at their website. View Full User Profile

4 Reasons Why Bugs Are Good For You

10.30.2012
| 5920 views |
  • submit to reddit

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 1 – 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?

Published at DZone with permission of Henrik Warne, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Sat, 2012/11/03 - 11:12pm

I'm not sure learning by example of what not to do is the best way to learn, but it does make you painfully aware of what bad practices are more common and which ones are the most damaging.

It is fun and satisfying to solve the focused mental challenge, the closest thing to being a detective (or a fireman).  The cause of the problem is rarely what you first guess it is.  I like predicting the cause, but I won't bet a nickel on it.

It is also immediately satisfying to fix code that someone else failed to make work, or fix properly, and code based on bad initial requirements or understanding of requirements.  Unless you are reinventing the wheel, with new development or features you are only competing with yourself and other design/implementation paths you could have taken.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.