05.14.09
“Big Design” Up Front vs. Big “Design Up Front”
Design is always a touchy subject. There are those who believe everything should be designed out beforehand, and those who believe you should design as you go.
I’m pretty firmly in the latter camp, as I’ve never seen the former plan actually work. But, there’s a few caveats to that.
I don’t believe in the idea of designing every class, method, and interface before you start coding. Many of those details will become obvious as part of coding, or improvements will be found, and having to add committees and approval processes to making changes (especially if they’re internal only) seems like a really bad idea. When I talk about big design up front, this is generally what I’m referring to – Big “Design Up Front.”
On the other hand, you need to do some level of design up front. I think the XP folks call this the system metaphor. You need to know the big pieces in your design, and what the general flow of the data is. If it’s a distributed application, who connects to who?
Specific technologies don’t need to be a part of this conversation. If you know that process A will send data to process B when the data is ready, then how that takes place is mostly an implementation issue. The important decisions are things like whether A connects to B or vice versa (especially if distributed), and whether A pushes data or B pulls it via polling. Even in a single process, where are your component boundaries, and are they really boundaries? What’s your threading model?
These are the kinds of decisions that you have to make early, as they shape the system as a whole. These are the big pieces of design that need to be hammered out. I’d call this “Big Design” Up Front, and I’m firmly in favor of it.