Those are rookie numbers. With a little Kubernetes, we can get them way up. So much of the incentive structure in software companies is to ship new features. Maintaining existing ones or fixing bugs is a career dead end for software engineers and managers. No wonder so much stuff is broken and slow. Call me cynical, but from a dollars point of view this seems to be what customers want.
I agree. I have to really fight people when I try to write robust software. "Why are you writing a proper parser when a hacky regex that I thought about for 2 seconds worked the one time I tested it? You're wasting time." They don't understand that I'm not wasting time, I'm just choosing to spend a little bit of time earlier, because I don't like spending a lot of time later when debugging why everything broke.
With buggy ship-it-now software you have a known bounded risk - bugs will occur in some cases but the software will ship and the bugs can be fixed because it’s simple.
With prematurely architected software the risk is unbounded - the project may get bogged down indefinitely in its own complexity without shipping.
The inverse extreme can also be a problem, of course A project that is maintained for a long time on the naive implementation will also become unmaintainable. However, this will be due to _known_ architecture problems encountered during maintenance. These problems can be addressed in a relatively bounded amount of time. They are also quantifiable and thus explainable to management.