The Inquisitive Coder - Davy Brion’s Blog

There’s a debate going on the ALT.NET mailinglist about whether or not teaching developers TDD for a project is worth the cost. I don’t really like the way things are discussed on that list nowadays, so i’m posting my thoughts here.

First of all, it’s definitely true that learning how to do TDD effectively takes some time and the learning curve is rather steep. If you need to bring people who are new to it up to speed, you definitely have to invest some time in that. So, is the time and effort spent on that worth it? I think it most definitely is. If you take the time to teach them how to do it properly, you can enjoy quite a few benefits.

For starters, the developers will improve their skills, not only in writing tests, but also in writing flexible and simple code. This can take some time, but if you’re coaching them properly you should get this situation under control in a couple of weeks (somewhere between 2 and 4 weeks depending on the number of developers that need to be coached, and their general skill level). The quality of the code (and the tests) that they’ll produce after this period can reduce your total future workload by a large quantity. I think most of us know what it’s like to work with code that is anything but flexible, and what a negative impact such a situation can have on your team’s productivity: things that should be easy to change, features that should be easy to add can become mind numbingly complex to implement without introducing bugs to existing code. I’ll gladly coach a few developers for a few weeks if that means avoiding a code base where people are afraid to make changes or where change in general is lengthy and painful.

Also, during this period where you have to do intensive coaching, you can still make progress in the project. It’s not like these developers have to learn these practices and principles on throwaway code. Have them work on real stories for the project. Double the estimates for those stories, and don’t assign any stories to the person(s) doing the coaching. Make sure they have enough room to help the developers that need the help and that the code (and the tests) are up to standards before the stories are considered done. If you’re coaching them right, you might be surprised how fast they’ll pick up the pace. You’ll definitely take a large productivity hit in the first couple of weeks, but after that your team’s productivity will go up rather fast and before you know it, you’ll have made up for all the lost time and with a healthy code base to boot.

Now imagine not investing that time and effort. Without even thinking about who’s going to write the tests, or when they’ll be written, suppose you decide not to spend the time and effort to teach them TDD. You start the project and everyone starts implementing features. Some people will write good, solid, flexible code. And some people won’t. Their code might stay in this unhealthy condition, or it might deteriorate further. But hey, your team’s productivity in the first couple of weeks sure is impressive right? Fast forward a month or two, then tell me how the productivity of your team is. It probably won’t be as high as it was in the first couple of weeks. Oh, and keep an eye on team moral. Chances are that some developers will be terribly frustrated by some of their teammates’ inability to write good code. The rest of the developers might be frustrated because some developers are too demanding and bitch too much about how bad their code is. All in all, chances are high that it’s not going to be a fun team to work on.

Now, as for the teaching and the coaching… this can be a relatively easy job, or it can be a royal pain in the ass. It all starts with the developers’ willingness to learn. If they are not willing, get rid of them. Yes really, get rid of them. You’re only doing them, yourself and the rest of your teammates and your organization a disservice by keeping them on staff. If they are willing to learn, make sure that they realize that you are there to help them. If they are afraid or hesitant to ask questions, then you are definitely doing something wrong. They have to be certain that you will do the best you can to help them, and that they won’t get ridiculed if they ask stupid questions. And let’s face it, we all asked ’stupid’ questions when we were learning these things so you sure as hell shouldn’t make another developer feel bad when he/she is in the same position you were a few years ago. Also, when they do good, make sure you reward them by showing them more trust. You’d be amazed what kind of a positive effect that can have on a developer who’s trying to learn a new approach. And never ever simply tell them what to do and what not to do. Make sure you explain everything! If they see you’re taking the time to make sure they understand why you’ve given the advice that you’ve given, they will usually appreciate it and they will certainly learn a lot more than they would’ve if you had simply told them not to do something.

All in all, deciding against teaching people TDD is one of the worst decisions one could make IMHO. It may not always be fun and it may not always be easy, but in the long term, the quality of your project will benefit greatly from it. If teaching them TDD is painful, then you’re either not doing it right, or you’re working with people you probably shouldn’t be working with anyway. But teaching TDD is generally not hard, as long as one party is willing to really teach, and one party is willing to really learn.