January 13, 2009

...Learn TDD with Codemanship

Long-term Peer-led Learning - Getting Into Good Habits

Adopting test-driven development hurts. At first, at least.

Those first few tests you write seem to take hours, and the simplest of logic suddenly seems laboured and causes major brain-ache.

There are all those habits you're supposed to get into: you keep having to be reminded to do things like running the test to see it fail before you write the code to pass test, or to remember not to refactor when you've got failing tests.

If you weren't pairing with someone who keeps prodding you on all these things, you'd almost certainly forget to do them a lot of the time. And this is probably the first time you've paired like this before. That can hurt a little, too. Your clumsy butter-fingers crash, bang and whallop the keyboard, spitting out typos and nonsense that you have to keep correcting, and there are all those embarassing hold-ups and pregnant pauses while you try to remember the right class name or find the required menu item while your navigator looks on impatiently and disapprovingly.

Like many skills that are worth having, the vast majority of us really suck at TDD when we start out. It feels uncomfortable, it takes ages, and the results are far from spectacular. In that sense, it's a bit like learning a musical instument. You sweat blood in those first few lessons just to play a slow and very shaky rendition of Three Blind Mice. Which is why most people who start to learn give up after just a couple of lessons. It's just so hard.

But stick with it, and the pain and the embarassment start to lessen, and your start to gain confidence and find that things you really struggled with at the beginning become comfortable and intuitive.

Give it a few months and you will find that TDD can become second nature (well, almost). Break through the initial pain and you'll very probably never look back. I don't know anyone who stuck with TDD who would consider working any other way now.

Which is why I've adapted my coaching style and approach to focus on giving TDD a proper go - long enough to work through the initial pain and reach a point where the basic practices fit like an old glove. These days, my focus is not on teaching developers all about what TDD is - there are plenty of books and courses that do that very well, and who the heck am I to tell them? Now I focus on giving developers plenty of practice over an extended period of time (3-6 hours a week over 3-4 months for basic TDD) where they are encouraged to do it by the book, shutting all other concerns (like deadlines, for example). As time goes on, they will be encouraged to spend more and more time each week "doing it by the book" until eventually they find that "TDD by the book" is now how they instinctively program most of the time.

During this period, developers pair with each other and effectively police the practices and habits they - as a group - have agreed constitute TDD "done properly". So if we all agreed that it's good to write the test assertion first, then in pairing sessions, developers will watch each other to ensure that they do indeed write the assertion first. After 30-50 hours of that, they will probably find that they start to just do it without thinking. It's the beginnings of a habit, which - with hundreds more hours being reinforced in their day-to-day work - will eventually become second nature.

Posted 12 years, 4 months ago on January 13, 2009