While what you said is true, the problem usually don't manifest in the way you described. Most engineers I know understand all these principles and adhere to th

While what you said is true, the problem usually don't manifest in the way you described. Most engineers I know understand all these principles and adhere to them. But the codebase still end up a huge mess. Code evolves. The technical decision you made when you were serving 30 customers doesn't make sense anymore now that you're serving 30k. The corner case you never thought would happen turns out to be very common. Suddenly your boss decide you should sell on-prem solution whereas you've been building a cloud offering. You can make the best decision every time these new requirements come along, yet still end up in a disaster, because hill-climbing algorithm can get you stuck in the local maxima. Oh, you say, you should've refactored your code, or rewrite from the scratch! OK, now you need to choose between spending time refactoring your code or delivering features. That's the trade-off! Hmm ok, you say, you should've refactored along the way, so you don't need one giant refactor! Great, now you've basically asked me to predict the future. So, shipping new feature and code quality is definitely a trade off, and is the job of us, software engineers, to make that call appropriately :)