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  | » ]
Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Debuggers are a wasteful Timesink (View in Weblogs)
Posted: Nov 29, 2003 8:35 AM
Reply to this message Reply
Summary
As debuggers have grown in power and capability, they have become more and more harmful to the process of software development.
Advertisement
Debuggers have become immensely powerful. A good debugger is a very capable tool. With it, an experienced developer can step through very complex code, look at all the variables, data structures, and stack frames; even modify the code and continue. And yet, for all their power, debuggers have done more to damage software development than help it.

Since I started using Test Driven Development in 1999, I have not found a serious use for a debugger. The kinds of bugs I have to troubleshoot are easily isolated by my unit tests, and can be quickly found through inspection and a few judiciously placed print statements.

I teach a lot of classes in C++, Java, C#, TDD, XP, Patterns, etc. In those classes I often have the students write code. It is not unusual for me to find a student with his or her nose buried in a debugger, painstakingly stepping from line to line, examining variables, setting breakpoints, and generally wasting time. The bug they are tracking could be found through simple inspection of the code.

I consider debuggers to be a drug -- an addiction. Programmers can get into the horrible habbit of depending on the debugger instead of on their brain. IMHO a debugger is a tool of last resort. Once you have exhausted every other avenue of diagnosis, and have given very careful thought to just rewriting the offending code, *then* you may need a debugger.


Thomas Koschate

Posts: 1
Nickname: koschate
Registered: Nov, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 12:12 PM
Reply to this message Reply
All right, I'll knock down the straw man. I agree - debuggers can be a timesink. On the other hand, they can be a useful tool, in conjunction with tests, to develop software.

It's quite common for me to write a test to exercise a requirement, write a high level method that will satisfy the requirement, and then start implementing the methods to which I've referred as the debugger pops up. In this way, I'm implementing exactly the methods I need when I need them. Of course, the tools I use (Smalltalk and VA Assist Pro) lend themselves nicely to this approach.

Used this way, the debugger is actually a development aid, rather than a diagnostic tool. When a debugger pops up, I know exactly which method is missing, and what kinds of parameters I might reasonably expect to send to the missing method. And, if those parameters aren't what I expected, I can easily walk up the stack trace to see where I went wrong. Of course, by following this development pattern religiously, The unexpected doesn't normally have a chance to happen.

Chris Sells

Posts: 1
Nickname: csells99
Registered: Nov, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 12:24 PM
Reply to this message Reply
Wow. Is it April Fool's Day already, because I assume you're kidding. Debuggers are an enormously important tool for real, commercial software development.

hackrobat

Posts: 14
Nickname: hackrobat
Registered: Jul, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 1:20 PM
Reply to this message Reply
Since I started using Test Driven Development in 1999, I have not found a serious use for a debugger.

I'm sure, because you're doing development, not debugging. I hardly ever used a debugger, if at all, when I was writing my own code. But you see, there are jobs where you have to just debug, when the guy who wrote the code has long since left the company (or worse, has become a manager), and you know neither the code nor the application domain.

The kinds of bugs I have to troubleshoot are easily isolated by my unit tests, and can be quickly found through inspection and a few judiciously placed print statements.

Only a couple of days back, I was diagnosing a bug: "Error while reading AFM file in PDF generator." Now, I have no clue what an AFM file is. I figured out it's an ascii file containing some font kerning information for PDF documents. Next, I don't know how the code works. I grep for the "AFM" and "read" in the code, and find a function called "ReadAFMFile" somewhere. Since I don't know the file format, I get lost in all the for and while loops. Print statements galore, but it makes little sense. Finally, I do manage to figure out the reason by "guessing" that it's a UNIX vs. MS-DOS format issue with the ascii file. I strip off all the carriage returns in the file, and bingo, it works!

So this turned out to be simple. What if it wasn't, and if I had to actually find out the file format and how the parsing works?! I think debuggers are very, very essential tools. I'd really like to hear how a debugger has ever wasted your time. Honestly, just how?

Check out this article on "code spelunking":
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=67

Mark Dalrymple

Posts: 2
Nickname: markd2
Registered: Nov, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 1:43 PM
Reply to this message Reply
They can be a wasteful timesink to a class of developers, particularly those doing new development, and who have a lot of experience and can tell at a glance what code can be a problem and what code can't.

Two counter-examples I have. One is a friend working on his CS degree, taking a class having to write a program in C (he's used to Perl and Java). It was SegVing, and he was wasting a lot of his time (and my time over an IRC channel trying to diagnose things) focusing on the wrong line of code. As far as he understood things, the other code was working fine, and the line that was breaking was "if (variableName == NULL)", which in regular C can't crash. Seconds after running his code in the debugger, we found out exactly what the offending line of code was.

The other is me, starting a short-term consulting gig faced with a system upwards of 1mil LOC, horribly designed (which makes me consider cut-and-paste to be a much worse sin against the programming world than debuggers). My job was to surgically refactor a couple of UI components factoring monolithic code into classic MVC. The debugger was an absolute God-Send in finding out what parts of the code I needed to pay attention to, and what parts I could ignore.

But for the most part, I generally only use the debugger when I'm faced with someone else's code breaking, or if I'm feeling extremely lazy at the end of a long day.

I do agree with Uncle Bob in that the reflex of "I have a problem in new code, I'm going to single-step through it" isn't a good thing, and can lead to sloppiness, leading to thinking like "I don't have to write it correctly the first time, I can just debug it until it works"

Steven E. Newton

Posts: 137
Nickname: cm
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 1:57 PM
Reply to this message Reply
> I grep
> for the "AFM" and "read" in the code, and find a function
> called "ReadAFMFile" somewhere. Since I don't know the
> file format, I get lost in all the for and
> while loops. Print statements galore, but it
> makes little sense.

Did you consider writing a unit test for ReadAFMFile instead and trying various inputs and asserting expected results?

hackrobat

Posts: 14
Nickname: hackrobat
Registered: Jul, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 2:21 PM
Reply to this message Reply
> Did you consider writing a unit test for
> ReadAFMFile instead and trying various inputs
> and asserting expected results?

Pray, I fail to understand how writing unit tests can be faster than stepping through the code, given the fact that I don't understand the file format (thus making it difficult, if not impossible, for me to write create unit test cases in the first place!).

Richard Todd

Posts: 1
Nickname: rwt
Registered: Nov, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 2:30 PM
Reply to this message Reply
I mainly use a debugger to pull the stack trace out of a core file. Beyond that, I have learned to avoid them. It's too much faster to mentally step through the code and identify the problem.

Not to mention that, people who find the debugger much easier than inspection will benefit greatly by working on this skill. They'll be able to apply a keen eye for bugs to their code as they write it in the first place.

Steven E. Newton

Posts: 137
Nickname: cm
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 2:40 PM
Reply to this message Reply
> Pray, I fail to understand how writing unit tests can be
> faster than stepping through the code, given the fact that
> I don't understand the file format (thus making it
> difficult, if not impossible, for me to write create unit
> test cases in the first place!).

Who said anything about faster? But when you were done, you'd have the start of a unit test suite for the code. Which leaves the next poor programmer who will have to work with the code (who could be you again, in 6 months) something other than guessing and flailing around with an untested piece of code.

Because there were no tests, there was no way to know how or why the code was generating the error it was. According the original description, it wasn't a bug in the code, the code was working as designed. The problem was with the format of an input file, but there wasn't any information readily available that clarified what was wrong with the input. Of course someone might have written a comment or documentation, but whould would have read it or trusted it?

A unit test is an investment in time savings for the future. Mucking about in the debugger to discover a problem with an input helped one person solve that one problem that time, but there is no lasting benefit.

hackrobat

Posts: 14
Nickname: hackrobat
Registered: Jul, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 5:13 PM
Reply to this message Reply
> Who said anything about faster?

Robert C. Martin said :-) IIRC, he was talking about some "timesink" thing.

> A unit test is an investment in time savings for the
> future. Mucking about in the debugger to discover a
> problem with an input helped one person solve that one
> problem that time, but there is no lasting benefit.

When a paying customer says they want a fix ASAP, they really mean it. Yes, you're right, unit tests go a long way, but right now's not the time for long-term investments ;-)

DrPizza

Posts: 3
Nickname: drpizza
Registered: Nov, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 5:28 PM
Reply to this message Reply
and can be quickly found through inspection and a few judiciously placed print statements.
I can go to the lines I want to examine and examine values -- thereby doing the job of your print statements -- in my debugger quicker than you can write the print statements. And the point of using either a debugger or a print statement is because inspection has failed -- something isn't working how you think it ought to be working.

My debugger is just a really clever print statement. It lets me print values not just where you've stuck your print statement, but anywhere. It lets me examine even complicated objects which have no effective string representation.

Why should I eschew my debugger instead of print statements?

In common with most programmers I used to use print statements to debug. printf debugging is as old as printf itself. But then I realized "Hey, I have this thing called a debugger -- why not spend a few minutes figuring out how it works so I don't have to write all these printfs?". And guessed what? I saved time because of it. It required a small initial investment, to be sure -- but that investment has paid off many times over.

Yes, programmers can get into the habit of depending on the debugger. This means that perhaps we should try to instill some discipline -- I would certainly agree that inspection should be performed first -- but branding the them "wasteful Timesinks" is simply idiotic. Advocating print statements is simply indefensible. Print statements simply do the job of the debugger less quickly and less effectively.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Debuggers are a wasteful Timesink Posted: Nov 29, 2003 11:31 PM
Reply to this message Reply
> > Pray, I fail to understand how writing unit tests can
> be
> > faster than stepping through the code, given the fact
> that
> > I don't understand the file format (thus making it
> > difficult, if not impossible, for me to write create
> unit
> > test cases in the first place!).
>
> Who said anything about faster? But when you were done,
> you'd have the start of a unit test suite for the code.
> Which leaves the next poor programmer who will have to
> work with the code (who could be you again, in 6 months)
> something other than guessing and flailing around with an
> untested piece of code.
>
> Because there were no tests, there was no way to know how
> or why the code was generating the error it was.
> According the original description, it wasn't a bug in
> the code, the code was working as designed. The problem
> was with the format of an input file, but there wasn't
> any information readily available that clarified what was
> wrong with the input. Of course someone might have
> written a comment or documentation, but whould would have
> read it or trusted it?

Hmm... I'm not sure if I agree with this logic in this case. Because in this case, if he had a working unit test (that say, tested data with CR but not CRLF), he would still have had to make the same discovery. Presumably the person who wrote the original code assumed input would always be of a certain format and would probably have constructed the test with the same assumption. I agree that unit testing is generally useful where applicable, but it is not a panacea and in this case, I don't see that it would have saved the day.

I've recently done work that involved two difficult areas where the unit testing didn't help much: hardware interaction (with optical writing devices CD and DVD) and integration with a (dreaded!) framework. Unit testing does great for software-only and self-contained APIs, but in these areas only helps a little.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Debuggers are a wasteful Timesink Posted: Nov 30, 2003 5:38 AM
Reply to this message Reply
Unit tests are great - if you know what the answer is (or, at least, should be) before you write the code. They're also pretty good for debugging pre-written code, provided that that code had already been developed using a test-driven methodology.

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.

The act of debugging will both teach you what the code is doing and (eventually) take you to the bug (which surprisingly often is a single character fix - but that's another story).

Fix made, a couple of quick passes with the debugger will confirm the fix and (in the commercial world) that's the end of the story - except for the paperwork mountain.

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.

My take on this is that it's a pointless exercise, if there is no pre-existing test suite for the code in question. A test suite is only as useful as it is comprehensive. A new suite that consists of only one test is of very limited use and may be counterproductive in inadvertantly leading someone to believe a section of code is covered by unit tests when it isn't. In addition, we are now firmly in the realm of developing for 'potential future requirements' which is a big no-no in the world of test-driven development.

So to conclude: Unit tests are ideal for test driven development but severely limited for code-driven bug-fixing. Don't forge, the worst thing you can do to the reputation of a god tool is to extend its use beyond where it's appropriate.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Are debuggers a wasteful timesink? Posted: Nov 30, 2003 5:49 AM
Reply to this message Reply
Well what do you know. I manually inspected the above item several times before posting it and obvious spelling 'bugs' still crept through. Of course, if there was a spell-checker to debug the text then I could have picked up most of the problems instantly. Mind you, none of them would have told me what I've just noticed - that the receiver for my wireless keyboard had fallen off the back of the desk and behind the PC, which is why I was dropping so many letters as I typed.

I'm sure there must be an educational anecdote in there somewhere.

Vince.

Robert C. Martin

Posts: 111
Nickname: unclebob
Registered: Apr, 2003

Re: Debuggers are a wasteful Timesink Posted: Nov 30, 2003 9:55 AM
Reply to this message Reply
> All right, I'll knock down the straw man. I agree -
> debuggers can be a timesink. On the other hand, they can
> be a useful tool, in conjunction with tests, to develop
> software.
>
> It's quite common for me to write a test to exercise a
> requirement, write a high level method that will satisfy
> the requirement, and then start implementing the methods
> to which I've referred as the debugger pops up. In this
> way, I'm implementing exactly the methods I need when I
> need them. Of course, the tools I use (Smalltalk and VA
> Assist Pro) lend themselves nicely to this approach.
>
> Used this way, the debugger is actually a development aid,
> rather than a diagnostic tool. When a debugger pops up, I
> know exactly which method is missing, and what kinds of
> parameters I might reasonably expect to send to the
> missing method. And, if those parameters aren't what I
> expected, I can easily walk up the stack trace to see
> where I went wrong. Of course, by following this
> development pattern religiously, The unexpected doesn't
> normally have a chance to happen.

In this particular case you are not really debugging. You are using the debugger in the same way that java programmers use the compiler to tell them when a method is missing, or what the arguments to that method are.

For example, when I write a unit test, my IDE (IntelliJ) tells me that the methods I am calling haven't been written yet. It even gives me buttons to push to automatically write create those methods, complete with arguments, etc.

My real beef is with depending on debuggers to debug code that could 1) be debugged more easily through inspection and 2) be debugged more easily using print statements.

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.

Flat View: This topic has 90 replies on 7 pages [ 1  2  3  4  5  6 | » ]
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