Ten tips to maximize the return on your TDD investment

Paul Cowen presented an interesting personal observation of using TDD on the ALT.NET mailing list, under the title “TDD + effort != return“.  The implication being that doing TDD requires extra work during development, extra work in training, extra work in hiring qualified people, even extra coding.  TDD is an investment in your team, your product and your craft.  But there are a few things you can do to get the most out of your TDD experience.  Here are ten tips to maximize your TDD investment:

1. Invest in a professional refactoring tool.  ReSharper is my current favorite, though I’ve been fond of Refactor! Pro in the past.  Visual Studio, out of the box, has some fairly paltry (and slow) refactoring support.  A professional refactoring tool will pay for itself (depending on your rates/salary) very quickly.  A good craftsman needs sharp tools to build quality products.
2. Invest in your design skills.  Go out and buy design books, read them, share them with your team.  Robert C. Martin’s Agile Principles, Patterns and Practices is a great start.  I haven’t read it, but Head First Design Patterns gets rave reviews.  The Pragmatic Programmer and Domain-Driven Design are two more must-reads.  TDD is meant to supplement and guide good design, not to be a magical spout from which good designs spew.  You have to know where you want to go for the destination to make sense.
3. Hire passion and talent, not acronyms.  If you want to have a good team that designs good software, they have to be passionate about the craft, and talent to achieve success.  An alphabet soup of tools in a resume is not nearly as important as the drive to learn.  Someone with passion, talent and an open mind can be taught TDD and design.  Someone in love with stored procedures because they like SQL cannot.
4. Invest in your team’s success.  Conduct book clubs, hold brown bag sessions, sponsor training, encourage learning.  A team member doing TDD simply because the tech lead told them to isn’t going to have much passion for it.  A team regularly conducting introspective analysis and searching for ways to improve will see the full benefits of TDD beyond the unit tests that result.
5. Consider enlisting a coach.  Tiger Woods has a swing coach.  If the best golfer in the world thinks it’s appropriate to hire someone to help with his swing, why would it not be appropriate to hire an experienced guide to ease the transition into TDD?  A coach is a person who’s already made the mistakes and learned from them, and can effectively pass on this knowledge to others.  While it might take months of failures before TDD starts to make sense and your team realizes the full benefits, a coach can set your team on the right path to begin with, as well as answer questions that might have led you down blind alleys and wrong turns.
6. Get everyone on board.  Quality needs to be important to your team, as should be good design.  Accepting less is a team decision, but that decision needs to keep in mind the cost of technical debt.  One person can subvert an entire team’s intention to start TDD, and it’s up to the team leader to ensure that everyone moves together.  If a team member refuses to cooperate, then it may be time to escalate the issue to HR.  A team’s success is more important than one team member’s ego.
7. Invest in your refactoring skills.  Find any and all refactoring books, and devour them.  From Fowler’s Refactoring to Kerievsky’s Refactoring to Patterns to Meszaros’ xUnit Test Patterns, you’ll need to understand how, when and why to change your code.  Refactoring is essential to good design, as you never design right the first time.  These books describe code smells and how to get from design A to design B, safely.
8. Always do the simplest thing that could possibly work.  Because you’ve invested in your design and refactoring skills, you don’t have to create the strategy or template method pattern every place you possibly could.  It becomes easy to move towards and away from patterns with Kerievsky’s book.  With refactoring techniques, applying design patterns before they’re actually needed becomes rather pointless and wasteful.
9. Avoid the cargo cult.  If test doubles seem foreign and pointless, do the research on the why.  Perform a little analysis before jumping in or dismissing a tool or technique.  There are gabs of resources on TDD, design and refactoring in books, blogs, articles and presentations.  Applying a new technique like TDD without understanding the “why” can be a short path to a bad experience.
10. Expect to fall down.  TDD is a skill, and like any other skill, requires patience, dedication, study and practice to master.  Expect to fall down, flat on your face as you learn.  Everything isn’t wine and roses once you start TDD, and you’ll need to have convinced yourself that the benefits will be worth the initial pain.  A coach will ease the initial pain, but TDD and design in general is a learning process.

This list isn’t exhaustive naturally, but I wish I had this list when I started doing TDD almost three years ago.  TDD is hard, as is good design.  The first time I threw a baseball, I was pretty bad at it.  With practice, I improved.  With guided and informed practice, I improved much more.

Skills aren’t static either, you’re either getting better or you’re getting worse.  These tips have helped me improve gradually and incrementally over time, but only because I wanted to.  I’m still not satisfied with where my skills are, and I never will be.  There are always inefficiencies to address, areas to improve, and new techniques to learn and employ.

TDD is a technique I believe whole-heartedly in, not because it’s vogue or the echo chamber is loud, but because I’ve seen the improvements in maintainability and design as a result.