Testify
First, read Roy Osherove’s post about TDD difficulties, then read this alt.net thread: TDD+Effort != Return.
Here’s the problem: I work with a lot of really good developers. Most of them agree that designing for testability sounds great. They’re interested in learning new technologies. But when discussing the various testable design techniques, they all go back to the coding style that they are familiar with, with the same old arguments of “it’s too hard,” “there’s no time to learn something new,” “I’ll do it next time.” The whole conversation condenses to “TDD sounds nice, BUT…”
A common answer I’ve heard for dealing with these developers is “fire them.” Not a very helpful answer 
Fire everybody, and replace them with whom? Or, we can work on training, mentoring, and making better tools. But how do you train somebody who doesn’t want to learn?
Wish I had more answers here. Maybe we’re just too focused on the [Fast|Cheap] angle of the iron triangle. Maybe there is something fundamental being missed, but we’re all so entrenched in our alt.net echo chamber that we can’t see it. Who knows. The search for truth continues.
I’ve faced a similar situation, both trying to get other developers to try TDD, and disciplining *myself* to invest more in TDD.
I’m convinced of the benefits, and continue to increase my test coverage for my own projects. Getting other developers to do it for theirs is difficult. In fact, I’m facing this right now. The argument I’m going to put forward is this:
* There are real benefits to TDD that will MAKE IT CHEAPER TO DELIVER SOLUTIONS.
* Most importantly, it encourages loose coupling, and that makes it much easier for us to change stuff. Period. We can roll with the punches.
* Also, we can introduce changes confidently, because tests will let us know when we break things. This is a *big deal*.
* Not testing is a “broken window”. You live in fear of the side-effects of change, and let bad code live on because it’s cheaper than fixing it. That problem escalates until the system finally requires re-build.
* Testing invites cheaper re-shaping, rather than expensive re-building.
* Depsite our doubts, if we NEVER *try* to get good at TDD, we will NEVER appreciate if these benefits are real. We just need to TRY it!
I’ll let you know how it goes!
Retrofitting a legacy project to work with unit tests requires more effort than using them on a *new* project. Do you have any projects coming up that could be good for getting on the learning curve as a team?
Jimmy Bogard adds in some tips to make TDD worth it:
http://www.lostechies.com/blogs/jimmy_bogard/archive/2008/09/21/ten-tips-to-maximize-the-return-on-your-tdd-investment.aspx
“fire them” is a bit harsh — try brainwashing instead.
But, realistically, I see TDD as one step of a process — and not the first step either. I do believe there are more important ideas that should come first, or TDD will be incredibly painful. Things like good Object Orientation, Patterns, source control, one step builds, and making maintainability to be more important.
Back to a previous post of mine, sometime there are things that require us, as developers, to rethink how we make software. This is painful. Developers are smart thinking, it is hard for us to be convinced that what we have been doing is wrong — since we know it has been good enough for us so far.
Finally, I will completely agree with Roy (even tho he really just trying to sell something) in that we really need better tooling. We need better wording. And most importantly, we need better guidance.
Because we have bad wording, it leads to bad guidance. Because we have difficult tooling, we create pain in development.
But you also hit on one. Because we promote development speed over practice, we are not creating better developers. And as such, we are not getting beyond “good enough” software.
I found the “fire them” replies symptomatic of what is starting to hack me off about ALT.NET.
The ego and smugness are holding things back.
TDD is not the norm in .NET and that is a fact. Certainly where I am in the world.
I started the thread after reading Roy’s article (even though it was not his point) and part of me was playing devil’s advocate to see what came back.
I love TDD and have loved it, especially after i now get regular reward.
But the learning curve was high, especially as the team I started using TDD with had no TDD experience.
A lot of dev.s where resistant when our first tests became unsuprisingly unmaintainable.
Not everyone can have or afford a coach and every blog I read is singing its merits.
The first time you stop a bug going into production because of your tests is the moment the green light goes on and you are hooked.
I appeal to professionalism. It is unprofessional for a developer to ship code that they don’t know works. The only way to know is to test it thoroughly. The only way to do that repeatably and efficiently is tdd.