Extreme Programming - Do you really stop using a debugger because of XP?

Author

Do you really stop using a debugger because of XP?

Gilligan

2005-01-13, 3:59 pm

I am hearing that people aren't using their debuggers anymore because
of XP?

Please tell me about this!

TDD seems to be the key many are talking about, but I am missing
something (which could very well be the correct usage of TDD, maybe I
am doing things all wrong).

Share the wealth out there!

Thanks,
Geoff

Laurent Bossavit

2005-01-13, 3:59 pm

Geoff,

> I am hearing that people aren't using their debuggers anymore because
> of XP? Please tell me about this!

I wrote up some of my experience with that, about eighteen months ago:
http://bossavit.com/thoughts/archives/000634.html

To me, the key result of TDD is that when I do write a bug, I can sit
back, think about my code as written, and usually point to a line and
say, *this* is where I got something wrong. Without running the code.

Laurent

John Roth

2005-01-13, 8:58 pm

"Gilligan" <geoffrey.slinker@gmail.com> wrote in message
news:1105640160.347436.90590@f14g2000cwb.googlegroups.com...
>I am hearing that people aren't using their debuggers anymore because
> of XP?
>
> Please tell me about this!
>
> TDD seems to be the key many are talking about, but I am missing
> something (which could very well be the correct usage of TDD, maybe I
> am doing things all wrong).
>
> Share the wealth out there!

I've been in this wilderness, uh, business for
almost 40 years, and in that time I've seen maybe
three things that have really revolutionized the way
I develop software. They are the personal computer,
object oriented programming and Test Driven
Development.

None of them were easy to adapt to or learn how
to use effectively. Test Driven Development gives
me the ability to know that I'm turning out
unbelievably clean code. It forces a degree of
decoupling that makes code very easy to understand.

It takes up to six months for someone to really
get it. Some people get it faster, some never
do. Once you do, you start realizing that code
you have to trace through to understand it
is bad code.

And when you begin working on clear,
understandable, tested and well designed
code, you find that there is no need to trace
things through. The debugger becomes a
tool you used to use a lot.

John Roth
>
> Thanks,
> Geoff
>

Gilligan

2005-01-13, 8:58 pm

I just need more experience to get to where you are at.

I find, especially with the unit tests and integration tests that I
step through them when they fail. There is no code coverage tool or
tests of the tests... Am I just pushing around where I debug?
Guidance here is needed.

Andrew McDonagh

2005-01-13, 8:58 pm

Gilligan wrote:
> I am hearing that people aren't using their debuggers anymore because
> of XP?
>
> Please tell me about this!
>
> TDD seems to be the key many are talking about, but I am missing
> something (which could very well be the correct usage of TDD, maybe I
> am doing things all wrong).
>
> Share the wealth out there!
>
> Thanks,
> Geoff
>

My team have been using TDD for 1.5 years now and I can tell you that on
our team there is a mix of who uses the debugger more or less.

Ironically, prior to using TDD, I'd just about always use the debugger
to test that what I'd wrote worked. So when I first started TDD I
noticed very quickly that my dependence upon it rapidly fell away.

I'd say that it took me at least a month before I became confident
enough not to have to 'check' my tests with the debugger, or use it to
find out why my tests failed when I thought they should have passed.

I realised that the more code I wrote before hitting the runtests
button, the more likely my tests were to fail and the more likely I
would have to debug to find out why.

Now on my team, there are some who still resort to using the debugger if
something fails, even when only a few edits have been done. I think it
must be a habit or simply the lack of ability to deduce what effect
their code edits have had, to the code under test, or some of it may be
due to the large amounts of code we now have under test.

Not that this number means much, but we currently have 1734 unit tests,
which take ~65 seconds to run.

Laurent Bossavit

2005-01-13, 8:58 pm

Geoff,

> I find, especially with the unit tests and integration tests that I
> step through them when they fail. There is no code coverage tool or
> tests of the tests...

I'm not sure either of the latter is needed.

When a test fails unexpectedly, my first reflex is to look at the
diagnostic message included in the assert statement. Sometimes I'm
careless and all I get there is the bare essentials: "Expected 20, got
21." More often I've been disciplined enough to make that more explicit:
"Field number 2 has value 20, the parser expected 21".

That and the context of the failure give me a head start in locating the
problem. I'm in "testVariableWidthFields" of "ParserUnit" tells me that
it has to do with parsing individual fields of my message format. (I'm
making up the bug, but I'm looking at actual tests and code as I write
this.)

Just about the only place this could be going wrong is in method
"readFrom(InputStream)" of class VariableField, because that's where all
the interesting stuff tends to happen as I parse messages. This method
is all of three lines long. I go over them one by one, making hypotheses
as to what could be going wrong. For instance, the first line calls a
method which computes an index into an array that's read later on, by
gobbling one int from the stream and adding an offset which is a
hardcoded value. Wait, the feature I'm working on one has of these
"weird" messages, and they said that the offset was computed differently
when the incoming message had the weird flag set; or did they ? The spec
was a bit unclear. (I'm making up this last bit, but it's not a
stretch.)

By now I have a working hypothesis for a failure scenario. What I do now
is write one more test, a fine-grained one that includes just the bare
essentials of the scenario: the smallest doable message (maybe from a
real message stream, maybe one I make up from the spec) that has the
weird bit set. I locate by hand the index of the correct value, which
becomes the "expected" portion of an assertion.

When I run the test, one of two things might happen - I get a failure,
which means I was right about the "bug" being my overlooking the special
case of the index computation. Or I get green - after double-checking, I
may go on to the next line looking for a different hypothesis. I'm not
panicked because I know that a process of elimination will eventually
turn up the bug.

Laurent

Gilligan

2005-01-14, 3:58 am

I think I see the light.

You have developed such a small piece of code that if the test fails
you are still mentally in context.
Is that it?

I maybe "multitasking" a bit too much! By the time I run my tests, I
have develped too many other things that confuse the brain.

That is what I am going to think about and see if it is the case.
Thanks.

Gilligan

2005-01-14, 3:58 am

Gilligan

2005-01-14, 3:58 am

Wow. Thanks for the info. I appreciate the help. One thing that is
refreshing is that our (development) community is helpful to each other.

Phlip

2005-01-14, 3:58 am

Gilligan wrote:

> I am hearing that people aren't using their debuggers anymore because
> of XP?

I have 2 years flight time using Python and TDD. We occassionally warmed up
the python debugger and figured out how to use it, but I never used it
myself.

When a debugger is available, such as in C++, I use it to research how
libraries work and to step thru all new test cases and new functions.
Debugging is great to see if a test fails for the correct reason.

XP does not make the debugger useless. XP prevents long arduous bug hunts;
the unpredictable kind that destroy a schedule.

That's the joy and relief you hear about. The defect rate starts low and
stays low, allowing code to hold its value and not decay over time. Adding
features to very old code is as easy as to new code. And if that code is
highly reused, then adding the features is easier than to new code.

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

carl.manaster@gmail.com

2005-01-14, 3:58 pm

Hi, Gilligan,

> You have developed such a small piece of code that if the test fails
> you are still mentally in context.
> Is that it?

That is exactly it. Write the test of the smallest piece of additional
functionality you can think of; watch it fail; fix it; repeat. You've
only changed a couple of lines of code between tests, so any errors
should be very easy to localize. If you can't figure it out, just
delete 'em - get back to green - and start over on that tiny bit of
functionality; you won't have lost much work. Remember, the code
you're adding to is already extensively tested, so there are already
damn near zero errors in it. Today's unit tests drive today's code to
be up to that standard.

Peace,
--Carl

WalkingDisaster

2005-01-15, 3:57 am

The moment I realized that each test should only test one
precondition/postcondition pair was the last moment I used a debugger.

jgrigg@mo.net

2005-01-15, 3:56 pm

The basic answer is that the fine-grained tests that you get from Test
Driven Development (TDD) generally make it clear what went wrong. If
your classes are small, and your methods are small, and you have tests
that exercise each class, and most methods, in relative isolation, then
observing which tests fail will usually point you directly to the
problem; no debugger needed.

I still use the debugger. Less now than before I started using Test
Driven Development. One reason is that I'm still working with legacy
code.

However, I've used a debugger in an XP "fishbowl," in front of an XP
audience, at the XP STL user group. Everyone was shocked. Why did I
do it? Well, a test failed, and the members of the audience couldn't
agree as to why it failed. So I set a breakpoint on the test, ran the
program, and stepped into the method in question. It quickly became
obvious as to what the method was *really* doing. This resolved the
confusion and disagreement among the audience members.

Conclusions? Well... Maybe the method was too large and complex, and
needed to be refactored. Maybe our need to use the debugger was a
"smell," telling us that the code was not as clear as it needed to be.

So I use the debugger a lot less than I used to, but I still do use it
from time to time. Maybe I shouldn't. I know that the legacy code I'm
working on needs /very serious and extensive/ improvement. Maybe if I
improved the code to be much closer to the "typical level of XP
quality" I would practically never see the debugger. I don't know for
sure, but I'm working on it...

Ron Jeffries

2005-01-15, 8:56 pm

On 15 Jan 2005 07:42:16 -0800, jgrigg@mo.net wrote:

>I still use the debugger. Less now than before I started using Test
>Driven Development

So do I, also less than I used to. And from time to time I'll print
something to the console or the transcript.

It's interesting that using TDD helps people not to need debugging as
often as they used to. I would take that as evidence that they're
writing code that they understand better than they used to. I still
write code that doesn't do what I expect, and sometimes I just don't
see why until I get the different viewpoint that a print or a debug
inspection gives. Rarely, but still once in a while, I step something
to see why it isn't flowing as I expected.

I wouldn't say that the objective of TDD is not to need the debugger,
though it's a good objective to consider. I'd say that frequency of
needing the debugger is an interesting measure of how we're doing. Too
much might suggest that we're getting careless, or in over our head.
Too little might suggest that we're going too slowly.

I'd just pay attention and use my best judgment about what my
experience is telling me, and I'd suggest the same to others.

Regards,

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

Robert C. Martin

2005-01-16, 3:56 pm

On 13 Jan 2005 10:16:00 -0800, "Gilligan" <geoffrey.slinker@gmail.com>
wrote:

>I am hearing that people aren't using their debuggers anymore because
>of XP?
>
>Please tell me about this!

The *way* I use a debugger has changed significantly. Firstly, I
don't use it very often. The act of keeping the program passing all
its tests every few minutes means that there just aren't enough bugs
to require debugging. Moreover, what bugs do exist are simple to find
because: I just added them, and/or they are discovered by a failing
unit test that pinpoints them.

The amount of time I spend debugging has shrunk by a huge amount, and
the need for a really good debugger has diminished.

The key is to make very tiny changes, and execute *all* the unit tests
between each change. The size of each change should be just a few
minutes.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

Robert C. Martin

2005-01-16, 3:56 pm

On 13 Jan 2005 16:46:22 -0800, "Gilligan" <geoffrey.slinker@gmail.com>
wrote:

>You have developed such a small piece of code that if the test fails
>you are still mentally in context.
>Is that it?

Yes!

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

Tom Plunket

2005-01-29, 8:56 am

Phlip wrote:

>
> I have 2 years flight time using Python and TDD. We occassionally
> warmed up the python debugger and figured out how to use it, but
> I never used it myself.

I read about the Python debugger once, thinking it would be handy
to figure out how to use.

It seemed hard, and I'm kinda dumb, so I figured out how to make
the unittest module work the way I wanted it to instead and to
this day have never figured out how to make debugging happen in
Python.

It seems like the PDB tools (if I'm remembering the name
correctly) could be really useful for unit test output, but
really unittest does all that I really need it to, and besides
being kinda dumb, I'm really lazy.

....amazing I can code at all, really, but there you have it.
Spoiled by debuggers that did exactly what I wanted them to for
Pascal, C, and C++ development, PDB looked to me like GDB except
that I never used PDB in college so I never had anyone standing
nearby to tell me what buttons to push.

-tom!

Steve Jorgensen

2005-01-29, 8:56 am

On Thu, 13 Jan 2005 14:10:39 -0600, "John Roth" <newsgroups@jhrothjr.com>
wrote:

....
>I've been in this wilderness, uh, business for
>almost 40 years, and in that time I've seen maybe
>three things that have really revolutionized the way
>I develop software. They are the personal computer,
>object oriented programming and Test Driven
>Development.
>
>None of them were easy to adapt to or learn how
>to use effectively. Test Driven Development gives
>me the ability to know that I'm turning out
>unbelievably clean code. It forces a degree of
>decoupling that makes code very easy to understand.
>
>It takes up to six months for someone to really
>get it. Some people get it faster, some never
>do. Once you do, you start realizing that code
>you have to trace through to understand it
>is bad code.
....

I'm curious about the statement "some never do". I'll grant that, back when I
was a hobbyist, just learning C++, I didn't get OOP, though I thought I did.
Having eventually gotten a handle on what OOP is really about, though, I found
TDD pretty easy to get once I accepted the idea that it was worth trying to
experiment with.

Does it actually happen that people who've been successfully programming at
some level for a long time can be coached in TDD and never get it?

John Roth

2005-01-29, 8:56 am

"Steve Jorgensen" <nospam@nospam.nospam> wrote in message
news:9bjmv0p6dbq9bieak623lns6g07grmbfs2@
4ax.com...
> On Thu, 13 Jan 2005 14:10:39 -0600, "John Roth" <newsgroups@jhrothjr.com>
> wrote:
>
> ...
> ...
>
> I'm curious about the statement "some never do". I'll grant that, back
> when I
> was a hobbyist, just learning C++, I didn't get OOP, though I thought I
> did.
> Having eventually gotten a handle on what OOP is really about, though, I
> found
> TDD pretty easy to get once I accepted the idea that it was worth trying
> to
> experiment with.
>
> Does it actually happen that people who've been successfully programming
> at
> some level for a long time can be coached in TDD and never get it?

_Everyone_ doesn't turn out bad code that has to
be beaten into submission to make it work using
traditional methods. For some people, what looks
like traditional methods turns out great code with
very low defect rates, just like some authors write
first drafts that are of publishable quality - no editing
required. It isn't the norm, but they do exist.

For these people, TDD doesn't solve a problem that's
worth the effort - at least until they have to work on
an XP team, and that isn't common enough to be a
problem - yet.

John Roth
>

Robert C. Martin

2005-01-29, 3:57 pm

On Sat, 29 Jan 2005 05:34:26 -0600, "John Roth"
<newsgroups@jhrothjr.com> wrote:

>_Everyone_ doesn't turn out bad code that has to
>be beaten into submission to make it work using
>traditional methods. For some people, what looks
>like traditional methods turns out great code with
>very low defect rates, just like some authors write
>first drafts that are of publishable quality - no editing
>required. It isn't the norm, but they do exist.

I suppose there are doctors who are so skilled and careful that they
consider hand-washing to be unnecessary. I'm not going to hire one.

I suppose there are programmers who are so skilled and careful that
they consider testing to be unnecessary...

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

John Roth

2005-01-29, 3:57 pm

"Robert C. Martin" <unclebob@objectmentor.com> wrote in message
news:134nv0t2srv8q8oj5g580s5lbv25fttckf@
4ax.com...
> On Sat, 29 Jan 2005 05:34:26 -0600, "John Roth"
> <newsgroups@jhrothjr.com> wrote:
>
>
> I suppose there are doctors who are so skilled and careful that they
> consider hand-washing to be unnecessary. I'm not going to hire one.

Hand washing has nothing to do with skill
and care. It's a false comparison.

> I suppose there are programmers who are so skilled and careful that
> they consider testing to be unnecessary...

Well, there are those shops too; they use a
technique called formal inspections, and regard
unit tests in addition as a waste of money.

John Roth
>
>
>
> -----
> Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
> Object Mentor Inc. | blog: www.butunclebob.com
> The Agile Transition Experts | web: www.objectmentor.com
> 800-338-6716
>
>
> "The aim of science is not to open the door to infinite wisdom,
> but to set a limit to infinite error."
> -- Bertolt Brecht, Life of Galileo

jgrigg@mo.net

2005-01-29, 3:57 pm

> --- "Robert C. Martin" <unclebob@objectmentor.com> wrote...

--- John Roth wrote:[color=darkred]
> Well, there are those shops too; they use a
> technique called formal inspections, and regard
> unit tests in addition as a waste of money.

For an even more extreme approach that is the "opposite of" approaches
that use developer testing, see:
http://www.c2.com/cgi/wiki?CleanRoomMethodology

(Yes, there's still testing by running the code -- but not by the
developers; an independent QA group tests the code, as the users would
use it, to *VERIFY* the correctness of the code -- *NOT* to find bugs.
The bugs should have been removed much earlier.)

Andrew McDonagh

2005-01-29, 3:57 pm

Robert C. Martin wrote:
> On Sat, 29 Jan 2005 05:34:26 -0600, "John Roth"
> <newsgroups@jhrothjr.com> wrote:
>
>
>
>
> I suppose there are doctors who are so skilled and careful that they
> consider hand-washing to be unnecessary. I'm not going to hire one.
>
> I suppose there are programmers who are so skilled and careful that
> they consider testing to be unnecessary...
>
>
>

like wise, when I hear the phrase "I can write bug free code"...

Phlip

2005-01-30, 3:56 am

Andrew McDonagh wrote:

> like wise, when I hear the phrase "I can write bug free code"...

Which leads to an assortment of...

- that's a feature
- oh, I just changed that. Wait a minute.
- you used it wrong

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

Isaac Gouy

2005-01-31, 3:58 pm

Robert C. Martin wrote:
> On Sat, 29 Jan 2005 05:34:26 -0600, "John Roth"
> <newsgroups@jhrothjr.com> wrote:
>
>
> I suppose there are doctors who are so skilled and careful that they
> consider hand-washing to be unnecessary. I'm not going to hire one.

>
> I suppose there are programmers who are so skilled and careful that
> they consider testing to be unnecessary...

"One of the ironies of TDD is that it isn't a testing technique"
p204, Test Driven Development By Example

Phlip

2005-02-01, 3:58 pm

Isaac Gouy wrote:

> "One of the ironies of TDD is that it isn't a testing technique"
> p204, Test Driven Development By Example

Only "testing techniques" may prevent debugging?

--
Phlip
http://industrialxp.org/community/b...tUserInterfaces

Isaac Gouy

2005-02-01, 3:58 pm

Phlip wrote:
> Isaac Gouy wrote:
>
>
> Only "testing techniques" may prevent debugging?

(I'll assume that you intended to reply to this post
http://groups-beta.google.com/group...f1c1a43ba433818
)

Let's retrieve the context, Mr Martin wrote:

> I suppose there are doctors who are so skilled and careful that they
> consider hand-washing to be unnecessary. I'm not going to hire one.

> I suppose there are programmers who are so skilled and careful that
> they consider testing to be unnecessary...

Whether or not 'there are programmers' who 'consider testing to be
unnecessary' is irrelevant. There may be programmers who consider TDD
to be unnecessary and who consider 'testing' to be necessary.
TDD and 'testing' are not synonyms.

Phlip

2005-02-01, 8:57 pm

Isaac Gouy wrote:

they[color=darkred]
one.[color=darkred]
>
>
> Whether or not 'there are programmers' who 'consider testing to be
> unnecessary' is irrelevant. There may be programmers who consider TDD
> to be unnecessary and who consider 'testing' to be necessary.
> TDD and 'testing' are not synonyms.

Mr Martin supposes there are programmers who are so skilled and careful
that they consider BugPrevention unnecessary. TDD and formal testing
both help prevent bugs. But you would slight Martin for using the word
"testing" when TDD is not a formal testing technique.

Washing your hands before surgery is about the best metaphor for TDD
available. It even applies to the current debate about it.
Prevention is better than a cure.

--
Phlip

Andrew McDonagh

2005-02-01, 8:57 pm

Phlip wrote:

snipped

>It even applies to the current debate about it. Prevention is better than a cure.
>

I agree, and unfortunately I've seen the same people who proclaim to be
able to write bug free code, are usually the very same ones who, if are
required to TDD, will actually not write certain tests, because the
'cost' of the test 'out ways' the 'benefit' of having it there,
protecting everyone else. These tend to be either for code that is 'too
simple' or 'too difficult'.

The example of one is when an error dialog is needed to be displayed.
yes the actual code to display a dialog with a title and message is very
trivial. But I'll still write a test for it. The one time we had a bug
where the message was wrong, was in the untested code produced by these
'I write bug free code' people.

I have metaphorical banged my head against this wall so many times now,
that I have a metaphorical head-ache.

Isaac Gouy

2005-02-01, 8:57 pm

Phlip wrote:
> Isaac Gouy wrote:
>
> they
> one.
that[color=darkred]
TDD[color=darkred]
>
> Mr Martin supposes there are programmers who are so skilled and
careful
> that they consider BugPrevention unnecessary. TDD and formal testing
> both help prevent bugs. But you would slight Martin for using the
word
> "testing" when TDD is not a formal testing technique.
>
> Washing your hands before surgery is about the best metaphor for TDD
> available. It even applies to the current debate about it.
> Prevention is better than a cure.

I have enough respect for Mr Martin to take him at his word; he said
testing - not TDD, not BugPrevention.

Don't put words into my mouth!
I would not "slight Martin" and I haven't mentioned "formal testing
technique".

Sponsored Links