The problem is software engineering discipline is wrought with missing the business context and ROI. Everyone talks about unit testing, clean code, refactoring,

The problem is software engineering discipline is wrought with missing the business context and ROI. Everyone talks about unit testing, clean code, refactoring, tech debt, documentation and whatnot. But no one talks about how much unit tests is appropriate for a project. A front-end for a simple simple CRUD todo list shouldn't have as many unit tests as a safety critical application. Unfortunately no one talks about this. I have seen a startup where ciritical data processing infrastructure doesn't have any kind of tests because the management doesn't understand technical importance. While the front end team which develops a simple web interface for just showing the data to customers follows TDD, tries to achieve 100% code coverage, every single function has documentation, extensive code reviews and whatever new clean-code techniques you can think of. Not surprisingly the front end team has 6 times more people than the data processing team. Obviously bad management is to blame here. But I can't help but think how much all these tech debt and clean code artciles on the internet is responsible for this. Advising people blindly to follow some development methodologies without the discussion in which contexts these methodlogies are acceptable, what are the costs and what are the trade-offs. There's a lot of resume driven developers out there find these articles and waste business resources to fill in their resumes.