I’ve been preaching about the benefits of Test Driven Development (TDD) for a long time and for the last two years I’ve been trying to introduce the idea to my team with limited success – some of my co-workers embraced TDD while other "just didn’t get it”.
At first I become frustrated and I’ve tried explaining more and more about it without any real success. When I asked several of my teammates why they fail to even try writing tests before code the answer usually was – “I would but I don’t have enough time for it right now” or “it’s a good idea but it won’t work with this feature”.
One day it hit me – why not get the team to do TDD in a natural environment where they can try it without fear of missing a deadline or writing bad code. And so I gathered the team together in one room for an hour and a half of “TDD training”.
For the exercise I’ve chosen a problem that is simple to solve in small iterative steps (TDD) but very hard to design up front.
The exercise I've used was a roman numeral to decimal convertor. it is a well known problem that luckily for me none of my team had the pleasure of solving in the past.
The slides from this session are available here.
After a short introduction of the problem and a few slides on the subject of TDD I got the team to pair up and try and solve that problem.
It was a fun exercise and some of my co-workers got to try test first for the first time.
I loved the fact The pair that finished first really embraced the methodology. The cool thing is that one member of that pair refused to try TDD for the last year.
We had so much fun that we’ve decided as a team to have this kind of meeting every three weeks.
Happy coding…Labels: Agile, TDD
