Re: how many bugs do you find and correct during TDD?

From: Ilja Preuß (it_at_iljapreuss.de)
Date: 01/09/05

  • Next message: Ilja Preuß: "Re: how many bugs do you find and correct during TDD?" 
    Date: Sun, 9 Jan 2005 21:12:22 +0100

    Jack Frost wrote:

    > To be charitable, if you set out to write a simple application you can
    > succeed with much less up front design planning, or perhaps even
    > none! If all we ever wrote were Lemonade Stand, I doubt we'd need to
    > do much planning at all.
    >
    > To be realistic, we often write systems of significant complexity.

    Well, the system my experience mainly comes from is under development for
    over six years now, has seen some dozen releases to a few handfull of quite
    different customers and consists of approximately half a million lines of
    Java code, distributed over >80 modules. I don't know wether that qualifies
    as "signficantly complex" for you, but I certainly wouldn't call it simple,
    thank you.

    > Trying to compose a system to model planetary weather patterns by
    > doing the simplest thing that could possibly work in small
    > deliverable chunks is a sure way to guarantee that you will get it
    > wrong and be refactoring forever.

    Is it? How do you know?

    > I have at my place of work a system
    > designed without the benefit of any design planning and without any
    > significant design artifacts left over to help maintenance coders.
    > It is a modeling application, and quite functionally complex. It is
    > a train wreck, both poorly designed (although functional) and
    > impossibly difficult for new people to begin maintaining.

    Yes, I know those applications, I have a seen quite a lot of them. They
    don't even need to be very complex to become that way. In my experience they
    mostly arise due to a "don't touch running code" philosphy.

    >> I find that, no matter how predictable the machine actually is, I
    >> often encounter problems when trying to predict it in detail, and
    >> even err now and then. And the costs of errors increase
    >> exponentially the longer it lasts until I get feedback about them.
    >
    > For simple systems, I don't disagree. Now if only we wrote nothing
    > but simple data-entry applications.

    We don't. Actually simple systems are rather easy to predict - it's the
    complex systems that aren't.

    >> Fortunately, due to the repeatability and due to the mind-blowing
    >> speed of our current technology, we do have a big advantage over
    >> other "engineering disciplines" - we can try the real thing, in
    >> virtually no time, at virtually no cost. I think it's because of
    >> this fact that I often find trying things out to be more cost
    >> effective than reasoning about them for a long time.
    >
    > This is true if we assume that our time is free,

    Sorry, you lost me here. How do we need to assume that our time is free if
    trying the real thing virtually takes no time?

    > if we assume that every iteration can truly be composed of minute and
    > meaningful chunks of code that work to produce "features" for a user,
    > which they cannot.

    When I do Test Driven Development, I produce running code every couple of
    seconds to minutes. Those chunks don't have to be meaningful to the end
    user, they only have to be meaningful to me. Every time I run the tests and
    get a pass or failure, I get some valuable feedback about my assumptions -
    feedback that would be missing if I would be working on some non-executable
    documents instead of code.

    >> I'm quite sure that if we could crash a car against a wall at
    >> virtually no cost, car manufacturers would do that much more often
    >> and do much less speculative design - with the effect of being able
    >> to have increased innovation by reduced costs. In fact as far as I
    >> know whole industries are actually trying to do exactly that by
    >> introducing new materials and software emulations.
    >
    > Er, you're aware that your comment about "whole industries" is in
    > support of the notion of up front planning, right?

    No, it is not. Read on.

    > Software
    > emulations are used for planning, not constructing. They are the UML
    > of the engineering community, much as the sliderule and paper was in
    > years past.

    No, they are not the UML (unless you talk about executable UML, possibly).
    They are not some non-executable blue prints, they are simulations that try
    to get as close to the real thing as possible.

    And I'm not only talking about simulations, but also about new materials,
    materials for fast and cheap prototyping. They are using those materials to
    build something as close to the real thing as possible, without imposing the
    same costs as the real thing. They are doing this to try things in reality,
    to more early verify wether their theoretical assumptions were in fact
    correct.

    > The Boeing 777 was famously designed to excruciating tolerances using
    > software before a single bolt was ordered. Sounds like it was
    > meticulously planned.

    Yes, but why? Probably because building early Boeing 777's a thousand times
    and let them crash in hundred of different situations would have taken to
    long and cost to much.

    In software development the forces are different. In Eclipse, I do have a
    new build of the above mentioned system ready nearly immediately after I
    changed the "blue prints" (the code). I can run thousands of tests in a
    matter of seconds, just by pressing a single button. Even more tests are
    automatically run every hour by our Cruise Control server, even more every
    night.

    Software development isn't constraint the way hardware development is -
    iterating is faster and cheaper by orders of magnitude. That's why we don't
    have to rely on simulations and surrogates that much - we often can use the
    real thing, and should use that to our advantage, in my opinion.

    > Metaphor is used to make a point, in this case failing to make one.
    > It is a type of logical argument by way of comparison.

    Actually in this case it wasn't used to make an argument, but to pose a
    couple of questioned, the most interesting possibly being "Why should
    software be any different?"

    I think answers to that question actually could be quite enlightening. YMMV.

    Cheers, Ilja

  • Next message: Ilja Preuß: "Re: how many bugs do you find and correct during TDD?"