If you’ve never done Test Driven Development or aren’t even sure what this "crazy TDD stuff” is all about than this is the series for you. Over the next 30 days this series of posts take you from “I can spell TDD” to being able to consider yourself a “functional” TDD developer. Of course TDD is a very deep topic and truly mastering it will take quite a bit of time, but the rewards are well worth it. Along the way I’ll be showing you how tools like JustCode and JustMock can help you in your practice of TDD.
Previous Posts in this Series: 30 Days of TDD – Day 28 – Reader Question #4
Brent Eritou asks
How do I best communicate the benefits of TDD to my non-technical manager?
Thanks for the question Brent.
Non-technical managers sometimes have trouble understanding the importance of the benefits of TDD. This is because most managers have two main priorities when dealing with a software development project:
It’s unlikely that we will ever get the non-technical folks to really understand the the benefits of TDD from our point of view, so we have to speak to theirs. That means we have to frame our discussion about TDD with them in terms of time and money.
Managers in charge of projects are tasked with making sure that the software their team is developing is done on time. Regardless of how arbitrary a deadline may seem to the developers, every project has a due date and the manager is the one who has to answer if it is not met. While there is a learning curve for TDD, overall software developed using TDD reached release faster.
Consider this chart (figure 1), which is derived from data in this report:
Figure 1 – TDD vs. Non-TDD
The data in this chart pertains to four projects; an IBM drivers project, Microsoft Windows, Microsoft MSN and Microsoft Visual Studio. For this study two teams from each project were studied; one practiced TDD and the other did not. The blue columns reflect how much time the teams practicing TDD took to develop a feature in relation to the team that was not using TDD. As you can see, each feature did take longer to develop. In the case of Microsoft Windows the features took 35% more, which is not insignificant.
But those numbers only tell half the story. The orange columns represent the number of defects the teams practicing TDD had in relation to the teams that did not practice TDD. As you can see, the teams that used TDD had significantly fewer defects. In the case of Visual Studio, the teams that practiced TDD had 91% fewer defects than the non-TDD team! The net effect is that in spite of a learning curve that caused features to be developed slower, the time saved from not having to fix as many defects during development created a net effect where the feature was actually delivered faster by the team practicing TDD.
All software has defects and all defects cost money to fix. But the cost of fixing a defect is greatly affected by when the defect is discovered. Figure 2 demonstrates the relative cost of fixing a defect based on when it is discovered:
Figure 2 – Relative cost of fixing a defect
The earlier a defect is found the less expensive it is to repair. To keep the math simple, let’s say that the base cost to fix a defect is $100. When a defect is found during the Requirements phase it costs a very manageable $100 to fix. If the defect is found in Construction phase it costs $500, which not a good as $100 is still manageable. In System Test the same defect now costs $1,000. This starts to become a little harder to accept, especially if you are working on a smaller project that has a budget of under $100,000. If the defect is found after the application is release that amount balloons up to $10,000. That number represents money paid to testers, developers, designers, business analysts and whoever is designated to be in charge of deployment. That number does not take into account intangibles like lost sales, angry customers, employee morale, violated SLAs and any fallout from potential security failures.
When practicing TDD you are able to confine most of the defects to the first three phases of software development. Coupled with fewer defects this factor has a lot of positive effect on the budget of your project; there are fewer defects and they are less expensive to fix.
Non-technical managers may never understand the technical reasons why TDD should be practiced. But they will understand time and money. By demonstrating that TDD will help them save both, it shouldn’t be difficult to at least get your managers interested in TDD.
Hope this helps.
Conclude the TDD journey: