"This is surely the most ignominious debacle of a project listed on my site, even though others have also not shipped. (Sudoku did not ship and will not. [...])"
Or ever. If we want to some colleague to tell us what is good code and what isn't, can we please pick someone who at least once demonstratably delivered good software? Bonus points if it was a group effort, and if it was on time.
Common for all these "industry leaders" is that they all write books and give speeches. I'd rather listen to someone who designed successful software such as git or OpenSSH than someone who designed a salary system in the 90s which, it turns out, was scrapped two years later for being a mess. Giving yourself a stage name is not a merit in itself.
There is something to be said for actually understanding the problem first. Did we learn nothing from the TDD nonsense in the 00s?
The famous InfoQ sudoku software design example was chronicled on HN here and should be required reading for anyone who cares about clean code in practice:
Discussions about TDD always make me think of Ron Jeffries' attempt to develop a sudoku-solver using TDD.
That attempt is discussed in Ravi's article: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
Peter Norvig wrote a sudoku solver, not by using TDD, but using old-fashioned engineering: http://norvig.com/sudoku.html
Ron Jeffries' attempts:
http://xprogramming.com/articles/sudokumusings/
http://xprogramming.com/articles/oksudoku/
http://xprogramming.com/articles/sudoku2
http://xprogramming.com/articles/sudoku4
http://xprogramming.com/articles/sudoku5
And, as dessert (Ron is very frank about his failures):
http://xprogramming.com/articles/roroncemore/
"This is surely the most ignominious debacle of a project listed on my site, even though others have also not shipped. (Sudoku did not ship and will not. [...])"