Sean O'Donnells Weblog
It all began when Ravi Mohan invited his readers to compare Ron Jeffries and Peter Norvigs attempts at building a Soduku solver. You really should read both attempts, as they are very educational, but to save time its pretty clear that Norvig wins by a wide margin. Many Test Driven Development fans took umbrage at the comparison and rushed to Rons defense. The most eloquent argument in Ron's defense I have found is Vlad Levins "TDD is not an algorithm generator". While well written Vlad's argument rings hollow to me, he seems to believe that an "Algorithm" is not normal code, that it is some sort of special case, and as such TDD is not the tool of choice as it is everywhere else.
Well, first lets ask , what is an algorithm?
Wikipedia's definition of Algorithm:
In mathematics, computing, linguistics, and related disciplines, an algorithm is a finite list of well-defined instructions for accomplishing some task which, given an initial state, will terminate in a defined end-state.
A finite list of well-defined instructions, this sounds like software. The definition is all embracing with little room for exceptions and special cases . There are well known and commonly used algorithms, such as QuickSort, that get taught in "Algorithms" Courses in "Algorithms" text books. But the truth of the matter is all code implements an algorithm of some sort. Those found in the text books are simply a list of algorithms that are generally useful in many projects, and so are worth teaching and passing on. When we develop something new, we take some of the well known algorithms, and mix them with something new, algorithms of our own creation.
TDD is presented as resulting in better more reliable code, which translates to better more reliable algorithms. And the contrast between Norvigs and Jeffries results shows that this is simply not the case. The cry of "Not an algorithm generator" is equivalent to saying you should not use TDD to write code if you don't already know how you are going to write it, if you are trying to solve a difficult problem for the first time do not use TDD.
I do not actually believe this to be the case. I am a fan of TDD and use it whenever possible, However I am also not adverse to sitting back and mulling over a problem for an hour or two in the middle of coding, call that design up front if you will, but Norvig's solution proves that this can also generate good results.
The real problem here is that TDD generated obviously inferior results in this case, and while Norvig did well, he did not provide a Methodology, after reading Norvig's article I know how to solve sudoku, but I don't think I can solve a completely different problem in a Norvig like fashion.
This is a challenge not only to TDD, but to the Norvig's of this world too. If TDD on its own cannot be relied upon to provide great results then there is something we are missing. Perhaps Agile needs a new practice, perhaps the Norvig's of this world need to document their thinking practices. I don't care where the answer comes from, but I want someone to teach me to think like Norvig.Share on Twitter Share on Facebook