I don't agree with the document, though I do agree with the idea of increased engineering rigor. I think that the value of this isn't in what it suggests doing

I don't agree with the document, though I do agree with the idea of increased engineering rigor. I think that the value of this isn't in what it suggests doing--because it's looking at the wrong things and is wildly out-of-step with how development is actually practiced--but in what it gets wrong, and why those things are wrong. For example, there is a large focus on "size"...lines of code, pages of documentation, etc. These are metrics that lend themselves to straightforward analysis, but are incorrect--a developer writing a one-line map with a lambda is doing better than her peer using an explicit loop. At the same time, her other colleague who is doing everything with one-letter variables and no linebreaks is doing better quantitatively (fewer lines!), but is creating massive technical debt. It's interesting to see these efforts.