Every few months someone (I prefer not to say who ) tells me the same thing. “We do not have time for TDD. We need to ship fast.” I always answer with a question. Fast compared to what? Because in my experience building and shipping software, the slowest weeks of my life were never the weeks I spent writing tests. They were the weeks I spent chasing bugs that tests would have caught.
Let me make the case the way I would make it to a manager, not to a developer. With costs.
What TDD actually is
Quick summary for anyone new. Test driven development means you write a small failing test first, then write the simplest code that makes it pass, then clean up. Red, green, refactor, repeat. Kent Beck described the whole discipline in his book Test Driven Development by Example, back in 2002. Twenty years ago this year, and the book is still the best place to start. Beck still writes about design and testing today at kentbeck.com and his thinking keeps being practical, not religious.
Notice what TDD is not. It is not a testing technique, really. It is a design and risk management technique that produces tests as a side effect. The test you write first forces you to decide what the code should do before you write it. That alone kills a whole category of confusion.
The math nobody does
Here is the comparison people skip when they say TDD is slow.
Writing a feature with TDD costs more upfront. Honest numbers from my own experience, maybe fifteen to thirty percent more hours in the first pass, more when the team is learning. So a three day feature becomes maybe four days. That is the cost everyone sees, because it sits right there in the sprint, visible and annoying.
Now the other side of the equation, the side that never appears in the sprint board.
A bug that reaches production does not cost hours. It costs days, and it costs them at the worst possible exchange rate. Someone has to notice it, often a customer, which already has a price. Someone has to reproduce it, in an environment full of noise, weeks after the code was written, when nobody remembers the details. The developer who fixes it has to drop current work, and context switching is a tax on everything around it. Then the fix needs review, release, and verification. And if the bug touched data, add the cleanup project on top.
I have lived this comparison directly. Years ago, in my agency days in Brazil, we delivered a campaign system for a big client without proper tests, because the deadline was holy. We shipped on time. Then we spent almost three weeks in production firefighting, with the client calling every day, while a calculation bug ate discounts it should not eat. Real money, paid back from our pocket to keep the client. The “time we saved” by skipping tests was spent four times over, plus interest, plus a client who never fully trusted our deadlines again. Trust is the expensive part. You can refund money. You cannot refund confidence.
That is the real comparison. Hours writing tests versus days chasing production defects and losing client trust. When you put both sides on the table, TDD is not the slow option. It is the cheap insurance against the slow option.
Why the test first part matters
People sometimes say, fine, tests are good, but why write them first? Why not write the code and add tests after?
Two honest reasons from practice.
First, tests written after are written by someone who already believes the code works. You test what you built, not what was needed. The edge cases you forgot in the code, you also forget in the tests, because it is the same brain on the same afternoon. The failing test written first does not have this blindness. It states the requirement before the code exists to argue with it.
Second, tests written after are the first thing cut when the schedule slips. I have watched it a hundred times. “We will add tests after the release.” There is no after the release. There is only the next release. TDD makes the test part of writing the code, so there is nothing to cut.
TDD as risk management
At Benevity I work on systems that move donation money. In a domain like this, the question is never “can we afford to write tests”. The question is what level of risk the business accepts, and tests are simply the cheapest way to buy risk down. A good test suite is also what makes refactoring safe, and safe refactoring is what keeps a codebase changeable for years. A codebase that nobody dares to change is a slow codebase forever, no matter how fast it was written.
And yes, I know what you are thinking. “So you use TDD in everything, right?” Of course not. There are projects and projects. I would love to use it everywhere, but that does not depend on the will of one developer. It is company philosophy, team culture, deadlines, all of that. What I always try to do is cover at least the core business with TDD. Do I always manage? Also no . Throwaway scripts, experiments, code I will delete on Friday, those never see a test first. And as I always say, these notes are not here to vomit rules or teach anybody anything. The only point of this one is the math. Is TDD slow or not.
So next time someone says TDD is slow, slow down the conversation and ask for the full bill. Count the firefighting weeks. Count the support tickets. Count the client phone calls. Count what it costs when your best developer spends three days hunting a bug in code with no tests, like looking for keys in the snow. Then compare it with the fifteen percent.
TDD is not slow. Bugs are slow. We just got used to paying for bugs in a different currency, and pretending it is free.
Pax et bonum.