The centering bugs are important. They show attention to detail. Humans are wired to see such sloppiness as indicative of deeper problems. If they can’t get the easy stuff right, it saps your trust that they got the harder stuff right.
It’s crazy because they have (or had) something like $100bn in cash. Spending 0.5% of that per year on software (development, bug-fixing, performance, and QA) would help tremendously. They’d be insurmountable.
I know “they don’t have to”, but they don’t have to do a lot of things that they do on the hardware side. They choose to.
Doesn't really help:
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Also, "bug fixing" tends to add new bugs - any kind of change can cause regressions. It's quite difficult.
TM3 is basically "if this is your approach to shipping sooner / more quickly, then you're going to have a bad time." It's not a solution for a delayed project. It's not "you shouldn't invest more in the infrastructure of a large project" (or at least not blindly).
I've been promoting a specific aspect of performance quality recently, but it's mostly lead to other teams creating tests to monitor it that don't really make sense (along the lines of "if you use the computer it'll make the CPU % go up"), asking me to look at it, and then when I say it's probably fine I get a response along the lines of "it must be important because we already told all the executives about it."
That's just a classic software development book. What makes its lessons scientific fact?
Also, it's about a singular project that's late.
Not necessarily applicable to dozens of projects with understuffed teams. Adding people to such teams to help, and assigning new people to look and fix bugs nobody cares about now because they're overworked on some "flagship" new features, is a different case.
Centering is not easy. Apparently. It requires human eye to verify. I can prove my decryption algorithm works. I can’t prove centering works.