I'd say the problem isn't DRY (People duplicate code way too much. The "rule of three" is too conservative. I am looking at an if-then-else ladder right now that is 250 lines that could easily be 25) but rather a high prevalence of "snake oil" in the industry that discredits any effort to improve things.

For instance there is the split between Microsoft and Open Source where people mutually think the others are idiots. (It used to be evenly split, now it is definitely one sided)

There is the anti-OOP hype train and the associated "functional programming" hype train. (I've met so many programmers who travel from job to job like an itinerant martial artist looking for some productive workplace that uses FP and became miserable in the process.)

Programmers have grown thick earflaps and it is not at all unusual to talk to an engineering manager who says "we write tests first", "we implement error handling with monads", and "we do code reviews" but when you get into the code base you find there are very few tests, errors get ignored silently, and obviously they can't be doing code reviews because otherwise the engineering manager would know the first two are the case.

The problem is not that OOP is bad or FP is bad or any particular practice is good or bad but that programmers have become intensely cynical and any effort to promote "best practices" of any kind runs headlong against resistance, "normalization of deviance" and production pressures.

Very good article.

Much of OOP code suffers from classitis - too many classes doing very few things, so now you need to keep in your head hundreeds of them for even simple things. Similar things happening in infrastructure with microservices - problem on dev side is moved to infrastructure and it has its own new and funky problems nobody understands.

After 20+ years in IT, I find that simple things, with a little bit of ellegance here and there, are the best regarding maintenance and velocity.

Also, no specialized tools, I prefer OTB scripting over enormous IDEs any time, as any computer in the wild can be my IDE then. People usually complain to me that they don't want to do it beause of the performance, but honestly, one needs performance very rarely compared to the volume of written and quickly needed code.

There's no such thing as "no architecture". If you have code, you have architecture even if it's not formally defined. If you don't have software architect on the team whose whole job is to lay out architecture for the team - then you're more likely than not to have "bad architecture".