The Deadline On Big Design Up Front

In TheDeadline, TomDeMarco has a couple of interesting lines:

Subtract debugging time by designing more efficiently.
almost nobody ever does a design that gets close enough to the actual code to allow sensible review.
high-level design is just hand-waving - low level design is the only thing that is real.
spend the middle 40% of the project doing exaggeratedly detailed low-level design, one that has perfect one-to-one mapping to the code
don't allow implementation until the very last minute.

How do you feel about this? --AlistairCockburn

5) was the most puzzling recommendation in the book to me. I took everything with a grain of salt because many of the characters were supposed to be veils for particular people in industry. I suspected that some sort of sarcasm was floating past me undetected.. at least I hope so. -- MichaelFeathers

One thing to remember is that they had full and complete requirements from the start (the user guides and manuals from the products they were copying). Given that they did not have to make any guesses and that they knew they were going to need it... did BigDesignUpFront make sense?

I was on a project that followed TomDeMarco's then-popular DataFlow? structured design methodology, which was very BigDesignUpFront. 10 people spent 9 months of an 18 month military project doing it, producing enough paper diagrams to fill a cubicle from top to bottom. I remember the project leader riding on a train with me, telling me that this was, finally, the right way to do software, that every other project he'd been on until then was a big hack, that all future software would be done this way, and that this time, this time, we were going to do it to the letter and get it right.

I'll bet almost anyone here can figure out what happened without me saying, but I'll volunteer it anyway. When we started implementing, we found out that a lot of our assumptions were wrong, that we hadn't thought a lot of issues through, and that refactoring and maintaining the intricately detailed design model was about ten times more work than documenting changes to the code. Plus TheDeadline was 9 months closer than it would have been otherwise. So the DataFlow? Diagrams sat happily and completely in their revered cubicle while we finally got down to work.

Since this was military work the QA manager was mighty glad to have all that TomDeMarco paper to wave around at the brass. Nevertheless, it was never used to produce code, never found its way into user documentation, never used to produce unit or functional tests, and was roundly considered nugatory, even by the originally enthusiastic project leader.--PeterMerel

He seems to be 4/5ths of an extreme programmer. It's only his last step which is wrong. That is, if you accept that the low-level design which is in one-to-one with mapping with the code, is the code. And yes, it's the only thing which is real. -- DaveHarris

Agreed, although TheDeadline makes one important assumption - your requirements are unambiguous. I think he says something like "any requirements that are ambiguous are wrong". In the book, it's the product & user manual, which is about as unambiguous as you get - isn't that why XP wants to show something to the user as soon as possible? (Anyone who did projects with spec in say Z?)

I would say that the only difference between doing a very detailed design in design diagrams and coding it in is that you can test your code - verify that the design works.

So, I think the BDUF discussion is really pointless, because you're doing the design up-front (of releasing the product, running your full tests etc..). You just choose a design technique that is verifiable. Then something translates your non-ambiguous, low level design to something that the computer understands. -- VladEnder

In other words, TheSourceCodeIsTheDesign.

I'd rather say TheDesignIsTheSourceCode. --VladEnder

5. don't allow implementation until the very last minute.

For those of us who haven't read the book yet, does that include spikes, prototypes, and 'build one to throw away' code? Or is it meant in the sense of final production code? If preliminary coding comes before this, it doesn't sound as unreasonable.