>Doesn't really help:

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.

It wouldn't help much in this case, because of Apple's "functional" team architecture - basically if you add more people to each project then there is no way for them to contribute in a way that adds up to a fulltime job.

This is a little simplistic. Investing more in the quality component of the org - valuable.

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).

It is valuable if you do it right, but it's difficult.

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."