How much design happens in your implementation phase?

Question

For those of you who work in big-design-up-front/waterfall groups: how much critical thinking and design is skipped in your design phase and left to your implementation phase? How complete and detailed are your functional and technical specifications delivered at the end of the design phase?

It seems to me that there's a lot of room for interpretation in the level of detail that needs to be provided at the end of the Design phase, and it irks me when the design phase is rushed and then managers get angry that the build phase doesn't progress like we're churning out widgets on an assembly line. On the other hand, a design phase that's complete enough to make the build phase operate like an assembly line practically includes the implementation phase with it - all that would be left in "build" is to type stuff into the editor. Of course, it also means your design phase is gigantic.

I realize that this is a shortcoming of the waterfall model, but if there's anyone out there that can provide some constructive advice: Where does one draw the line? What should the expectations for the design and build phases be, and what kinds of design shortcomings or mistakes should/shouldn't be tolerated in the build phase?

Answer 1

i'm a huge fan of rapid prototyping, rapid incrementation, and rapid iteration. evolution rather than "intelligent design". you're writing software to solve problems for people and people tend to change their minds and needs over time, even short periods of time.

it's nice to get requirements, a birds-eye view, and "sign off" as squared-away as possible before coding, but there is little point being dogmatic, its all fluid. be prepared to edit, amend, and throw away code as you go. the funny thing is you never arrive at a completion point anyway...most code seems to change while people care about it, and then once no one cares, it just gets deleted.

now to be certain this won't apply to must-work-the-first-time bits of software like aircraft control systems, nuclear reactor controls etc, but my guess is that isn't your case.

Answer 2

There is always something missed in the design phase. People are imperfect, and even with a perfect management that permits lots of design phase time without the pressure to move on to implementation, there will be things you missed.

Likewise, in design, you enter a point of diminishing returns. For example, if designing a user interface and writing that in a spec, you can rapidly reach the point where the spec contains the layout, formatting, and all of the logic of a form. In which case its pretty much identical to the implementation, with perhaps only the messy bits of code glue being different.

You do need to query the value of pushing the design too far: when design turns into writing the code because thats the clearest way to convey your intent, its time to ask if enough is enough.

Implementation, then, will start to uncover things forgotten or missed, as well as other implementation details that might have seemed easy but turn out not to be. (Perhaps the services you thought you might get from some library, or your OS, turn out to be not quite as expected... and you need to do some digging or write a whole lot of new code as a work-around, shim or patch.)

Waterfall is a lovely simple model, great for explaining to management. It is also pretty far removed from the iterative and mixed high level /low level thinking that happens in reality.

---

A bit more interesting commentary about this can be found in an older book: "Decline and fall of the American Programmer" by Ed Yourdon.

I know this is not a perfect answer, but then, programming & design methodologies are not perfect either. The best approach to them is to treat them as a Helpful System For Getting Things Done. The rules are there to HELP you, and to be broken when they get in the way. The breaking of the rules should be done intelligently, not simply because somebody felt like cutting code from day 1.