When managers find out that I teach test-driven development to software development teams, they sometimes ask me how they can introduce TDD to their team. Unfortunately, it’s not always easy.
We software developers are jaded. And for good reason. It seems like nearly every day we are hit with new technologies or methodologies that are going to save the industry and make our lives so much better. Most of these don’t pan out. The things that we discovered that do work for us are valuable and we’re not about to abandon them for something untested.
I find that we can discuss all the benefits and reasoning behind doing test-driven development and we can all agree intellectually that it’s valuable but still not be willing to implement it on our team. The only way that I’ve seen teams adopted test-driven development is if they experience the benefits of it for themselves, preferably together.
But learning TDD and experiencing its benefits requires the right kind of environment. Doing TDD with existing code when there’s already a lot of technical debt adds another level of complexity. It’s always better to start by learning TDD on a greenfield project. Doing TDD can be very effective with existing legacy software but it requires advanced techniques and it’s always better to start with a clean code base.
It always seems that new Scrum teams form and immediately want to hit the ground running so they don’t take much time to think about technical practices or development standards. Learning new skills like TDD get put off until later. But when later comes we already have so much legacy code that is quite difficult to dig ourselves out of the technical debt we’ve accumulated.
I’ve seen this vicious cycle play out time and time again on Scrum teams and, of course, the solution to this challenge is to be prepared. Give teams the skills and the baseline knowledge for the kind of development that you want to have happen in your organization. If technical excellence is important to your organization then there should be some sort of consensus and common understanding of what that means and how that gets incorporated into the software being built.
I see TDD is a core software development practice and many teams are discovering how important it is in order to correctly implement continuous integration and become truly Agile. Test-driven development is perhaps the most advanced practice of Extreme Programming. It’s easy to do it in a less than optimal way and there aren’t many good sources to learn how to do it well.
The best book I found on the subject of TDD is the first book that was written on it by Kent Beck, called Test-Driven Development by Example. It’s an excellent book but no book can cover all of TDD and how to do it properly. We need a dozen excellent books on the subject.
I try to share as much as I can about what I’ve learned that works for me in TDD on my blog but it’s hard to communicate an entire body of knowledge in a series of blog posts. We can go much deeper with three to five days of doing TDD in my developer classes.
One way to learn TDD is by mobbing where the whole team gets together and works on the same story using new techniques or approaches like test-driven development. Mobbing and pair programming are some of the most powerful ways that I know to propagate new practices throughout a team. Training and attending conferences can also help.
{2 Comments }
Previous Post: « Code Coverage
Next Post: Introducing TDD to Managers »
David,
I always appreciate your thoughts about software quality and how to communicate with folks in the tech community.
Cheers, Ian
Thank you, Ian! I’m looking forward to sharing more about AI and software development in the coming years!