by Well folks, I'm here today to gripe about Test Driven Development (TDD if you can't live without an acronym). For those unfamiliar with it, the concept is (and feel free to correct me folks), one starts coding the unit tests firsts and implements the various classes/structures one needs to make the unit tests function. By the time all is done, you have a completed, working, and unit tested application. Re-factoring is embraced, heck there's even the TDD mantra: “Red, Green, Re-factor” (which comes from the Nunit paradigm of failed unit tests show up in red, running one's show up in green, and the re-factor refers to moving code around / renaming classes functions, etc to make more sense in one's project domain. Essentially it means, when just the test is written, it will fail as there is no concrete things to actually perform the tasks the test requires. Once you right just enough to make the tests pass, it passes (green) and is now ready to be “integrated” into the rest of the project with minor corrections).
Sounds good in theory doesn't it? Unfortunately, I don't live in Theory (houses are far too costly…) Why only in theory you ask? Well, as I sit here writing some tests so I can actually code the logic at some point, I'm looking at some diagrams of system interaction and whatnot and I frankly have no idea what the hell the tests are supposed to do… I have nothing to test, and using TDD, at best, I'll have tests that work and they will dictate what I build, unfortunately, the business wants me to build something particular. Depending on how well I do it, I could end up with something that is what they asked for, OR I could end up somewhere completely different if my understanding is off or I get pulled into the cadence of test code (vs. application logic which may be optimized for performance or maintainabililty, or whatever).
Basically, what I am getting at is, TDD is helpful when you don't know what you are building. However, if you don't know what you are building, why the hell are you building anything? Your time would be better spent fleshing out the requirements and the design. And before you say it (because I KNOW you're thinking it), “But the business doesn't know what they want, just what they think they want and I need to deliver what they NEED!” Well, I agree, so wouldn't expectations be better managed by working through requirements with the business so everyone is on the same page, wouldn't you know better what you are trying to build? I think so.
So where did it all go wrong? To put it bluntly, <flameShield on=”true”>Inexpereienced Developers are the majority of the workforce, and they often make mistakes (as doing is the only way to build experience, this is expected, and natural (albeit problematic)) TDD is just another way to homogenize the programming workforce to reduce the negatives.</flameShield> The downside is it also reduces the positives of having an “All Star” team. People also cite “quicker to market” reasons as by the time development is done there is something to deliver. This is just slight of hand to avoid the problems of managing business expectations. Cough up more frequent milestones and vi'ola, it looks like things are getting done. Unfortunately in reality, the same time is spent, and I propose, MORE time is being spent with TDD refactoring every pass and of course the final refactoring to align the new code with the existing code (which to be fair mostly amounts to renaming of classes, functions, etc, not so much new coding)
To me it just sounds like an excuse to not have to learn more formal documentation and requirements skills. I think knowing what you have to build is far more important then delivering it quickly. The old adage goes, “You can have it done Fast, Right, and Cheap. Pick any two.” This technique addresses the disconnect between the developers and the business that employs them who know very little about software development (think Business Programming here, not so much Software Development shops 😉 ) I firmly believe a much better approach is to teach the business what they need to know to manage software development projects, because we as developers don't have that skill, our magic is programming and archetecting, management is for the pointy haired boss types.
 Ok, I'm done. My apologies to anyone I've offended! Please feel free to correct me, I'd love to hear your thoughts!
I should probably mention Martin Fowler's book, “Refactoring. Improving the Design of Existing Code” as it's pretty good, although seasoned developers will likely know a lot of the items in the book, other books seem to reference this one (for example, “Refactoring to Patterns” by Joshua Kerievsky”)
-Regards!