Pivot Matthew Parker elaborates on the benefits of practicing test-driven development, and also why you shouldn’t be afraid of refactoring.
Consider these two graphs of team speed over time, and ask yourself which team you want to be on:
At Pivotal, many of our customers come to us saying that they have teams that look like the first curve on the left. They went really fast at first — but it didn’t last. Their speed dropped precipitously, until reaching a depressing asymptote. That asymptote kills teams. It kills their spirit.
Teams that practice Extreme Programming (XP) believe that the best software is built through a process of learning, which requires them to continuously deliver software into the hands of users, get their feedback, and iterate on the product in response to that. You can’t do that if you’re on that first curve. You need the second curve. You need to GO FAST FOREVER.
There’s lots of reasons a team slows down. But there’s one thing that will always slow a team down: bad code.
A team that looks like the first curve cut corners (e.g., they didn’t clean their code, they created lots of defects, etc.). You can go really fast if you cut all the corners — but only for a little while. It’s false expedience. What made it easy to go super fast in the short term makes it impossible to go fast in the long term. The codebase very quickly resembles a ball of mud. And eventually, it reaches the point of no return, and those engineers will have no choice but to start over and try again.
If you want to GO FAST FOREVER, you have to have CLEAN CODE. But you don’t just clean code once. Cleaning your code is like taking a bath. You have to bathe regularly if you want to stay clean. The longer you wait, the worse you get. It’s the same with code.
So, to keep your code clean, you have to constantly REFACTOR it. Every new feature you add to your codebase challenges the assumptions behind the code’s design. Here’s where you have two options: you can either find a way to workaround the invalidated design in your code, or you can take the time right then to fix it — to refactor it. The former leads to that rollercoaster first curve, which ends with a death spiral. Refactoring leads to the second curve — consistent speed — by holding the behavior of the system constant while cleaning up the underlying design.
But most teams don’t refactor — because they’re afraid. They know the code is rotting, but they’re not sure if everything will still work after they clean it up. To continuously refactor your code, you have to have CONFIDENCE that the refactoring has still resulted in working software, that you haven’t introduced regressions.
Unfortunately, there’s no magic wand you can wave to prove that your system still works. You have to do the work yourself. If that work is too hard, or takes too long, you’re unlikely to do it. That’s why manual QA teams don’t work. It takes too long for the engineers to know if the changes they made resulted in working software. The only way to get that confidence quickly is to write tests. TESTS give you the CONFIDENCE you need to REFACTOR your code to keep it CLEAN so that you can GO FAST FOREVER.
So the question becomes: When do you do it? When do you write tests? And the answer is obvious. Everything depends on tests. They’re the most important thing. So when do you do the most important thing? Obviously, you do that first. That’s why we TDD.
There are, of course, many more reasons why we write tests before — instead of after — we write the production code. Writing a test first helps us tease out and think through our APIs. It forces us to clarify exactly what behavior we’re trying to build, since we can’t write a test without that clarity — and it also lets us know when we’re done. It helps us triangulate on simple, maintainable implementations, by making each test pass one by one and writing just enough code to make each test pass. Furthermore, writing the test before the implementation gives us the confidence that our test suites aren’t giving us false positives; we first watch the test fail for the reason we expect, and then do the simplest thing we can to make it pass.
You can watch more about how Pivotal approaches TDD in this video:
Interested in working at a place that uses TDD to write quality code? Check out the jobs available at Pivotal.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
Why TDD was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
