The Artima Developer Community
Sponsored Link

Weblogs Forum
Debuggers are a wasteful Timesink

90 replies on 7 pages. Most recent reply: Jun 1, 2005 1:53 AM 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 | » ]
Steven E. Newton

Posts: 137
Nickname: cm
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 1, 2003 8:28 PM
Reply to this message Reply
Advertisement
> http://www.etnus.com/Support/papers/caltech.html

A paper touting the benefits of debuggers on the website of a company that builds debuggers -- a good question to ask in this case is "Who benefits the most if this view is correct?". Also note that the example is C/C++, and the focus is optimization, not correctness. A good performance analysis tool is probably a better solution in this case.

Also, for most software being built today, developer efficiency is far more important than run time efficiency.

Susan Jolly

Posts: 6
Nickname: brllady
Registered: Nov, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 1, 2003 9:56 PM
Reply to this message Reply
Also, for most software being built today, developer efficiency is far more important than run time efficiency.

One arena where run time efficiency matters is in High-Performance Computing. Some of us like working with the state-of-the-art. (Smart people, good pay, chance to affect scientific progress, ....)

Javid Jamae

Posts: 16
Nickname: javidjamae
Registered: Jan, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 1, 2003 11:26 PM
Reply to this message Reply
From my experience in several XP environments, with fairly well tested code, you usually don't need the debugger while using TDD and pair programming (not to be confused with mentoring). By no means do I explicitly try not to use a debugger, but with small incremental TDD, we usually know exactly what has happened since the last non-passing test that we wrote.

On the other hand, I will not hesitate for a second to choose the debugger over a print statement. Print statements are non-transparent (they go right into your code), they don't visually tie the output to the source of the output ("what line of code printed that again?"), they are non-interactive (you can't look at any data that you didn’t print), and they are time-consuming and messy to write.

I have worked with people who are very stubborn about not using the debugger, and to be honest, it can be annoying. They spend so much time typing out print statements, while I could have the answer in front of them in a matter of seconds using the debugger (because I'm good at using it). I usually end up snatching the keyboard away from people like this in a pair-programming environment.

The debugger in my IDE of choice, Eclipse, is very simple and powerful. It does "hot swaping", meaning that it dynamically reloads the code during the debug session so you don't have to re-launch the thread to get back to the point where you were after making code changes. It has great features for enabling and disabling breakpoints. This is useful for when you want to set a breakpoint, but only enable it when you are in the correct context. It also has a layout and presentation that is optimal for visual inspection of the code that is executing, while looking at your variables.

No doubt, it is an art to know when, when not, and how to use the debugger effectively. It's also a matter of personal preference, I guess. While I think that it's well worth learning to use the debugger, I think it's infinitely more important to learn how to do TDD really well.

Javid Jamae

Posts: 16
Nickname: javidjamae
Registered: Jan, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 1, 2003 11:32 PM
Reply to this message Reply
> Also, for most software being built today, developer
> efficiency is far more important than run time
> efficiency.

>
> One arena where run time efficiency matters is in
> High-Performance Computing. Some of us like working with
> the state-of-the-art. (Smart people, good pay, chance to
> affect scientific progress, ....)

They never said run-time efficiency doesn't matter, they just said that developer efficiency is far more important.

I've worked on several applications where run-time efficiency was paramount. That didn't change the fact that the ability for developers to update and maintain the software was significantly more important.

If you need an ultra-fast system, but it takes your developers 2 weeks to fix a bug that should take a few hours, then you're going to have much bigger problems than worrying about what type of throughput your system can handle. You're going to be fighting to keep your project alive because you're running out of money.

Ashley Herring

Posts: 2
Nickname: agherring
Registered: Dec, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 1, 2003 11:54 PM
Reply to this message Reply
Well, I seem to have come into this thread a little late - that's the problem living at GMT+11!

This sort of conversation regularly comes up in programming discussion groups. Typically you get a bunch of people coming out of the wood, proudly declaring "I don't debug because I write brilliant code".

Well, just a few points on why in the real world, you need debuggers, and you need good ones!

* The term "Debugger" is a bit of a misnomer, because it is also an interactive learning tool for exploring the way a program works. Hence, more often than not I've fired up a program in a debugger, not to debug, but to understand how it works. This is particularly important when you inherit somebody else's codebase!

* "You can understand code just by reading it". Bullshit. Quite simply, utter bullshit. Why? Code describes the static structure of a process. A debugger allows you to look at the dynamic behavior of a process in action. No matter how smart you think you are, the number of states a non-trivial program can be in is vastly more than the mind can comprehend by "reading the code". How often does a innocuous looking method turn out to have a bug in it that only occurs as a result of an seemly unexpected sequence of inputs? Looking at the code, you don't even consider analysing how it would have behaved in that situation, because it "will never happen" thinks the developer. Then you fire up the debugger and surprise, surprise, it *does and did happen*. Why? Because the developer is not the user, and will frequently overlook common input situations. Debuggers provide a way to understand what is occurring in these unexpected, but commonly encountered situations.

Keep in mind, a "bug" is rarely as obvious as finding something like an incorrectly assigned reference - ie, something an "experienced" developer will pick up through a code review. Typically a program "bug" is not a code bug, but a design bug that did not take into account a certain scenario. The code looks fine, and may be 100% correct for the purpose it was designed for, but the "bug" is that there is a scenario that the design of the code never took into account.

* This above situation - programs behaving unexpectedly due to input unexpected by the developer, but in reality a common input in production/"the real world" - is why unit tests by themselves are not the answer. Unit tests are written by developers to test the *expected* behavior of their programs. Unit tests are a great QA & development tool - they improve the quality of the code, but they are not a 100% replacement for a debugger. Why? Programs do crash, and when they do, it's not necessarily because of bad design, or lack of unit testing, but because something unexpected has occurred - something so unexpected, there was no unit test for it.

* Unit tests are exactly that: a test on a self-contained unit. Programs are made up of a multitude of interacting units. The number of interactions in any non trivial system is so large that for it is a practical impossibility to write unit tests that consider every possible scenario.

* Programs crash, have bugs, run slow etc, not because a developer has deliberately coded them to behave like that, but because the actual way the program behaves does not match the conceptual model the developer has of how the program should behave. A debugger provides a way of verifying that your conceptual model matches the actual behavior of the program.

Whilst I agree with the original poster that debugging can be a drug and a lazy first stop analysis, I disagree that it's use should be discouraged. If a problem occurs, I tend to analyse the code, form a hypothesis of what is going wrong, then fire up the debugger to test that hypothesis, *before* engaging in any extensive refactoring. The idea of rewriting the "offending" code before running the original code through a debugger is just ludicrous - what if what you think was the "offending" code was actually not the real problem. Too bad, you have just spend 4 wasted hours recoding the wrong code, when 5 minutes with a debugger would have verified if you had correctly identifier the problem.

Patrick Wilson-Welsh

Posts: 5
Nickname: padraig
Registered: Oct, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 1:19 AM
Reply to this message Reply
All gospel begins as heresy, and once again, RCM is spot-on.
An excellent debugger in the best of hands can never give you as fresh detail or as good detail as good unit tests.

The more you need your debugger, the less you probably know about test-driven development, and the less you probably know about the code. The debugger is a tiny post-facto flashlight in a vast scary darkness. TDD is brilliant sunshine everywhere, all the time.

Another metaphor: You don't want DE-bugging. You want PRE-bugging. Only TDD and refactoring can catch every bug in its larval stage.

DrPizza

Posts: 3
Nickname: drpizza
Registered: Nov, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 5:31 AM
Reply to this message Reply
> Imagine a server-type program (a Mud gamedriver in fact)
> which crashes once a month after several hundred users
> used it. It crashes always with a memory corruption at the
> same place, after having executed the same piece of code
> without a problem millions of times. Obviously the actual
> corruption happens someplace elsewhere in the code, at
> some unspecified time before the crash.
>
> I fail to see how a debugger or unit tests would be
> helpful in this kind of situation.
Never used a JIT debugger? Or a crash dump?

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 7:15 AM
Reply to this message Reply
Oh please! What is it about Extreme Programming that engenders so much of this nonsense from so many of its adherents. I think it does more damage to the acceptance of XP than any else I can think of.

> All gospel begins as heresy, and once again, RCM is
> spot-on.

Classifying all opinions on software development as either extremes of 'gospel' or 'heresy' is - at best - unhelpful, and does nothing to promote a sensible discussion of an opinion. No-one has suggested that Robert's views are heretical and equally (at the risk of putting words in his mouth) he would not expect what he says to be treated as gospel.

> An excellent debugger in the best of hands can never give
> you as fresh detail or as good detail as good unit tests.

The basis of this sweeping statement about the relative abilities of all other programmers is what?

> The more you need your debugger, the less you probably
> know about test-driven development, and the less you
> probably know about the code.

Again, this is a sweeping and muddled statement, made without any basis in fact. Pretty much all the arguments here in favour of use of a debugger have been related to its use for debugging not development. They were made in response to an article that appeared to argue against all uses of a debugger.

> The debugger is a tiny post-facto flashlight in a vast scary darkness. TDD is brilliant sunshine everywhere, all the time.
> Another metaphor: You don't want DE-bugging. You want
> PRE-bugging.

I think we've now wandered completely off the map with respect to rational argument and into the realm of New Age voodoo talk. It does nothing to encourage others that you know what you are talking about.

> Only TDD and refactoring can catch every bug
> in its larval stage.

TDD is one of many useful development tools. If you think you can rely on it to 'catch every bug' then you are badly mistaken. TDD will only catch those bugs that generate problems that you decided in advance to test for.

Refactoring does not catch bugs. Refactored code is functionally identical to the code started with.

Vince.

Kelly R. Denehy

Posts: 8
Nickname: kdenehy
Registered: Dec, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 10:16 AM
Reply to this message Reply
You can understand code just by reading it". Bullshit. Quite simply, utter bullshit.

Wow. Strong words. I haven't used a debugger in the way you suggest for at least 10 years. I think one can visualize the system when running (at a high level, without all the tiny details) - perhaps it's a skill that takes time to develop. Whether using the debugger helps or hinders the development of this skill, I don't know.

How often does a innocuous looking method turn out to have a bug in it that only occurs as a result of an seemly unexpected sequence of inputs? Looking at the code, you don't even consider analysing how it would have behaved in that situation, because it "will never happen" thinks the developer.

Hmmm, my gut reaction to this statement is "that's a sign of a bad programmer". Don't assume anything. Expect the unexpected. Test for all boundary conditions.

This above situation - programs behaving unexpectedly due to input unexpected by the developer, but in reality a common input in production/"the real world" - is why unit tests by themselves are not the answer. Unit tests are written by developers to test the *expected* behavior of their programs. Unit tests are a great QA & development tool - they improve the quality of the code, but they are not a 100% replacement for a debugger. Why? Programs do crash, and when they do, it's not necessarily because of bad design, or lack of unit testing, but because something unexpected has occurred - something so unexpected, there was no unit test for it.

You're wrong. It is because of lack of unit testing. If you don't believe me, then tell me that, after finding the root cause of one of these crashes, you couldn't build a unit test to test for those crash-prone conditions.

Unit tests are exactly that: a test on a self-contained unit. Programs are made up of a multitude of interacting units. The number of interactions in any non trivial system is so large that for it is a practical impossibility to write unit tests that consider every possible scenario.

The unit testing for a non-trivial system isn't trivial. To do it right takes a lot of work (or FUN, as the TDD crowd would say) but to not do it means that you're basically saying "we hope this code doesn't have bugs, but it's just too darn complicated to be sure, so let's just put it out there and then when a bug is discovered we'll use the debugger to find the root cause." To me, this is why there's so much buggy software out there - because this is the methodology that's been widely used. Status quo.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 11:10 AM
Reply to this message Reply
> TDD is one of many useful development tools. If you think
> you can rely on it to 'catch every bug' then you are badly
> mistaken. TDD will only catch those bugs that generate
> problems that you decided in advance to test for.
>
> Refactoring does not catch bugs. Refactored code is
> functionally identical to the code started with.

It is deeper than that. When you TDD you end up with incredibly decoupled designs. It is one thing to talk about decoupling when you design, yet another to end up with one. If you want to see whether a non-TDDed design is decoupled try to write a test for an arbitrary class. It is usually harder than you might imagine.

When you can get each class into a test harness, it is pretty easy to check for bad behavior, you write tests to nail it down. Far easier than working with an application that is a monolithic slab.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 1:15 PM
Reply to this message Reply
> It is deeper than that. When you TDD you end up with
> incredibly decoupled designs. It is one thing to talk
> about decoupling when you design, yet another to end up
> with one. If you want to see whether a non-TDDed design
> is decoupled try to write a test for an arbitrary class.
> It is usually harder than you might imagine.
>
> When you can get each class into a test harness, it is
> pretty easy to check for bad behavior, you write tests to
> nail it down. Far easier than working with an application
> that is a monolithic slab.

I wouldn't disagree with you about the actual capabilities of TDD and refactoring and XP in general. I do use it. But, (lifting Pete Breen's quote from Robert's latest book) "as developers we must remember that XP is not the only game in town".

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. Talk of 'gospel', 'heresy' and 'brilliant sunshine' is the unhealthy language of dubious cults not rational discourse and XP attracts too much of it.

Vince.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 4:29 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. Talk of
> 'gospel', 'heresy' and 'brilliant sunshine' is the
> unhealthy language of dubious cults not rational discourse
> and XP attracts too much of it.

I agree and I'm glad we haven't had any of that on this thread. Now, back to debuggers.

Erik Price

Posts: 39
Nickname: erikprice
Registered: Mar, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 6:25 PM
Reply to this message Reply
Debuggers do not write, modify or even suggest code.

Never heard of debugger-driven programming?

;)

Erik Price

Posts: 39
Nickname: erikprice
Registered: Mar, 2003

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 6:28 PM
Reply to this message Reply
Also, for most software being built today, developer efficiency is far more important than run time efficiency.

It would be neat if our customer agreed with that statement.

Tim Vernum

Posts: 58
Nickname: tpv
Registered: Dec, 2002

Re: Debuggers are a wasteful Timesink Posted: Dec 2, 2003 11:35 PM
Reply to this message Reply
Also, for most software being built today, developer efficiency is far more important than run time efficiency.

I don't write "most software", but I'm pretty sure that's not true.

What is true is that it's usually cheaper to fix runtime problems with hardware than people.

Flat View: This topic has 90 replies on 7 pages [ « | 1  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-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us