Share via

Debugging process considered harmful

  • Article

The following is a result of personal experience on a number of projects:

* First of all, in general, you cannot install the debugger where the application you are developping will ultimately run. If you are writing a desktop application, there is no way you will be able to install a decent debugger there. If you are writing a server application, the operation team will probably not let you install the debugger of your choice on production servers! If you are lucky, you will be able to install a simplified debugger, like WinDbg that has almost no side effect. WinDbg just works for unmanaged code so far. I do not know any good standalone .Net debugger yet (w/o installing Visual Studio, that is). This is a real issue. If you have put all your debugging efforts in the Visual Studio debugger, putting your application in production is like sending a spaceship towards Mars without any communication with the ship: welcome to the unknown.

* Now, let's get back to the development phase. You have to think that, when someone debugs, he just works for himself. Debugging may only be benefitial to one person. There is no way to transfer the work he has done (setting breakpoints, stepping into code, ...) and the knowledge he has acquired on the program he was debugging (if any...) to someone else.
In a team development mode, the time spent by one individual on debugging is simply lost for the rest of the team.

* When someone debugs, he just does the same things (stepping) over an over agin, loosing precious time. He is just exchanging development (creativity) time with stupid "stepping" time. This is actually depending on the competency of the guy. A good developer will use good watches, good breakpoints and advanced debugging techniques. He will therefore loose less time than a beginner developer. Thus the next point:

* To debug efficiently, a developer needs to master a debugger, or worse a certain number of debuggers. Debuggers do not follow any real standards, beside some de facto common UI. Training should be required to be able to debug efficiently.

* If you manage developers and just take a look at the time the average developer in your team spends in the debugger, you should do something! But you can't because Debugging trainings are very very rare and Debugging books are very rare too. Here are two decent books about debugging https://www.amazon.com/exec/obidos/tg/detail/-/0735615365/ and https://www.amazon.com/exec/obidos/tg/detail/-/1590590503 (not only for vb.net)

This explains why I almost never debug. And I think my productivity is greatly enhanced. I trace everything. I agree this is not ideal (some call it "printf debugging"...), but that's just because no technical progress has been made in this domain. Today, putting traces everywhere is really prehistoric work. But that does not mean traces are bad, it just means nothing is there to help us add traces automatically to our code. I would like to be able to tell to the C# compiler: "put traces here and here, please remember the values of the parameters automatically, just like you do when I debug. Please add a hierarchical trace of this object, and please record all that that so I can replay it later, add filters, and so on...". That service should be provided by the CLR, IMHO.

Comments

  • Anonymous
    May 17, 2003
    http://log4net.sourceforge.net/
    http://nunit.org/
  • Anonymous
    May 17, 2003
    Yes, NUnit is how you SHOULD address these issues. Trace statements don't tell you what is broken, a properly designed test suite will.

    However, when it comes to tracking down a specific bug, then the debugger is invaluble. In VS.NET, it is drop dead easy to use and doesn't really take much training, if any. Debuggers aren't even meant to be used with production code, they are meant to be used in the developement phase, so you shouldn't ever attach to your live servers. With VS.NET, you can use remote debugging, but you should attach to a staging server, not your live servers. This staging server should duplicate the configuration of your live server, so you should almost never run into any issues that come up only once you have deployed to your live server.

    In any case, you really should start using the debugger.
  • Anonymous
    May 17, 2003
    Frans Bouma's blog
  • Anonymous
    May 17, 2003
    Fabrice's weblog
  • Anonymous
    May 17, 2003
    SBC DotNet Weblog
  • Anonymous
    May 17, 2003
    Simon Mourier's WebLog
  • Anonymous
    May 17, 2003
    The comment has been removed
  • Anonymous
    May 17, 2003
    http://dotnetweblogs.com/sbchatterjee/posts/7189.aspx
  • Anonymous
    May 29, 2003
    http://dotnetweblogs.com/fmarguerie/posts/7764.aspx
  • Anonymous
    January 11, 2008
    PingBack from http://msdn.blogsforu.com/msdn/?p=3657