Re: Does anybody write tests first?

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

As we all know, the hardest thing about computer programming, if there is a “hard part,” is deciding what to do; not the fairly-rote procedure of actually doing it. But people drop into this self-taught mentality of “just banging stuff out,” just like they first did when they were mastering the language. And then they get to be managers, or worse, and they're still doing it all the same way – they're “just banging stuff out.” Without management-skill (which generally has not too much to do with programming-skill), projects are always missing deadlines and expectations, which those people mistake for “gee, programming sure is hard work.” They vindicate their own actions to themselves, because it's always been this way (for them...), and they never realize that there could be a better way. So, some very smart, very sincere, very well-intentioned people can go an entire career and never bother to learn how the process works. (They think they know.)

You've heard it: “Don't just plan there! Do something!” :-/

When a project gets big or important, it's no longer adequate for “one person” to be making all of the decisions. Not only is this impractical from a timing standpoint, but the true complexity of the project reaches a point where a single individual is not likely to possess all of the essential experience. You need to have several active brains on the project, with eyes wide open and individual responsibilities, and with the sanction to disagree with one another... and with you. To make a project of any size really work, you must borrow from the greater field of engineering discipline and formalize the task of project management, as well as the programming, the documenting, the testing and all the other “technical” things. You can be responsible for a project, and be very pivotal in making it succeed, and not write a single line of the source-code yourself.

O'Reilly has recently published a definitive book (which doesn't have an animal on the cover...) called The Art of Project Management, by Scott Berkun, (ISBN-13: 978-0-596-00786-7) which should be required reading. In a similar vein is Debugging the Development Process, published by Microsoft Press. (It's part of their “Software Engineering Classics” boxed-set.)

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. But it happens every day, and millions of dollars get blown that way.

You can do these things on a smaller scale too; make it part of your overall daily practice. First of all, you need to plan ahead so that you're not bumping into “crisis mode” and throwing every concern out-the-window. (Never agree to a “schedule” that you don't agree with. Never work to a “wiki” as a spec.) Instead of building a great-big thing only to discover that it doesn't work and have to scrap it, probe the entire project from a higher-level before you start ... looking everywhere the waters seem to be disturbed to explore what kind of rocks might be underneath that particular area. In the case of Perl, use CPAN (and this forum!) very aggressively so that you can take advantage of someone else's experiences (ka-whack! ouch!!) rather than repeating them.

Microsoft Project® can be your greatest ally: you can “work it out on paper!” If you can't say day-for-day what you're going to be doing and what milestones you will reach, you're not ready to start work. If you find that you're not hitting your deadlines squarely, you need to stop right away and fix your schedule: the schedule reflects the plan, so if the schedule's non-functional, so must be your plan... and the schedule is simply your bellwether; your canary.

Replies are listed 'Best First'.
Re^2: Does anybody write tests first? by chromatic (Archbishop) on Feb 22, 2008 at 19:03 UTC
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.	[reply]
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.
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
Re^6: Does anybody write tests first? by chromatic (Archbishop) on Feb 22, 2008 at 21:51 UTC
Some notes below your chosen depth have not been shown here
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]
Re^2: Does anybody write tests first? by doc_faustroll (Scribe) on Feb 22, 2008 at 21:19 UTC
Sundial, I like your writing, and he who writes well, demonstrably thinks well. And I appreciate a proper requirements cycle, but I must concur with chromatic here. Design first with all its attendant paraphernalia (artifacts which often obscure the fact that implementation is design) is often too brittle. As the sages of the middle way opine, you are, in this post at least, heading too far to one side of the game. give me one or two scribblers who can understand business needs, design and implementation, and I'll be in Scotland long before the project managed, designed, and handed off to in shore/offshore coders group has found out how little the design had to do with meeting the requirements I'ved tried the design first way. with ten pms to two developers. I was the implementer. We could have saved so many cycles if we had fired 9 pms, and had me collect the requirements. In that case. ymmv. Furthermore, a wiki is a tool like any other. wikis don't kill projects. people kill projects. update: design prayerful-gnalia. where is the qualia?	[reply]


No such thing as a small change
	PerlMonks