[Tabular-Iceberg]

> If you're tired of working with legacy code without tests, most of your suggestions for improvements will be met by a shrug. We don't have time for that now. It's more important to deliver value to the customer.

This is what bothers me the most. Whether it's about tests or something else. Even clean slate "let's get everything right this time" projects degenerate into legacy code within weeks with this mindset. The "It's more important to deliver value to the customer" line is especially insulting, since it's not as if the developers are trying to sabotage the delivery of value by writing tests or sanitising input or whatever the conflict is about. We know that high quality code is faster and cheaper to build than low quality software, but it's counter-intuitive to most managers.

And you need sympathetic managers to get the software right. Business rules are rarely clear, orthogonal or consistent. Which is not actually a problem for humans, but until we have artificial general intelligence, it is an insurmountable one for computers. But unsympathetic managers will not want to have long, uncomfortable conversations about deducing what they actually need from what they think they want. So developers are instead forced turn messy rules into messy code as best as they can, and put out fires whenever they break out, which they will all the time.

And perhaps the most insidious thing of all, spending all the time putting out fires means they don't get real world experience they need to build a robust system on time. If managers let them try once it would just make them look incompetent. And if they quit, their experience putting out fires will be worth nothing to companies who actually value proper workmanship. Their only option would be to join another death march company.

I think this the biggest reason why most software, especially enterprise software, is so bad, and isn't likely to improve in the foreseeable future.

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