This is another way of looking at how Test Driven Development (TDD) helps us build better software.

Before becoming a developer, I was an academic at University College London. We built the world’s first homodyne and heterodyne phase locked loop with semiconductor lasers for oscillators instead of electronic oscillators. Sounds easy, right? But the problem is that because lasers oscillate at high frequencies (it’s light after all), a delay of a few hundred picoseconds around the feedback loop is significant and results in the system becoming unstable.

Indeed, any system with feedback can become unstable if the delay around the loop is significant. There are things that one can do to prevent instability but the best thing to do is remove the delay if possible.

In software, there are many feedback loops. When you write code, often the first feedback you get is whether it compiles or not. Can you imagine the pain if that wasn’t the case? Waiting a few weeks to find out whether the code actually compiled would be ridiculous. Right?

Fortunately, most software developers have a go at making sure their software actually compiles. Some don’t, but thats a different article.

Testing is another feedback mechanism. So how is it sane to wait months before finding out that your code actually works? It isn’t, thats crazy talk. TDD helps in a number of ways: it helps you to think about what your code will do before you think about how it will do it; it provides a safety-net for all those refactorings you will need to do; and it tells you that the code you thought you wrote is what you actually wrote.

The instant feedback obtained by TDD is a stabilising mechanism to ensure that what is written is correct and that you haven’t broken anything else inadvertently because all that other code in the system is also tested.

But what is meant by stability in this context?

The main instability is the code – wait – test – fix – repeat cycle. During the wait and test phases, new code is being built on top of the broken code, and the fixes themselves often introduce new defects. This results in increasingly painful fix phases. What is worse is that there may be many overlapping loops like this which is utterly chaotic!

This chaotic process results in developers working in a panicked, crisis mode which leaves no time for refactoring, reflection about improving the codebase, or writing tests. It’s very demoralising as the deterioration in the codebase cannot be stopped.

The end result is a brittle, sprawling mess of a system that is now not in any state to be tested or repaired without heroic effort from the developers, and buy in from business stakeholders. And we know how that story ends…