People who actually write software understand that you have to optimize for throughput first. Not to worry: latency won't be forgotten! But a primary focus on throughput will result in a clean codebase, that will maximize throughput and minimize latency.
In practice latency is the goto target for optimizing actual processes. It's the most linked with all the risks. But software development is not an actual process.
Exactly. And it's quite wrong even without taking the growth of complexity into account — as every engineer knows, or should know. Getting every task done as quickly as possible requires a lot of context switching, which is murder on throughput. When you add in the effects of complexity growth (aka technical debt, though I think "complexity growth" is clearer) the disadvantages of optimizing for latency become that much more serious. And the worst part is, as the disease progresses and latency deteriorates, managers try to cure it by applying even larger doses of the poison.
This idea that managers optimize for latency, while I optimize for throughput, occurred to me only recently. But as I look back over the disagreements I've had with managers through the years (including disagreements over the usefulness of Scrum processes!), it's quite remarkable how many of them seem to come down to this.
These books are not about software development, but of product development in general. The first one actually predates agile, published in 1997.
Core idea is that minimizing the size of the tasks is the best way to improve productivity. Not getting it done as quickly as possible, but to decrease the size.
Remember that product development (new, innovative, uncertainties) vs product manufacting (repeatable), is not a new problem, and not unique to the software industry. There's a lot to learn from product development in other industries.
Another interesting read is "The Toyota Product Development System: Integrating People, Process And Technology" which talks about ways of making product development predictive, and less risky.
It's interesting to see how little software is used to improve the process of software development. Other industries use a lot of software (cad/cam, visual modelling, testing, impact analysis) to improve efficiency and quality of product development. Software for product development is a huge market.
The problem is that except on the bare minimum, latency is a bad proxy on development projects. So the idea is perfectly correct, yet it's useless.