In-Process versus Outcome Measures
The recommendation seems to be toward in-process measures as these are the only measures that can help guide action. Although these have been proven to work really well in the production industry, it is instructive to note their implementation in the software industry.
Software shops tend to institutionalize measures, such as lines of code, number of functions, cyclomatic complexity, etc.. Although these are in-process measures, they have been confused by their implementors to be in some way, an indicator of quality or productivity. If LOCs are to be maximized, then organizations ought to hire stenographers and not computer programmers.
On the other hand, if LOCs are to be minimized, that might force teams to refactor, revise and shorten. That might not be a bad idea after all.
The point in this section is that the right measures matter. Not any measure.
At any point, knowing the percentage of coverage could help programmers write more tests. However, it does not usually affect the quality of the tests. It is hard to believe that the quality of a test can be quantified in repeatable manner. That is also something the authors bring out, in that the measures are meant to be a soft guide with a "light touch."