[majormajor]

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. 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.

A dev who's also focused on "how can I deliver value to the customer" is really the only person who can make the right choices there, because the code has to be designed to make sure future valuable changes can be made, vs designed for a specific "snapshot" of specs.

And yeah, it often becomes a cycle, where management doesn't trust devs to build systems that won't suck, because devs haven't shown they can build systems that won't suck, because they're constantly just fighting the old systems that suck instead of having good training/experience building ones that don't... but I can't put that on non-technical management. We don't want non-technical management trying to tell us how to build a system, we just have to get better at it ourselves. You can do that by working on a bunch of broken systems, but you have to be thoughtful about it, and reflect on what you learn, and not just be distracted by "ooh, new shiny framework will make this better!"

[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.

[Tade0]

I believe there's a way out of this and I've seen at least one successful attempt - it's having regular group practice/rehearsals/drills/wargames or, to put it in a more familiar term - internal projects.

On one hand developers get to scratch their "ooh new shiny" itch, on the other management doesn't risk any deadline from people trying new ideas when there's no time for that.

Unfortunately few employers are willing to go this route due to the associated cost.