Recently there has been a heated discussion about the comparison between Ron Jeffries’s way of solving Sudoku with TDD and Peter Norvig’s solution. After reading all the comments, I have to say that it’s a stupid discussion. I have at least two reasons.
First, Sudoku is not the appropriate topic to base the comparison on. It’s the kind of problem that requires relatively complex algorithm but has well defined requirement. In this case, the requirement is: Solve the Sudoku. But if you ask the majority of business application developers what kind of requirement they get, the answer will most likely be something like “Make it work”, “I can tell you. But don’t expect the same answer six months from now.” or “Requirement? We are not sure”. That’s the challenge the main audiences of TDD are facing. Whoever says you don’t need TDD in this kind of situation must be either a genius or insane. No, let me rephrase that. They are just insane.
Second, Ron Jeffries’s example is terrible. He seems like the perfect guy to reference if you want to badmouth Agile and TDD. He made it sound as if TDD eliminates the need for upfront design. That’s not what we do! Brainstorm/design sessions happen a lot more often in an Agile team than in a traditional development team. TDD is there to insure that we don’t write unnecessary code and all the code we write are covered by tests. These tests are usually white box tests. We already know how we want to implement it. We just want to make sure it works and continues to work over time. There are, however, times when we have to write black box tests. That’s when we were given a chunk of legacy code that nobody knows how it’s supposed to work. We have no choice but to gather the up-to-date requirements, write test to demonstrate them and refactor/rewrite the legacy code to be readable and working.
That’s my take on this debate. Ron Jeffries is not a good representative of Agile. There are better guys out there.
