I concur. Most of the most painfully over-engineered swamp projects I've dealt with have been a result of not understanding the requirements.

Of course, this is not to imply that it's necessarily possible to know every requirement perfectly before you begin - I find that I frequently don't really understand the requirements until I've built the damn thing and it's made first contact with the real world.

So I usually toss that first version out, and build the second one. And that one is usually good enough that I don't immediately want to throw it out the window.

And by the time I get through the third version, usually a fair bit after the second is done, it's pretty damn good.

Because now I understand the problem and the requirements so much better than I did at the start, and I better understand what the system needs to be to solve that problem.

Will it be perfect? Never, except in a static and unchanging universe. But we can approach optimality for a given moment in time, which is functionally the same thing.

> Most of the most painfully over-engineered swamp projects I've dealt with have been a result of not understanding the requirements.

For me it's been a complete lack of requirements. Absolutely no one in the company seeming to want to make a firm decision on what we're building right at the moment. Every decision coming with a hedge "but maybe we might want to do this sometime later so we should keep our options open"

So any time there was a tradeoff we would take the option that leaves our options open, which takes way more time and effort to get right