Fanciful Magic

Re: Under-design vs. Over-design

Michael Arnoldus had some interesting comments:

Very interesting subject. Allow me to suggest a few questions which will help me understand and maybe make it clearer what answer you are searching for. After reading David Schmaltz: "The Blind Men and The Elephant" i've found worthwile to investige in what 'action-context' an answer is to used. Do you need the under- vs. over-design answer to blame somebody or do you need it to evaluate how much design you need to do before beginning? Another question, does the design-question make sense at all until after the fact, when we know what we should have done? Isn't the under/over design answer just as much subject to change as XP claims (and I agree) the requirements are? I'd like to know what you think.

Well, the answer is certainly not to be used to blame anybody for anything (like "NO NO NO BAD PROGRAMMER!") of course. I think the evaluation of how much design do you need to do is getting closer. I think the real reason for the discussing "over" vs. "under" design is to understand how far do you need to go when thinking about a system. The thought and planning still needs to happen, but how much is good enough? Is it OK to err on the side of not enough thought or on too much? Like I said before, the extreme cases of either is clearly bad. But, what about the less than extreme cases. I think we can all point to examples of where under design killed a project or where over design burdened a project into extinction. I keep pondering on what side would I want to err on (of course, I want to err as little as possible, but I know that perfect designs are very hard to obtain if not impossible). The thing about XP is that it says that to err is human and to err on the side of under design because if it not enough then you can refactor in a better design as you outgrow the old one. It doesn't say not to do design, but just to not to go overboard with super generic solutions (basically, don't invent a new tool if a hammer will do for today). I also think its extremely important to always been evaluating a design and refactor it the minute it becomes painful to use. So, I do believe in post-mortem activities after iterations in XP. And to his last point, I would say I would expect the design to change as often as the requirements in the beginning and then slowly harden as the project continues. I would expect changing too much of the design constantly would be a bad thing. A good design changes slowly. I mean how many times was Smalltalk rewritten before we got the system we have today? Perfection is not obtained overnight. I look at a good design like a fine wine. It gets better with age.