The idea that a schedule is God leads to infinite defects
A great example of this is recounted by Joel Spolsky [1] who was a project manager for the early Excel team (but presumably the problems in the Word team became legend):
[In] the very first version of Microsoft Word for Windows ... the project managers had been so insistent on keeping to the “schedule” that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote “return 12;” and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as “infinite defects methodology”.
Immediately brings to mind: The first book I read on TDD recommended writing "return 12" and waiting for a test that fails. So I guess PR/marketing could say Microsoft pioneered an early form of TDD in WinWord, combining it with the power of pair-collaboration between a developer and a tester. Just one more in a long line of MS innovations.
Your book seems to be selling a peculiar flavor of TDD. Typical TDD says you write the failing test first. You don’t wait for it to appear after writing your broken code.
It's not that it is the first thing written--it's that it recommends writing broken code like "return 12" until a test knocks it down. I think that book (it's been 15 years!) went through a currency-exchange example, but you know how they go: write your first test "The sqrt of 4 is 2".. make it pass "return 2" etc. In all cases, the person writing the code knows it won't stand, but they do it anyway. That was the parallel which prompted my comment.
A great example of this is recounted by Joel Spolsky [1] who was a project manager for the early Excel team (but presumably the problems in the Word team became legend):
[In] the very first version of Microsoft Word for Windows ... the project managers had been so insistent on keeping to the “schedule” that programmers simply rushed through the coding process, writing extremely bad code, because the bug fixing phase was not a part of the formal schedule. There was no attempt to keep the bug-count down. Quite the opposite. The story goes that one programmer, who had to write the code to calculate the height of a line of text, simply wrote “return 12;” and waited for the bug report to come in about how his function is not always correct. The schedule was merely a checklist of features waiting to be turned into bugs. In the post-mortem, this was referred to as “infinite defects methodology”.
[1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...