#07-TDD Will Increase Development Velocity

This tip is one of four that elucidate the benefits of TDD, so that those whose approval is needed for adopting this way of working will understand why it should be done.  This week, the issue is increasing team velocity.

Transcript

TDD Will Increase Development Velocity

Often when it is suggested that the developers should adopt Test-Driven Development as their way of work, a number of objections will arise from those who control the project and are responsible for its success.

One of them is that TDD will slow down progress.  It makes sense to think this: after all, the developers are being given a new task, namely writing tests, that they were not doing before.  It might be a very valuable thing to do but it will cost developer-hours to accomplish it.  Maybe we cannot afford that.  You may well have to speak to this objection if you hope to adopt TDD.

The truth is that adopting TDD will slow you down initially because at first will be an unfamiliar activity to the team.  Anything new tends to take time to bring to maturity but that's not unique to TDD.  Once the developers get comfortable doing it TDD will actually increase team velocity against requirements.  How can this be?  It seems counter-intuitive.  Here's why:

1. We gain improved confidence. Developers who become adept at TDD become much more confident in their work, and thus will work faster. This is because of the constant confirmation they receive.  When they write a test and run it, watching it fail, this confirms that the test is legitimate.  Once they make it pass they know the behavior of the system is correct.  When refactoring or debugging the tests constantly confirm that current work has not broken previous work, or the work of others.  Confidence is rare coin in systems development and once they feel it developers will become much more aggressive about delivering value.

2. It's not really new work. Developers know they cannot simply sit down and start writing code once they have a requirement.  They must first analyze that requirement to make sure they understand it correctly and fully, asking questions if need be, and then documenting the knowledge that results.  In TDD this analysis process is conducted by writing tests.  So writing tests is old work done in a new, better way. Better because the tests (unlike a traditional document) are written with technical precision, which reduces the chance of misinterpretation, miscommunication, and missing details.  There are other benefits to this form of specification, but I’ll save them for the next agile tip.

3. We avoid doing unnecessary/duplicated work.  Often a developer will create code that does something already done by the framework, eco-system, or other components/libraries that they are working with.  They do this because they did not realize the behavior already existed, or they were unsure and so they created it "just in case."  This code is wasteful but also represents a duplication with other code and this creates the risk of the two getting out of sync with each other over time. This can produce bugs that are extremely hard and time-consuming to find.  When tests are written first and they pass unexpectedly, TDD mandates that the cause of this must immediately be determined.  If it turns out that the developer was about to create duplicated behavior then this is completely avoided.

TDD increases team velocity.  It's one of the many benefits that will be accrued upon its successful adoption, but this must be made clear to those who hold the reins of decision-making in an organization.