Sometimes I feel conflicted when my team does very strict TDD and apply “heavy” refactoring because it feels like we are committing some kind of “over-engineering” or “gold-plating” sin.

But I’ve noticed something counterintuitive: when we do this, our team actually moves faster. Even though it feels like we’re going slow.

The Difference

What’s the difference between a master carpenter and a regular carpenter?

About a 16th of an inch.

The joke is that master carpenters don’t add that much impact, besides precision so small that no one but them cares about.

But that 16th of an inch is everything. Without it, small problems snowball into big headaches for everyone downstream. In my experience, software is the same.

The Tom B Story

I worked with a master carpenter by the name of Tom B, who knew how to mill wood to perfection. Sometimes it seemed like he was the bottleneck to a lot of operations. He was a perfectionist. The wood had to be sawed straight, planed square, absolutely no shortcuts.

As a result, to both the trained and untrained eye, it looked like Tom B was slowing everything down. Sometimes it seemed to make sense to just order from the lumberyard and mill the wood on-site with other people who worked “faster” than Tom B.

Except when that happened, you’d find that the other carpenters who had to install that hastily milled wood would have to wrestle with it. They’d take a much longer time doing the installation than if they’d had Tom B’s milled wood to work with.

Working with his milled wood, everyone else moved so much faster. The carpenters could install pieces quickly because they didn’t have to wrestle with warped or poorly cut wood.

The metrics looked roughly like this:

With Tom B:

Without Tom B:

The Paradox

So in a way, Tom B took longer so that everyone else could have a much faster output. But it was hard to see that sometimes.

When you zoomed in on just Tom B’s metrics, he looked like he was slowing down the entire process. But really, he was making the entire process faster.

TDD and Refactoring

This is what our team’s TDD with good refactoring feels like to me.

It was counterintuitive that slow Tom B made for a fast team, but when you zoomed out, he did make for a fast team. In my experience, TDD is similarly counterintuitive, and similarly efficient.

When you write tests first and refactor heavily, it can feel like you’re going slow. Your velocity on that particular feature might look lower. But the precision does add speed. The tests catch bugs before they compound. Error messages are actually helpful. The code is easier to reason about and extend.

Just like Tom B, the impact is worth it, even if it’s about a 16th of an inch.