[astine]

I think that anyone with even a little bit of real world experience would realize that the spec is rarely ever set in stone. You don't know what you want in a car until you've driven a few. The same is with software; Users don't know what they want until they've tried it out themselves.

This is part of what the big deal about 'agile' methodologies is: People remaining flexible about requirements because they don't really know what will be needed in the future. Specs change and grow and the more flexible your code base is, the easier it is to make changes and maintain.

Granted it can be overdone, (some of the worst WTFs come from overly flexible code,) Ideally, a program should be flexible enough to allow for any reasonable change or extension.

[gruseom]

Actually, I think you're putting your finger on a certain tension here (I won't say contradiction) in the agile principles. On the one hand, develop incrementally and adapt to change; on the other hand, build the simplest thing that meets the requirements now (and resist the temptation to avoid generalizing up front). The trouble is that code that does X in a direct, concrete way can't always be easily changed to meet the new requirements when X changes to X'.

The typical agile answer is, "We'll just refactor to allow the necessary changes as we go along." This is an oversimplification, because the cost of such refactoring isn't always low. Sometimes it's no less than the cost of rewriting the system. Other times the refactoring leads to suboptimal solutions for X', compared with what you would have if you designed for X' originally. I've seen agile projects get into trouble this way.

There's no question that up-front generality is often misplaced (since you can't know for sure what you'll need in the future) and can cause a lot of complexity damage. But the answer doesn't lie in making a "process" out of a half-dozen or dozen principles and pretending you've solved the problem.

[astine]

Oh, I understand. My current job is an agile shop and I've seen firsthand how dealing with poorly thought out legacy design can be a pain. We take a lot of pains these days to make sure decisions today don't get in the way of plans tomorrow.

Personally, I'm not a huge fan of agile but it does hit on a few things right.