TDD Is Not An Algorithm Generator

I think far too many people fail to make the distinction between designing an algorithm and designing a program (which implements it).

This is why I have to watch co-workers create dozens of useless error classes and utility functions, and totally ignore YAGNI, before actually taking a single step towards a working program.

If you don't know the algorithm, and haven't figured out the abstractions, then just slinging some implementation code is the easiest (and laziest) thing you can do. It's basically a way of avoiding having the necessary conversations. In this case, the question that needed answering before beginning TDD was: "How does one efficiently solve a sudoku puzzle (as opposed to just manipulating one)"

The "design up front" in TDD is hidden in the write code / refactor steps. The pure TDD framework is bogo-sort for code: start with no code, bang randomly on keyboard, test if it passes, if not then repeat. Obviously something sensible has to go in that gap.

What it usefully replaces is bikeshedding. It lets you try out the design you have in your head, in bite size pieces.

Good holistic take on that article.

Also I applaud Ron for posting an utter failure to get the job done. MANY people run into issues like this (lord knows I have) and documenting it for everyone to see is something we need more of.