Poorly built software is the other side of the coin of over-engineered software. They both exist because users carelessly use software products. By not exercising the code enough, or system failure not costing the business more penalties than they can bear, incompetent developers will continue to get away with building things haphazardly –not as relates to tech stack, but the nitty-gritty implementation details they gloss over without adequately thinking through

Because of this, there doesn't seem to be sufficient incentive for thorough planning –what could be referred to as over-engineering. Those fancy pedantry in code mostly goes unnoticed by the end user. Of course, this doesn't apply to big corporations in most cases. It's usually unexpected to see elementary bugs in them

I would go so far as to say that for some businesses there are examples of bad codebases that has been "working OK" for years and years - and that makes them doubt if it's even worth doing great code.

As long as the system is non-critical: if it was developed in a a week with zero tests, zero code reviews, many KBs of unused code, slow ass ancient frameworks etc...it crashes a few times per year,.but it has been running ok for 7 years.

Then it's kinda hard to argue that "it should've been properly engineered!" if that would've taken 5x as long and done by a team who rebuilds their sites ever 3 years.

---

Of course this is short sighted, and those bad codebases only work since they were done by that one guy who has been with the company for 30 years, and if he left they'd all break and cause massive costs.

@jiraTicket when thought about like that, the industry seems a lot more dispensable ie not worth dying over the things some of us are hung over –sweating the small stuff and expecting credit for following patterns to the letter, doing things "right", etc. In most cases

@Nmeri17 Yeah it's beneficial to view things from the "enemy perspective" once in a while.

But I wouldn't go as far as to say that time is wasted on code standards. I'd say the importance of good code grows exponentially with team size and amount of changes.

A one-man project that does one tiny thing could work well as a quick hack. But if it's a team of 8 people working on it the business would pay an insane price for having 8 devs scratching their heads for hours every time they had to make a change.