A few years ago, I interviewed with a CTO
Everything was going well until we started talking about automated testing.
I explained how useful tests had been in some of the systems I worked on, especially when we had to change existing behaviour without breaking something completely unrelated.
Then he interrupted me.
"We don’t write tests because our business logic changes too quickly."
For a moment, I understood what he meant.
They were a startup. Things changed all the time. Requirements moved fast, features were rewritten, and nothing stayed stable for very long.
So why spend time testing something that might change again next week?
But the more I thought about it, the stranger the statement became.
He was using change as the reason not to write tests, when change was exactly the reason tests mattered.
If your software barely changes, you might survive for a while with weak test coverage and a lot of manual checking.
But if your business logic changes every week, you are constantly touching code that is already running in production.
That is when the risk starts to add up.
Fast-changing software does not need fewer tests.
It needs a safer way to evolve.
Tests Give You Something to Rely On
Tests are usually described as a way to catch bugs.
That is true, but it is not the main reason I value them.
The bigger benefit is that they give you something to rely on when you change existing code.
Imagine you are asked to update a pricing rule that has been in production for more than a year.
The request sounds simple. A discount should no longer apply to a specific customer group.
Writing the new condition is easy.
The real problem is figuring out where else the current behaviour is used.
Maybe the same rule exists in another checkout flow.
Maybe one market has its own override that was added two years ago and never properly documented.
Maybe an old campaign still depends on the current calculation.
Without tests, you can read the code, check a few scenarios manually, and ask someone from product to verify the result.
That may be enough in a small system.
After a few years, it usually is not.
Too much context ends up spread across code, tickets, old decisions, and people who may no longer be on the team. At that point, manual testing becomes less about verification and more about hoping everyone remembered the right things.
Useful tests do not prove that the change is correct.
They do not tell you that nothing can go wrong.
They give you feedback about the behaviour the team already decided was important.
And in a system that keeps changing, that feedback matters.
Change Is the Normal State of Software
Software is never really finished.
Business rules change. Customers use features in ways nobody expected. Performance becomes a problem. Regulations evolve. Decisions that made sense two years ago stop making sense now.
Sometimes the request is genuinely small.
Other times, one small request exposes a design problem that has been sitting there for years.
You add one condition and discover that the same rule is duplicated in four places.
You try to update one workflow and realize that three unrelated modules depend on it.
You fix one edge case and suddenly the change touches far more of the system than it should.
This is where the lack of tests becomes expensive.
Teams compensate with manual checks.
The developer verifies the feature. Someone from product checks the happy path. Maybe a few related screens are tested before the release.
That works until one of the forgotten cases breaks.
Then releases become slower. More people get involved. Everyone becomes a little more careful around the same parts of the codebase.
Eventually, some areas become known as dangerous.
Everyone agrees they should be cleaned up, but nobody wants to be the person who breaks them.
The frustrating part is that the engineers may know exactly what is wrong with the design.
They may even know how to improve it.
They just do not trust what will happen when they touch it.
That is how temporary technical debt slowly becomes the architecture.
Not because nobody noticed it.
Because changing it feels riskier than leaving it alone.
A useful test suite changes that.
It gives the team enough feedback to improve the system gradually instead of waiting for one huge rewrite that may never happen.
This does not mean every test suite is useful.
A slow or flaky suite can create the same uncertainty it was supposed to remove. Tests can also become so tied to the implementation that harmless refactoring breaks them everywhere.
The point is not to write as many tests as possible.
The tests should protect the behaviour the business depends on without breaking every time the internal structure changes.
The Sentence I Still Remember
I do not remember anything about that interview anymore.
I do not remember the architecture they described or any of the technical questions they asked.
But I still remember that sentence.
“We don’t write tests because our business logic changes too quickly.”
What made it such a red flag was not simply that they did not write tests.
It was the reasoning behind it.
They knew the software changed constantly, but instead of giving engineers a safer way to make those changes, they accepted uncertainty as part of the job.
That told me something about the engineering culture.
Engineers were expected to move quickly, but without the feedback needed to know whether their changes were safe. And when that becomes normal, people eventually stop improving the system. They avoid refactoring, work around bad design, and become more careful every time they touch old code.
Since then, I have worked on systems where a tiny change took far longer to verify than to implement because nobody knew what else might break.
I have also worked on systems where much larger changes were possible because the team had enough feedback to move step by step.
That is why the sentence stayed with me.
We do not write tests because the software is stable.
We write them because engineers need the confidence to change it.
Top comments (0)