His advice needs to be contextualized within the 90s and 00s. He was correcting (or overcorrecting) for issues that were prevalent then: methods that were hundreds or thousands of lines, processes with hundreds of hours of design work without writing a single line of code, no testing (or maybe handing to a QA to test, if you’re lucky), and tangled messes of logic the author thought could be saved by adding a comment.

Much of his advice seems silly or extreme now, but I believe that’s because he (and his cohort of likeminded programmers) won. Things have improved dramatically. The extreme advice worked. The problem, of course, is that you can’t just declare victory and move on. So now we have The Church of TDD and the like.