Most of the really big successes and game-changers I’ve seen in my career have been initiated through individuals seeing a problem and fixing it themselves rather than waiting for others.
If you need something done that isn’t already happening, nobody else is going do it for you.
Here’s 4 lessons learned from adopting TDD…
It takes time & effort to get TDD into place
You will have to sacrifice “new code” time in the short term. From my experience, time is probably the biggest barrier to successfully introducing TDD on most teams (closely followed by motivation & accountability). Seeing the pay-off on the other side is notoriously hard to when you’re not there – either starting out or sitting at the bottom of the change curve.
If you’re coaching teams, sometimes you might just need to say “Trust me, I know what I’m doing”
“It can’t be unit-tested”
When you or someone else makes this statement they probably mean one or more of the following:
“I don’t believe I have the time to make this testable”
“Nobody has provided the infrastructure/harness/test data for me”
“I don’t know how to unit test this” (and need some help to figure it out)
“We have some architectural impediment to resolve in order to achieve this”
From these statements, which do you think is least common?
Break this cycle by encouraging accountability for making code testable.
This doesn’t just mean the product code it includes taking ownership of your testing tools and abilities as well.
If you’re struggling…
There’s 2 options for you; “abdicate” or “own”
Option 1 – Abdicate responsibility.
- You’ll set the tone for your whole team. The next time someone hits the same problem, the cycle will repeat.
- At best, someone better than you may eventually address the issue. (And I hope they make you feel mediocre or inferior).
- At worst you may find them saying that you didn’t provide the solution for them.
The “best” case is highly unlikely to happen during your current project – maybe even the one after. Just think how much testing debt can build up over the life of a single project. We should be avoiding that, right?
Someone has to break the cycle. If you’re facing pain, why aren’t you responsible for fixing it?
Option 2 – Take ownership of the problem yourself
Great! You’ve recognized that your accountability is part of the problem.
Nobody else will do this stuff for you!
- Establish a Personal strategy for implementing TDD – how are YOU going to solve the problem?
- The teams and individuals I’ve seen that are successful with TDD have all got there by taking a personal responsibility to do so.
Just Do It
Here’s some suggested steps to get going – you can either do the first few alone or as part of a team.
(If there’s an accountability gap in your group you’ll probably need to start alone)
1. Get a unit test harness and environment in place – there’s plenty online but write one yourself for starters if you have to!
2. If you have a database, break that dependency and channel it through something replaceable.
3. Write your first round of tests and see what hurts – now resolve those pains.
Limit the time spent on this first cycle and determine whether you should ask for time in advance or for forgiveness later – it’ll depend on your local context.
4. Educate & support your team on what you’ve provided so far.
5. Get other team members to write their own round of unit tests (treat it “as an experiment” if there’s concerns over the effort required). See what hurts and resolve those pains.
6. Encourage and develop shared long-term ownership of the test harness, test data, stubs and mocks (if used).
Remember you’re setting the tone. If someone needs something that isn’t available, pair up, help them provide it and share the results with the team. Don’t leave them alone but don’t do it for them either.
7. Repeat round 2 during development until writing tests is fast, easy and natural. (Don’t give up too soon – this is hard work and takes time!)
8. Capture any “wins” and “losses” during this cycle – what benefits are you seeing and what new pains are coming through?
9. Review the wins & losses. Decide what to do about the losses and how to promote the wins up the management chain and across the team. For example either publicise as you go or use as fuel for your retrospectives.
Think about the positive impact that little bit of extra effort and ownership has on you and your team in leading by example – doing a great job that others will want to share, not just a good job.
Abdication or accountability is a personal choice but it affects everyone around you. What are you doing to help your team?