I just do not think that TDD is like a magic dust that you can sprinkle on your work and make it suddenly right. Not so; like many good things, becoming proficient with TDD requires time, work, and dedication. The poor results of that evening could also be the result of me trying to have you do too much in too little time, with people who had a full day of work on their shoulder.

Still, what are the alternatives to TDD? Formal methods and program derivation are too difficult. Unless you’re doing aerospace-grade software, it’s not practically possible to apply them. At least I can’t apply them successfully to my work; and while I’m certainly not the brightest star when it comes to math reasoning, I’m probably average, so that most other programmers would have the same problems that I have.

What other method there is? “Guessing a correct solution and expressing it in correct code that is also readable and mantainable” is not really a method, it’s a goal. How do you get there reliably? A few gifted individuals can do that. I know I can’t, and even if I did, I could not teach this to others. It’s really code and fix: if you’re good you can make it work, sometimes.

What else? The conventional advice is that you do “design” before coding. I have no objection to that; I do design in my head before coding, I often discuss design with collegues so that we all understand what we’re trying to do. You just have to be ready to change the design when you find it’s not adequate. A design is like a plan, and “no plan survives contact with the enemy”, that is, when you try to execute your design you realize it’s not adequate. So, no matter how much design you do, you are still left with coding as a difficult technical activity.

I think TDD is the most exciting and useful advance in programming technique since OOP. The technique is still evolving and I’m ready to believe that it’s not the end of the story, and some day something better will be found to replace it. That day, I hope I’ll be around to be excited about it.

In any case, I did not mean to say that the OO techniques for decreasing program complexity are less or more valuable than the ones I present here. What I’m telling you here is just a different angle.