The Artima Developer Community
Sponsored Link

Weblogs Forum
Debuggers are a wasteful Timesink

90 replies on 7 pages. Most recent reply: May 31, 2005 10:53 PM by Brian Slesinsky

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 90 replies on 7 pages [ « | 1 ... 2 3 4 5 6 7 | » ]
Greg

Posts: 18
Nickname: singleton
Registered: Jun, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 7:57 AM
Reply to this message Reply
Advertisement
Obviously your example is of an application where
your students have written ALL the code.
In an application that uses libraries or is a client
server app talking to something that you didn't write
inspecting your code will not do any good. I've seen
a lot of times when upgrades have broken perfectly
functional code because of changes in libraries and api's
that could only be identified with the use of a debugger.

Marc Clifton

Posts: 2
Nickname: cliftonm
Registered: Dec, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 7:59 AM
Reply to this message Reply
A little clear thinking regarding this subject might help to clear up this tripe.

First off, the author lures you into the idea that incredibly powerful tools waste time because they're so hard to learn, having so many features. This is an illusion. You use the set of features within the tool that are needed to solve the problem.

The second problem with this commentary is more insiduous. TDD merely shifts the time spend in debugging from the back-end to the front-end. Essentially, with TDD, you are "debugging" the code first, then writing it.

TDD is still debugging, but it uses a different tool--the unit test. This fellow seems to fail to recognize this. If you look at programming as two tasks--writing code and testing code (which includes debugging it), he's still spending the same (and probably more) time debugging. He's just doing it before writing code, rather than after.

Finally, using students to examplify the problem with debuggers is like saying jumbo jets are bad because your Cessna pilot can't fly it. They're students for a reason. I remember wasting time with a debugger because my skills at reviewing my own code were untrained. But guess what? The debugger became my training tool (and much better than any instructor at that!), and I began to use it less and less because I understand programming better.

Marc

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 9:20 AM
Reply to this message Reply
> A little clear thinking regarding this subject might help
> to clear up this tripe.

I agree. Let's shoot for it.

> First off, the author lures you into the idea that
> incredibly powerful tools waste time because they're so
> hard to learn, having so many features. This is an
> illusion. You use the set of features within the tool
> that are needed to solve the problem.

That wasn't the argument. The argument was that the debugger can be distracting for errors that can be found by inspection.

> The second problem with this commentary is more insiduous.
> TDD merely shifts the time spend in debugging from the
> back-end to the front-end. Essentially, with TDD, you
> are "debugging" the code first, then writing it.
>
> TDD is still debugging, but it uses a different tool--the
> unit test. This fellow seems to fail to recognize this.
> If you look at programming as two tasks--writing code and
> testing code (which includes debugging it), he's still
> spending the same (and probably more) time debugging.
> He's just doing it before writing code, rather than
> n after.

That sounds like an argument, but I guess you could say the same about writing formal specifications. Is that debugging before writing code? Maybe. Whether it is or isn't is irrelevant next to the more important matter of whether it is more cost effective to find bugs with a debugger or not put them in in the first place, and that is a simple one to answer.

> Finally, using students to examplify the problem with
> debuggers is like saying jumbo jets are bad because your
> Cessna pilot can't fly it. They're students for a reason.

Yes, because they are humble. I train beginners but also very experienced people. Some of them spend most of their professional lifes in debuggers. Some of them even write debuggers. When you are immersed in something, sometimes it is hard to see the alternatives.

> I remember wasting time with a debugger because my skills
> at reviewing my own code were untrained. But guess what?
> The debugger became my training tool (and much better
> r than any instructor at that!), and I began to use it
> less and less because I understand programming better.

Yes, and that's the ultimate goal.. to understand the program. Frankly, I think that debuggers can be pretty distracting in that regard, even for very experienced users.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 3:46 PM
Reply to this message Reply
You know, some people think computers are a wasteful timesink, so I suppose debuggers and TDD would also be, by extension.

I agree with Vince's sentiments on zealotry; a level-headed discussion of methodologies does a lot more to promote them than unbridled hyping of them does.

I like TDD pretty well in many cases and think it makes development fun, but I think it is certainly a style that some people may never be comfortable with. If they can still do a good job, that's just fine. There are also cases I've found where writing unit tests seems pretty infeasible, or at least not worth the amount of effort it would take.

In contrast, I haven't been too impressed with pair programming. Maybe I haven't done it right, but it seems a bit like those bean bag races, where you have one leg in a bag with your parter and try to outrun other teams. Lots of fun and laughs, but you're probably not going to be making an appearance at the Olympics with that strategy.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 3:47 PM
Reply to this message Reply
> As Manish observed though, many, if not most programmers,
> work with existing code that is a) undocumented and b)
> badly (i.e. incomrehensibly) written, and c) has no test
> suite (or any other reference bench mark). So, when
> they're presented with a bug to fix in code with which
> they're unfamiliar then it is simply impossible to write a
> unit test that throws up the problem until the code has
> been examined in detail. It is frequently equally
> impossible to inspect the code manually, unless you have
> the brain the size of a planet, simply because there are
> often too many variables, procedural calls and logic mazes
> to track in your head. In such circumstances a good
> debugger is worth its weight in gold.

I sympathize with this view, and agree that in such cases a debugger can be useful (though I've found that debuggers tend to fail just as the problem gets interesting.)

On the other hand, it seems to me that this is exactly the situation we'd like to avoid in our projects going forward.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 4:07 PM
Reply to this message Reply
> > Wouldn't it have been nice if the code had been written
> in
> > a clean and expressive way so that it told you how it
> > worked?
>
> Well yes it would, but that's just wishing in the wind,
> isn't it.

Not where the code that YOU write is concerned.

> In any case, bugged code doesn't tell you how
> it works. It tells you how it doesn't work. You can't
> always deduce intent from implementation,
> doubly so when the implementation is wrong.

When you cannot deduce intent from implementation, then the implementation is sloppy. As professionals we should strive to make our intent transparent in our implementation.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 4:23 PM
Reply to this message Reply
> > A little *too* clever sometimes. A print statement does
> > not (usually) interrupt the flow of execution.

> So says the person who's never seen a printf statement
> magically fix some broken code.

I've certainly seen that happen. I've also seen failures that magically disappear when you run the debugger.

> This is not unheard of
> (it happens because printf has a return value which
> normally ends up fixing some broken value on the stack
> which has resulted from improper initialization).

Or sometimes it happens because of the timing of the printf.

> Then I'll race you. You can type System.err.println(/*
> whatever's needed here */); or whatever precise mechanism
> you prefer for printf debugging, I'll type ctrl-b to get a
> new breakpoint, and we'll see who can do so quicker. I'd
> put money on it being me.

I just won that particular race a few weeks back with some other folks. Indeed, I won it several times in a row. It was the event that stimulated me to write this article.

In once case I was working with a group of folks who had gotten into the habbit of leaping into the debugger at the first sign of trouble. I had seen them do this over and over again. In one particular case they set breakpoints that happened to break in the wrong context, and they didn't know it. They thrashed around for a couple of hours trying to find out what was going on. Eventually I came over, looked at the code, put a couple of print statement in. Wrote a couple of unit tests, and had the problem fixed in 15 min.

Don't get me wrong. I'm an old hand at using debuggers. I've been programming for over thirty years, and I'm pretty good at using power tools. I went through my period of depending on debuggers. Then I went through a period of being disillusioned with debuggers. Now simply relegate them to the big power tool shelf in the back of the garage and only pull them out when absolutely necessary.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 4:31 PM
Reply to this message Reply
> I'd like to add another context: developing device drivers
> or working with new hardware. In these cases debuggers are
> pretty much needed from day one. How are you going to deal
> with buggy hardware? How are you going to deal with a
> device driver that spontaneously reboots your system when
> it hits an unforseen event? Bob, would you say that kernel
> debugger and SoftICE are wasteful timesinks?

I think such projects would be at extreme risk if you didn't have those tools. I also think that every time you fire one of those tools up, you should put $5 in the kitty for a group party.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 4:53 PM
Reply to this message Reply
> What I do object to - strongly - are assertions to the
> effect that TDD is the pinnacle of perfection and that
> only by using it can you have bug free code.

I also object to such assertions; though I understand how enthusiasm sometimes causes them to be uttered.

> Talk of
> 'gospel', 'heresy' and 'brilliant sunshine' is the
> unhealthy language of dubious cults not rational discourse
> and XP attracts too much of it.

Please take this next metaphor in the pragmatic spirit is is given; not as a glorification of XP.

<<Lightbulbs attract lots of bugs.>>

The solution, of course, is not to get rid of lightbulbs. The solution is to invest in screens. It's not a perfect solution, but we live with it because we like having the lights on.

Steven E. Newton

Posts: 137
Nickname: cm
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 3, 2003 6:26 PM
Reply to this message Reply
> As Manish observed though, many, if not most programmers,
> work with existing code that is a) undocumented and b)
> badly (i.e. incomrehensibly) written, and c) has no test
> suite (or any other reference bench mark). So, when
> they're presented with a bug to fix in code with which
> they're unfamiliar then it is simply impossible to write a
> unit test that throws up the problem until the code has
> been examined in detail. It is frequently equally
> impossible to inspect the code manually, unless you have
> the brain the size of a planet, simply because there are
> often too many variables, procedural calls and logic mazes
> to track in your head. In such circumstances a good
> debugger is worth its weight in gold.
>
In their book, Object Oriented Reengineering Patterns, Demeyer et all list 20+ different techniques for understanding and working with existing code. Only one pattern mentions the debugger, and it has a prerequisite that the programmer must have sufficient understanding of the code already in order to develop specific scenarios in which to single-step with the debugger. This seems to state the obvious -- a programmer can't single-step through every line of source, so some understanding is necessary before the debugger can even be started. The next level is to keep working on that understanding, rather than breaking out the debugger as soon as you have a hunch, and soon enough it becomes possible to dispense with the debugger in nearly every case.

> Now that you understand the code that was at fault, you
> are in a position to write a unit test that will pick up
> the bug - that no longer exists. The purpose of doing
> this would be to potentially aid maintenance programmers
> in the future.
>
I've always wondered how programmers can determine that some piece of code is failing if there isn't a test. If a test can be written to determine that the fix works, a test could have been written to exercise the bug -- why not write that test first?

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 4, 2003 6:04 PM
Reply to this message Reply
> As a Java programmer, I haven't used a debugger in several
> years. Nor have I spent a significant amount of time
> debugging. I attribute both to the disciplines of TDD,
> Refactoring, and Pair Programming. I also attribute them
> to a desire to avoid the debugger addiction.

Must be nice to work all by yourself on only your code. As a Java victim, I find not only do I increasingly need a debugger but also a decompiler to cope unexpected behavior in the excessively complex frameworks that are so popular among the J-unkies.

For instance, I recently installed a commercial J2EE application server on an unsupported platform for development (OS X) and couldn't understand why the damn thing wouldn't take my password. In exasperation I decompiled the entire app server and set breaks in the auth code only to find the stupid thing was doing some non-portable byteswapping.

So long as the skill level of the average Java developer remains at the level of the current average Java developer, I will continue to need more advanced tools to untangle the latest fad framework.

That doesn't even begin to address my need for setting breakpoints in xml parsers because their error reporting is so bad or I can't tell which of the 654 xml config files is actually generating the error without looking up the stack.

With Java, I need debuggers more than ever before - for other people's code.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Debuggers are a wasteful Timesink Posted: Dec 4, 2003 11:51 PM
Reply to this message Reply
> Please take this next metaphor in the pragmatic spirit is
> is given; not as a glorification of XP.
>
> <<Lightbulbs attract lots of bugs.>>
>
> The solution, of course, is not to get rid of lightbulbs.
> The solution is to invest in screens. It's not a perfect
> solution, but we live with it because we like having the
> lights on.

I tried but I despair. The trouble with dodgy metaphors (XP as brilliant sunshine, XP as a lightbulb, etc.) is that - though they look good at first sight - they are too often a distraction and a barrier, not an aid, to understanding.

I mean, what does "invest in screens" mean in this context? My second guess was fly screens not PC screens (here in the UK fly screens are rare, PC screens common). Am I right? Maybe. To find out, we now have to disect the metaphor and therefore we have now completely lost sight of the original discussion and all we are left with is discussion that is little better than "Oh yes it is!", "Oh no it isn't".

Vince.

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 5, 2003 6:15 AM
Reply to this message Reply
> I decompiled the entire app server and set breaks in the
> auth code only to find the stupid thing was doing some
> non-portable byteswapping

Too bad that code didn't ship with a full suite of test-driven programmer-tests... those make porting so much easier. TDDing would have put the byte-swapping in a small function with a unit test, and that test should fail if run on a platform that didn't support the assumptions of the code.

We're all going to remain victims if we continue to accept software without test-suites; if we continue to support the status quo.

Javid Jamae

Posts: 16
Nickname: javidjamae
Registered: Jan, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 5, 2003 8:44 AM
Reply to this message Reply
How about a slightly different approach to either debuggers or print statements?

I picked up the idea of using assertions in my code. In the Java world, I use the static assert methods on JUnit's Assert class.

Assert.assertEquals(..);

I would definitely argue that you should write tests, even if the code is untested otherwise. But while debugging, these assertions can be great help. In many instances, assertions can be left in the code.

This is moving more towards a design by contract type of model. I think there is a lot of room for exploration here.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 5, 2003 10:08 AM
Reply to this message Reply
> Too bad that code didn't ship with a full suite of
> test-driven programmer-tests... those make porting so much
> easier. TDDing would have put the byte-swapping in a small
> function with a unit test, and that test should fail if
> run on a platform that didn't support the assumptions of
> the code.

I don't see how that would help at all.

First - its a very popular commercial appserver and I had to grab the windows version. They ship other versions for other platforms but in a Java world this strikes me as stupid. I'm sure from their perspective that there is nothing wrong with this code. If I filed a bug on it I would be told that this is not supported and that it is not INTENDED to be run on a non-windows system. The fact that I got it running at all is bloody lucky (and probably violates the license agreement but I have to support the client's app - which has a valid license).

Second, unit tests aren't all that useful without source code. There's no substitute for looking up the stack to figure out how you got the bad data that you were passed.

Actually, this sort of points up my other huge complaint about planned vs unplanned reuse. Java is designed to support planned reuse (rigid interfaces, static typing, blah blah blah). My estimate is that more than half of code reuse is unplanned and Java as a langauge is hostile to casual reuse.

>
> We're all going to remain victims if we continue to accept
> software without test-suites; if we continue to support
> the status quo.

And without source code. But the bean counters buy this garbage and we are supposed to make it work because its a "standard".

Flat View: This topic has 90 replies on 7 pages [ « | 2  3  4  5  6  7 | » ]
Topic: A Real-World Example of a C++ Contract Verification Class Previous Topic   Next Topic Topic: C++ Meta-Binders

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use