The Benefits of Test Driven Development (TDD) for Non-Engineering Managers and CTOs
Most conversations about Test Driven Development (TDD) on Linkedin are between software engineers arguing the pros and cons of this approach. There are implications for non-engineering managers and CTOs but there is little information online aimed at providing the benefits of these approaches for non-engineers in leadership positions.
I'm a fan of this approach, I've seen complex, expensive problems solved by teams working with TDD. However, when speaking to CTOs it often feels like they need convincing that they should be looking at this way of working for their teams.
A quick definition of Test Driven Development:
What are some of the benefits of teams using TDD for CTOs and non-engineering managers:
Driven by design
Small, incremental changes that are intentional. The practice of writing a test first means that the engineers are actively thinking about the design of the product. This approach means that complex systems are built in a controlled manner, step by step, with each change being tested against the desired outcome and impact on the overall system.
Limiting the impact of change
By forcing themselves to work in smaller steps the engineers are limiting the impact of any change. Changes that have unintended outcomes can be much more easily fixed by either rolling back the change or in a perfect world a small fix that can be rolled forward with limited or no down time to the overall system.
Recommended by LinkedIn
Faster feedback
As a non-engineer I value the consistent and frequent information I get from engineers working in this way. They are effectively working in a set of small feedback loops so there are constant signals about how well the code is meeting the needs we have defined and in terms of quality and performance. Once you have worked in this way it is hard to go back to a signal-less approach.
Higher quality
TDD leads to higher quality. Quality is a broad topic but I don't just mean the code quality is higher due to the existence of tests but the software design quality is higher because of the intentional approach and the product quality is higher due to the short feedback loops.
Lower cost of change
Small, incremental steps that are well tested increases the safety of each change made. This effectively lowers the cost of any change we want to make to our plans. If we find that our initial assumptions are wrong through user feedback we are not tied to as much sunk cost. This means we are free to make better decisions based on data.
These are just some of the benefits I have seen as a non-engineering manager working with teams who practice TDD. Knowing that the team are producing high quality code, in small feedback loops that provide me with the constant signals I need to make decisions and lowering the cost of any necessary changes are huge benefits.
It's not easy, and requires a high level of engineering skill to be able to work in this way. However, the benefits of this approach are high enough that I consider them to outweigh any cost.
Photo by Lili Popper on Unsplash
