Test Driven Development is one of the most effective practices from the agile community of practices, and also one of the least practiced regularly. Why is that? Why, 15 years after it’s introduction to the world via Kent Beck’s eXtreme Programming Explained, is one of the least adopted practices in the community?
Test Driven Development is One of the Most Effective, Yet Least Adopted Practices in the Agile Community
After years of practicing it and teaching it to others I have a few ideas on the subject.
First of all, Test Driven Development takes time to master. It is conceptually simple, however, practicing test driven development on existing code, not written for tests tends to be very difficult. And for some reason, even though there are some really great, and simple, techniques out there for working with legacy code (most prominently Michael Feathers’ book by the same title), people tend to be unaware or unpracticed with the well-known and well-documented techniques. This means there is a skill-gap in using test driven development for existing, untested, code bases.
Most Developers are Unaware or Unpracticed at TDD Techniques for Code Not Written With Testing In Mind (Legacy Code)
Then there is the problem of the current way TDD is taught in the community. We, the coaching community usually teach TDD on toy applications built for a classroom situation. And students leave the classroom having learned the basic skills of TDD on greenfield applications and unable to apply them in their daily lives with aging code and tight deadlines. The techniques of working with existing code are usually considered advanced and not broached until teams become practiced with the basics of TDD. Unfortunately most teams don’t become practiced in TDD because they cannot apply what they’ve learned in class to most of their regular work. Finally, although there are a few workshops out there where coaches teach TDD on their clients’ live code, they are by far and large the minority.
Most Students Leave TDD Training With The Ability to Practice TDD on Greenfield Applications Yet Their Day-To-Day Work Is On Legacy Code
For those lucky few, that learn TDD in a class, have follow-up coaching afterwards as they begin to master TDD in the few cases where it is possible, and advance enough to learn how to work with legacy code effectively there is one last hurdle. You need to make TDD a daily habit. And making TDD a daily habit is easier said than done. Even well practiced developers, who have been doing this for years, spend roughly 40% of their time writing tests and 60% of their time writing production code. For those new to TDD, if they want to create such a habit, they will need to spend the majority of their time writing tests, not production code, to make things stick. Add to that the existing deadlines. Add to that managers that might become worried as velocity drops. And, add to that, our own critics in our head that start to get worried that we are spending much of our time writing tests. To make TDD a habit, given such a large step size, we need an immense amount of personal and team motivation to make it part of our day to day lives.
Making TDD a Habit Requires Sustained High Levels of Motivation
Finally, if you learn TDD, get coaching to apply it to your existing code, are excited enough to sustain the levels of motivation needed to make it a habit, you have one final hurdle. You are dependent on the rest of the team. TDD is a brittle practice. That is, we all need to be practicing TDD on the team to succeed. If I write a test, and someone else breaks that test and does not fix it, then the TDD habit isn’t going to last. Also, if I am the only one writing tests on the codebase, and my colleagues aren’t, we won’t ever reap one of the great benefits of TDD – a safety-net of tests that enables us to refactor regularly and changes the cost of change curve for our project so that is affordable to make changes late in the game.
TDD Is Fragile – Success Relies On the Whole Team Practicing
With all this stacked against us: a big learning curve, ineffective training techniques, a need for sustained levels of high motivation, and fragility, it is no wonder most of us in the Agile community do not practice TDD. We need a new approach to learning and practicing this most valuable of skills.
We Need a New Approach to Learning TDD
I’m not writing this blog as a lament; I’ve been working on parts of the puzzle for a few years and the last piece is now sliding in place:
Training: TDD is a difficult skill. Teaching it effectively even more so. We need to reconsider how we train TDD. The current method has proven ineffective. We need to either go back to the old XP immersion classes which jam-packed a team into a shared workspace for 2-weeks of intense work, or we need to start teaching legacy code techniques at first encounter – preferably on live code – so students can transition to daily work after class.
Teach Legacy Code Techniques In Introductory TDD Classes
Building habits: the latest research on making practices into habits gives us new ways to be more effective in transforming the way we work. One very effective technique is to take ridiculously small steps to reduce the levels of motivation needed and build the habit first. Once the habit is there, then we can layer-on sophistication and complexity. Specifically to TDD, we need to find the smallest possible step – an MVP of TDD training – that we use to build our habit first.
Design and Use an MVP of TDD Training
TDD fragility: Because TDD needs the whole team to work together effectively, we need to create a culture that encourages individuals on a team to write tests regularly. The work I’ve been doing with Steve Peha on agreements-based culture is an effective way to make that a reality.
Leverage Agreement Based Culture Techniques To Get Full Team Participation
By putting those four techniques together we can, as a community, start benefitting from our most effective technical practice.
Amr Elssamadisy's Blog 