Is TDD an objectively good methodology?

The short answer is, yes, I think it is.

But, this post is in reaction to an email conversation (portion reproduced with permission) that I had with Aaron Erickson:

"I think anyone who works in the real world knows cases where TDD wasn't used, but happens to be successful.  Steve Yegge had a good analogy - you can start with warmed over shit, but if you add enough chili to it, you get chili.  People that do TDD suffer from selection bias - meaning - only good developers are doing TDD.  Which, of course, makes the results so far seem good.  Trust me - once it gets to the masses, it will have about the same success rate as any other methodology.  The good will write good software using it, the mediocre will write mediocre software with it, and the sucky programmers will still be sucky with it.

I will be more convinced when a methodology makes a bad programmer better.  I think I will spend a long time waiting for that to happen ;)"

Now, there's a certain level of cynicism/skepticism in Aaron's comment.  As a cynic/skeptic myself, I can relate to it (and how far he would go in defending this as totally serious I would leave to him). 

But there is a point to it.

I think it takes a certain level of skill and education to learn TDD/MVP/IoC, etc.  I don't think education is enough as there is a certain level of 'innate' (for lack of a better word) ability to be able to pull this off successfully.  This is where I think I disagree with the 'idealists' of the Alt.NET crowd.  By definition, elite developers are in the minority.  To be fair to the idealists, I do think you can increase the number of developers who can successfully pull off programming using these advanced techniques.

Having said that, I think it is clear that you can do TDD, etc. poorly and the wider the range of programmers who are exposed to it, the more mediocre to poor results you will get with it.  I'll use myself as an example.  I'm egotistical enough to say that I'm clearly intelligent enough on some basic level, but whether I have the skill set to be able to implement these advanced techniques is open to question.  I'm trying (in every sense of the word), but I have no realistic expectation that I will be able to code at the level of an Ayende or Jeremy Miller.  I just hope to be able to implement them well enough to provide business value to my clients.

Or at least not do it poorly.  But, a question I have raised previously bears repeating: how can you prove objectively that certain advanced techniques are in fact advanced?  I certainly believe that some of them are, otherwise, I wouldn't be trying to learn them.  But how do you prove this?

And how do you prove which techniques should be applied in particular ways?  As I implement MVP on a project, I find there are (exaggerating) 147 different ways to do it.  Well, which one is best?  Or, at least, which one is best for the project that I am working on right now?  How can I know?  The Alt.NET guys get into fights over this at times.  So, if I'm using them as guides to, well, guide me, who should I believe?

posted on Monday, June 25, 2007 8:45 PM Print
# re: Is TDD an objectively good methodology?
6/27/2007 5:38 PM
I think you're dead wrong, TDD is the silver bullet we've all been waiting for! The sucky guys will no longer suck! The mediocre guys will become language wizards and the good guys go to heaven. Halleluia! :-p

Sorry for the tease! :)

Post Comment

Title *
Name *
Comment *  
Please add 1 and 5 and type the answer here: