Test-Driven Development and the Discipline of Juggling

People who know me know that I like analogies. I have many to describe Test-Driven Development (TDD) and how I use it, one of which is relating it to juggling. Here’s how I explain it:

To me, writing code can be a lot like juggling. I write a method that is 15 lines of code. I consider this method to be the equivalent of one ball. Almost all people can juggle one ball with two hands — it’s essentially handing it back and forth.

Next I write Method2, another 15 lines of code, that interacts with Method1. Slightly more complexity but still straightforward. In my head, I can keep track of those 30 lines of code and how they interact. It’s now the equivalent of juggling two balls. I can keep an eye on both balls, two hands, just a simple toss to switch them. Harder than one, but still doable.

test driven development jugglingI add in Method3 (another 15 lines) that is called by Method1 and Method2. Changes that I make in Method3 must not break anything in Method1 and Method2. Also, changes that I make in Method1 and Method2 can’t break what’s done in Method3. Lots more complexity and code to keep track of in my head. A lot like adding a third ball to juggling. Now I have to keep one ball in the air at all times, transfer another ball, and throw the third. I do know how to juggle — just like programming, doable. I almost never drop a ball… or introduce a bug.

Here’s where my juggling skills max out, though. When I try to add a fourth ball, I can’t juggle for long without dropping some balls. Not only do I now have two balls in the air, but I have to change my juggling technique. Similarly, when writing code you could add Method4 or even a new Class that calls or inherits from the original Class. A lot more complexity happens then. More things to keep track of and, as we all know, everyone has a limit to how many balls they can juggle at once.

Now let me explain how TDD works to help me juggle many balls. Even before I write Method1, I start writing tests to drive my functionality. Those tests are the equivalent of the ball being smart enough to juggle itself and knowing where it needs to go automatically. It never falls because my tests are ensuring that it “juggles” correctly. With tests supporting all the balls, an infinite number of balls can be juggled with no problem.

Because my methods are supported by tests, I know that not only that I did not break the functionality of the method that has my full attention and that I am actively modifying/writing — I no longer have to keep track of the litany of other functionality that I might impact in other methods and classes. The other methods have their own tests and can take care of themselves. It’s liberating not have to worry and try to remember everything about the entire codebase. I can focus on the important parts — the parts that I’m directly working on — and how to improve them.

Some people like analogies and some don’t. Not every analogy is perfect, either. I like this one and it generally holds true. With TDD, I don’t need to focus on keeping all the balls in the air, making quick transfers, and catching. TDD enables me to focus on juggling one ball at a time. All the other balls will know how to juggle themselves and let me know if something goes wrong.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.