Darrell Norton's Blog [MVP]

Fill in description here...

Fixing bugs is 80% learning, 15% patience, and 5% coding

I’ve been trying to help a client tackle a rather large list of issues (some might call them underappreciated program features), so I’ve been doing a grab-bag of various coding issues. Some JavaScript, some VB.NET, some web services, some database work, yikes! The possibilities on where the code was broken were huge.

I started working on one particular issue and saw some code that looked like it would fix it right away. I changed it and tried out the application. No change. I found some more code that looked like it needed fixing, and fixed it too. Still nothing. So I continued to fix away for the next 30 minutes, fixing nothing and wrecking pretty much everything else.

Finally I stepped back, undid my checkout, and went back to the original code base. I actually went in and figured out how the code really worked, and it was so much simpler than I had originally thought. It didn’t help that the code base was in marginal shape when I got there, but that was no excuse for “code and burn” debugging! I hate learning things I already know the hard way.

Published Feb 17 2004, 07:38 PM by darrell

Comments

Aaron said:

Fixing bugs usually sucks. You spend most of your time figuring out the problem, then a little time fixing it, then a lot more time making sure you didn't break anything else. And some "new-code only" developers think that it's easy. Ha!

# February 18, 2004 12:39 AM

Scott Galloway said:

And a few percent cursing, drinking, shouting at the screen and weeping quietly in a corner

# February 18, 2004 2:48 AM

Darrell said:

Scott - yes, much cursing. I believe the cursing is inversely proportional to the amount you know about the application. Currently knowing little about the domain, infrastructure, etc., I do a lot of quiet cursing (I don't want to offend the client!). :)

# February 18, 2004 2:54 AM

Dave Donaldson said:

When I get into these situations, I find that having a sequence diagram is very helpful. If the sequence diagram does not exist or is not current, then make it so. I've found that the effort to do this up front in the debugging process helps tremendously when trying to pinpoint a bug location, especially in large, distributed applications.

# February 18, 2004 6:27 AM

Darrell said:

Dave - I hadn't thought of using a diagram as a debugging tool... could be interesting. I have plenty of bugs to try it out on! :)

# February 18, 2004 6:31 AM

Darren Neimke said:

Darrell, I'm actually planning to blog about this in the coming weeks but... (and I'm sure that you already appreciate this) when fixing bugs, just make sure that you make lots of explicit comments about changes that you make to code that you know little about.

I like to make my comments such as:

- the bug number that the code change is fixing
- why I changed it and how the change altered behaviour
- downstream effects of the change

So, I'd end up with something like:

' COMMENT: DJN - #1765
' Previously the blah was being incremented at the bottom of the loop
' so, I've moved it to the top becuase the Foo
' Function that it gets passed to expects blah.

These kinds of comments will help not only you, but also the next poor soul that has a hand in maintaining a piece of complex logic.

# February 18, 2004 9:05 AM