His steps 4 through 6 seem to completely violate the principle of YAGNI. It also seems way too much like big-bang releasing. You write all this code for a very long time and don't have any way to objectively say the design is correct (in that it actually performs the business case from start to finish) until the very end.
I've designed systems in this way before (strangely, they always seem to be some sort of document validation), and they always turn into complete hairballs of code that eventually gets thrown away and something much simpler substituted.
That's why I thought this article was honestly the case against TDD. Because the upfront "this method has major problems" stuff rang very true, but then the "this is the correct way to do it" made me wince hard, with its Java-esque upfront complexity.
I like to always start with YAGNI, and then try some of these exercises after I already have something that kind of works - its much easier imho to refactor something that is simple and gets the job done, i.e. add-to versus something that is wrought with way too many abstractions and such.
I've designed systems in this way before (strangely, they always seem to be some sort of document validation), and they always turn into complete hairballs of code that eventually gets thrown away and something much simpler substituted.
Now, I just stick to DRY, YAGNI, and "Compression-Driven Development" http://mollyrocket.com/casey/stream_0019.html