Re^3: Does anybody write tests first?

(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.

Replies are listed 'Best First'.
Re^4: Does anybody write tests first? by chromatic (Archbishop) on Feb 22, 2008 at 21:34 UTC
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.	[reply]
Re^5: Does anybody write tests first? by doc_faustroll (Scribe) on Feb 22, 2008 at 21:41 UTC
chrom, Don't get testy. ;-) Tell us what you think. I presume that this is sundial's style of discussion. nothing more/	[reply]
Re^6: Does anybody write tests first? by chromatic (Archbishop) on Feb 22, 2008 at 21:51 UTC
Okay. I think that the common definition of success with regard to software projects -- did it meet its original schedule? did it meet its original budget? did it meet its original goals? -- is fatally flawed. A better definition of success comes from asking "Does the project provide real business value to the organization? Is that value greater than the investment of time and resources required to build the project? How soon did the project begin to produce that value?" The dangerous part of that definition of success, besides that it's totally at odds with the time/budget/scope question, is that it depends on what's valuable to the organization. You may be able to guess what's probably valuable in broad terms eighteen months in advance, but I've never seen the specifics stay static for more than a few months at a time, and certainly not in the detail necessary to write software that takes eighteen months to complete.	[reply]
Re^7: Does anybody write tests first? by doc_faustroll (Scribe) on Feb 22, 2008 at 22:40 UTC
Re^4: Does anybody write tests first? by doc_faustroll (Scribe) on Feb 22, 2008 at 21:35 UTC
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.	[reply]


Think about Loose Coupling
	PerlMonks