Wayne Seymour emailed me the other day and asked:
“I find it difficult to ‘sell’ junior developers on test driven development; however, I do find it easy to relate design patterns to them. Have you any advice on what techniques you’ve found useful for getting the idea of software craftsmanship across to junior developers?”
I found myself composing an involved response to Wayne’s question, as it pertains to several of Atomic’s core values, and we’ve had a lot of success overcoming this challenge.
Software craftsmanship as an idea is not something we attempt to sell a newcomer on up-front. Being a craftsman means loving your craft, bettering it (and yourself), and building the right software for your customers. It means taking on the responsibilities of a professional and respecting yourself and your peers enough to “do it right“… which involves a huge amount of figuring out what “right” is. It’s something you grow into over time.
TDD is one of the core tools of a software craftsman, to be sure. But I don’t need to convince you that craftsmanship is a worthy goal before I teach you how to write good tests before code.
Like Wayne, I find “selling” TDD to be problematic. The combination of unfamiliarity with the concepts, lack of experience of its benefits, and the initial outright difficulty of TDD practices (when tackled alone) can be so daunting that it’s easy to disregard the whole approach and go back to doing whatever you were doing before.
Let’s say you’ve come to Atomic as an apprentice, and I am your mentor. I’ll bring you into my project team and pair with you from day one, and we’ll start by employing TDD at the unit and system level to drive the construction of our code. I don’t expect that you know anything about iterative development, TDD, or feature breakdown and estimation… yet. I DO expect you to pay close attention, participate in the testing and coding process, ask “Why” a lot, and point out my typing and design mistakes as you notice them. (I’ll be doing the same for you.) My answer to “Why” will never be “Because we’ve always done it this way“… there are tons of good reasons and I won’t hesitate to try to explain them in context. Eventually, I expect “Why” to transition gradually into “How.”
You’ll find immediate value in TDD. If you’ve ever had your project go from simple, clean and functional to complex, messy and unreliable, you’re going to rejoice in the continued stability of your code that TDD provides. (I’ve found this to be true especially in personal side projects, which are not funded or staffed.) The trick is in getting over the hump of disbelief and technical fear.
The key here is the togetherness and safety that pairing provides in this early learning environment. It’s far easier to believe that TDD is a good choice when I’m sitting by your side, encouraging you, navigating the tangle of strange concepts and tools, and producing effective results. Over and over again. You have to work hard and keep up, but I won’t leave you behind to fend for yourself.
As a mentor, I must commit time and energy to your training, and I must believe that you’ll hear my words and learn from my actions (uh, and a few mistakes). But it’s not hard for me to believe you’ll do well, after watching so many others succeed, so I’ll summon the patience to see it through. (I’ve come to realize that patience can take many forms. For example, my technique involves appearing angry, pushy and loud, but it’s really a caring, nurturing patience. Honestly.)
Ok, now let’s say you’re a senior developer in a budding software culture, hopefully in a place where you’re at liberty to commit to your juniors and invest in their early development. In this case, pair with them constantly and show them how its done. Once they experience the value of TDD and iterative development, they’ll fight to keep it for themselves.
If you’re in an environment where TDD or pair programming are not encouraged, where your juniors are free to disengage from you and go work on their own in the closet, you are probably screwed. (You might think about Working at Atomic Object)
My parting comment for the would-be mentor is: the learning/teaching process can feel difficult and stressful (especially when you’re on a budget and the clock is ticking)… but this approach can lead to better products, better teams, and yes, you’ll still be able to hit your deadlines. Internalizing a process of intensive teaching and learning is a very effective means to keep this job fun and productive for a very long time.
(And for those who need to brush up on their testing and TDD knowledge:)
- Testing articles and papers at Atomic Object
- When is it ok to not TDD?
- Wikipedia entry on TDD
- Kent Beck’s TDD By Example
