Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re^2: Does anybody write tests first?

by chromatic (Archbishop)
on Feb 22, 2008 at 19:03 UTC ( #669633=note: print w/replies, xml ) Need Help??

in reply to Re: Does anybody write tests first?
in thread Does anybody write tests first?

I like to remind people that if you wanted to get a new addition built onto your house, and the first day the guy showed up with all his workmen and they started cutting boards and banging nails while the foreman went inside to ask you what you wanted ... if as the days went on they built something and tore it down and built something else, obviously “just making it up as they went along” ... why, you'd throw that guy out of what's left of your house and call your lawyer! So why this sort of nonsense is deemed to be de rigueur in a software project is quite beyond me.

In software terms, we would call those workmen the compiler. I leave fixing your example to match the reality of both construction and software to the reader.

The trick is to truly design it, completely, first. Yes, all of it. (Oh yes, you can!)

Has that ever worked for you on a project that took longer than a week to complete? Yeah, me neither.

Replies are listed 'Best First'.
Re^3: Does anybody write tests first?
by sundialsvc4 (Abbot) on Feb 22, 2008 at 21:11 UTC

    (The compiler...)

    Those workmen have nothing to do with “the compiler.” To continue your peculiar analogy, the compiler would roughly correspond to a cement-mixer:   a necessary, but passive, tool for the job that is used by every single job of its kind.

    (Have you ever...)

    For a project consisting of more than a quarter-million lines of (not Perl...) source code, lasting nearly ten years ... yes, it did.

    Even though the thought of meticulous planning somehow earns responses of “why bother” or “software is different,” I'll stick to my experienced guns.

    Just as you can design a physical machine, or a building, or a golf course, or a shopping center “on paper” in advance of building it, and even accommodate fairly on-the-fly changes to those plans “on paper,” you can design software systems in advance, and keep those paper-plans up to date.

    When people spend $30,000 or so on an addition to their houses, they take for granted this sort of discipline. Yet when they spent $3,000,000 (maybe without quite realizing that they're doing it, or that they're wasting more than half of it) on a software-project, they get lured into thinking that somehow the rules have changed. No, they haven't:  you're still paying someone to do something, and you still expect to have reason for confidence that you'll actually get it.

    When you are “in the trenches” on a project, as most “Perl programmers” are, you just don't see the financial burn-rate. You don't think of your salary as an expense. It might never occur to you that the company is spending a million a year on what you're doing, but that's actually just a small project:   it could be much more. Software projects are actually very-big capital investments that traditionally do not get the same scrutiny and treatment that other smaller investments routinely receive. Don't ask me why...

    So what does all this budget-talk have to do with testing? Everything! Physical construction projects look simple as you whiz past them at 65mph on the freeway, but they're meticulous undertakings. That's why you whiz across thousands of bridges in the course of your travels and (almost...) never fall into the river. Software has never had that sort of track-record, and here's part of the reason why.

      Those workmen have nothing to do with “the compiler.” To continue your peculiar analogy...

      Construction workers take the complete design for a structure and build it, in the same way that the compiler takes the complete design for a system and builds it.

      If natural-language specifications were sufficient for design, we'd feed them to compilers. (We'd also call that source code.)

      When people spend $30,000 or so on an addition to their houses, they take for granted this sort of discipline.

      I don't believe that. I've worked in construction and two of my friends work in industrial construction. Static, up-front design with no changes allowed after the implementation stage has begun doesn't work there, either... and physical construction is less malleable than source code.

      You don't think of your salary as an expense.

      If you asked me what I think instead of telling me what I think, you might realize that what you think I think and what I actually think are two very different things.


        Don't get testy. ;-)

        Tell us what you think. I presume that this is sundial's style of discussion. nothing more/

      Ok, I'm going to modulate and moderate, myself and my point.

      Design certainly has its place in software development as in all realms of building.

      Good design nonetheless only exists and is effective within an ecology if you will that includes an iterative feedback between the design and implementation.

      One thing that I recommend and that seems to pay considerable dividends is to have people step out of their silos. If one does have an implementer who works from design, they should spend some time re-collecting raw requirements and going over what the design models, before they implement the design.

      Your points are well taken, Sundial. And we do indeed have considerable ground to cover in the maturation process.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://669633]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (7)
As of 2020-10-30 17:44 GMT
Find Nodes?
    Voting Booth?
    My favourite web site is:

    Results (282 votes). Check out past polls.