This article misses that there is a business case for bad decisions. Sometimes there is no other choice than making a design shortcut, doing things that don't s

This article misses that there is a business case for bad decisions. Sometimes there is no other choice than making a design shortcut, doing things that don't scale, overcomplicating or overabstracting. There is no sense criticising these decisions, typically made for good reasons for which the current view of the code does not provide an explanation. Sometimes you don't win the contract if your service doesn't work in three months (game over), sometimes there literally is no funding for more engineers, or a system hemmoraging existential amounts of money needs to be hotfixed. Moreover building a system can be like discovering a new scientific theory, only once it has been developed in an overcomplicated or overabstracted way, does the simple case actually become obvious. If there is an "epidemic" of anything it's hindsight criticism of engineers who made the best decisions that they could. "Incompetence" is doing a lot of leg work in this article, this is not a real specific criticism by itself. To me this a symptom of over antrhopomorphising the failures of a company and glomming them onto a theoretical goblin for which you can blame the ills on. I believe this behavior emerges from engineers that have not participated at a decision making level in the entire software development process at many different sizes of company in many different contexts. This means a startup from zero, a large company where the marginal cost of issues is so extreme that all code is mobbed, a mid size company being bought out, being in charge of a service from ideation, to development, to maintenance and deprecatio.