Motley says: "Rely on the debugger to write solid code"

  • Article

 

Summary

 

Motley: I rely on the debugger when I am writing code. Without it, I'd have a really hard time tracking down all the bugs in my code.

 

Maven: Write code as if the debugger does not even exist. Include unit tests, assertions, tracing, logging, static analysis, and internal consistency checks in your code to pinpoint problems as they occur. Time in the debugger is generally not efficient.

______________________________

 

[Context: Maven interrupts Motley as he is debugging some code]

 

Maven: Hey Motley. What are you up to?

 

Motley: Just debugging some code I just wrote. The debugger is every developer's best friend don't you know.

 

Maven: Actually, when I am writing new code I try and avoid the debugger at all costs. It is my most inefficient time spent as a developer.

 

Motley: Avoid the debugger?!?! You're insane! How can I expect to get my job done without the debugger. It lets me see the current state of my application and figure out why things went awry. Do you really have any experience in this industry?

 

Maven: How long does it take you to debug a typical problem using the debugger?

 

Motley: It depends on the problem of course. On average I would say it takes me about 15 minutes to come up with a decent repro and then another 15 minutes to get to the bottom of the issue. From there the fix is usually just a couple of lines and I'm off and running to the next issue. I suppose now you are going to tell me that your code is bug-free?

 

Maven: Of course not. Writing bug-free new code is next to impossible. Even "Hello World" typically has bugs. BUT, when I am writing new code I like to think the debugger doesn't even exist.

 

Motley: Boy, I bet you are really efficient. Can you sense my sarcasm?

 

Maven: You bet - I AM efficient. By incorporating the right level of unit tests, debug assertions, tracing, logging, and embedded self-tests, I can get to the bottom of an issue in no time. In fact, I can usually nail down the exact lines of code that caused the issue in a few seconds flat.

 

Motley: Did you say "unit testing"? That's the test team's job! I am not paid to write tests.

 

Maven: Oh jeez. One thing at a time - we'll have the unit testing conversation next. In the meantime, try inserting some defensive programming techniques into your code, like debug assertions and tracing. Not only will they help you get to root of an issue more quickly, but they will also help the support team once your software ships in the unlikely event a problem occurs. An assertion that fires provides an immediate indication that something is wrong and gives some great information about the error - as long as you take care writing your assertions.

 

Motley: By assertions you mean something like System.Diagnostics.Debug.Assert in my .NET code, right? I supposed I could sprinkle a few more in there. Including more debug traces would be easy. Unit tests? Not a snowball's chance in a high temperature furnace!

 

Maven: Okay, at least that's a start. The support team will thank you, and your time spent in the debugger will be minimized. I guarantee that the little bit of extra effort expended to incorporate those things into your code will still give you back lots of the time you would have otherwise spent debugging.

______________________________

 

Maven's Pointer: Use every tool in your arsenal to tell you about problems in your code before they appear. That involves running tools like Visual Studio's built-in code analysis (FxCop and PREfast) and cranking up compiler warnings to the highest level.

 

Maven's Resources: Code Complete 2nd Edition, by Steve McConnell, Microsoft Press, ISBN: 0735619670, 2004.

Comments

  • Anonymous
    April 21, 2009
    Summary Motley: There is no harm shortcutting a few steps of development to meet a deadline. Some up-front