First and Last, cool design is an art. At various points in a project cycle, failing to slow down to do formal “big” design means your product will fail — unless you happen to be lucky — or be only average. These are the well known design “points of no return.”
There are also points when everyone pretty much knows how the design should proceed and should be programming in an XP fashion. Because I help maintain/extend an embedded telecom code base of over 500,000 lines of source, the problems most apparent to me are design problems. Whatever methodoligies we programmers may expound, the bottom line for medium and large projecs, IMO, is that you MUST get the macro design (interfaces, now and future, and features, now and future) pretty much correct at the beginning, or at least learn enough about object-oriented Design to provide for product expansion.
Not doing this means spaghetti swamps of code when produced in the last 1/3 of the project cycle when everyone starts to aim their code towards the way it should have been done in the first place.
I agree with the XP “test often” mantra. I never code for more than a few days, maybe week at most without testing the whole shebang.
But my Bottom Line on the importance of good design: there is no way to undo cooking an egg, so decide at the beginning whether you want fried or scrambled.
Embedded Software Engineer