[Tabular-Iceberg]

> I have seen this be the fault of developers as much or more than management - even for that "let's get everything right this time" sort of project, devs who interpret that as "let's build a beautiful intricate machine that does exactly what we want it to today" are fare more common than devs who build something that will be able to evolve for tomorrow's needs.

Yes, but more due to inexperience than anything else. Projects tend to start out under-abstracted because modelling takes time, and they were told time to market was the #1 priority. So the natural reaction when that approach breaks down is to dust off the old design classes from school and create an all-encompassing model of everything in the business. Of course in the safe confines of college assignments they never got to experience what a pain that really is.

> Management rarely is involved or interfering there, when a dev or dev team decides to abstract over messy rules to make something "clean" - but in the process just encodes the messiness deeper, and in a harder-to-change way.

That exact lack of involvement is a big part of the problem. The idea of chucking PowerPoint mock-ups for CRUD screens over the fence and telling the devs not to worry their pretty little heads with any domain knowledge. I think Eric Evans has the solution to this problem with Domain Driven Design, but DDD requires a huge commitment on both sides to meet in the middle, sit down and work it all out. But neither have the time for it the way businesses are currently run.