Wednesday, July 04, 2007

TDD, or not TDD?

I'm pretty convinced that TDD (or better yet, BDD) is the way to go. As usual when I get to this stage, I no longer care a lot to discuss the issue. However, I just hit on an interesting article... one that I find particularly weird.

Ravi's point appears to be that TDD is rather useless... and / or that Peter Norvig is a much better programmer than Ron Jeffries. The thing is, as I said here I managed to solve the whole thing in about 8 hours total. Worse, I only did that once I started with a consistent test-first approach, my previous 3 or 4 attempts ended in failure.

So. While I have a huge ego (not so huge not to accept Peter Norvig as a better programmer than me though), I have strong doubts that I'm a better programmer than Ron Jeffries. I think that Vlad's article hits on part of a problem: discovering an algorithm using TDD is at least difficult, if not impossible - and TDD was not meant for that. I also think that Ron simply gave up - in fact, I also did that, several times - because the effort required to figure out the solution was not warranted by the importance of the problem. He started on what was probably the wrong idea and hasn't tried to get out of that box and re-think. If you will, he is guilty of having a (wrong) design up-front [grin].

(In my case, the issue was never the algorithm: I had in mind from my first attempt the final algorithm: try to discover "forced" values, where a cell can only have a single value, and repeat that until there's no such constrained cell left; after that, go with a "greedy" recursive algorithm where the first possible value of a cell is chosen, the whole algorithm is re-invoked, and if no solution is found go back and try the next possible value. I must admit that Peter's optimization "try the cell with fewest possible values first" never crossed my mind.)

So. In my opinion, TDD / BDD is quite useful... even for writing a Sudoku program :)