OK. So this is going to probably be a controversial posting.
Just call me an old crusty code warrior.. but..
It’s no secret I’m wholly unsold on test driven development [wikipedia] (TDD). I have nothing against testing or writing of tests, it is vital to the overall success and stability of any quality driven software. However, I have a major problem with the strategy that pits developers into the writing of tests (to prove design even) before writing any of their implementation. This is why..
1. It’s Inefficient/ineffectual – my experience leads me to believe that there are far too many changes (or requirement churn) during a development cycle (be it an iterative MSF/Agile development project or traditional waterfall methodology). By the time a developer has had a chance to write out all the possible test scenarios, what are the odds that the business logic changes? Then, aside from not having written any code, there are a bunch of unit tests to rewrite. Even worse when a change request comes in mid-stream. In other words, nothing really gets achieved but a few hundred odd unit tests which become unmaintainable (broken unit tests are useless) – does this mean perhaps that cost outweighs the reward?
2. It can create bottlenecks. What’s the worst that could happen? Someone (a developer) spends a decent portion of their budgeted time allocated to building up the tests first (even design oriented ones). Without some superhuman micro management there is a great chance that another developer will be blocked, waiting for the actual implementation to be produced. Personally, I prefer not to foster the development of bottlenecks or resource contention..
3. It reduces all developers to the same level, regardless of levels of quality or attention to detail. For my mind this is a way of ensuring a specific level of quality (meandering to the average) whilst punishing the talented (and less bug prone) developers from just getting the job done in the first place. Kind of like a speed limit, reducing the ability for skilled drivers to go faster due to the most common denominator.
To this end, I suggest "different rules for different tools" (I mean tools in a nice way). I can understand why graduates and intermediate developers might benefit from a tightly managed TDD driven policy. Seasoned developers though, may find such a blind principal to be too restrictive (not too mention overkill). TDD should be considered where it is likely to add the most benefit without causing more impact than it merits.
Yes, I know I’ve singled this out on its own, and TDD rightfully or wrongly should be coupled with other implementation and project management strategies…
What are your thoughts? Do you violently disagree? Can you suggest an alternative? Be creative and add a comment..