One typical Friday morning in 2004, I walked into a government building and headed to work. I was a junior Java engineer and part of a hired team building an internal system for a government agency. We were a few days behind on schedule, and a technical issue arose. During the morning team meeting, we made a plan to refactor a small key part of the codebase - an effort that should have taken just the morning. And I made a classic mistake.

I was tasked with rewriting one file that other parts of the program relied on. As I started to change this file, I saw ways in which other related files could be improved. And then other functions that could be optimized. Pretty soon it was midnight Sunday and I was quite deep in the rabbit hole.

If I had wanted to change the oil of the car, I now found myself having completely dismantled the engine. The oil filter lodged in the engine block and cylinder head gaskets commingled with timing belts. The program wouldn’t compile - didn’t work at all.

At about 2am, I deleted all the changes I had made over the past 72 hours, and went back to the original library. I spent 45 minutes rewriting that file and slept for a few hours before returning to work, exhausted and defeated.

My beleaguered ambition to rewrite a big chunk of the codebase that weekend isn’t uncommon, as I learned later and have seen in several companies.

In fact, these efforts occur a much larger scale when companies decide to migrate to the latest front end framework or infrastructure management technology. These large refactoring efforts can take months or sometimes years. All the while, product innovation stalls.

For a startup, whose competitive advantage is speed, this innovation hiatus has an enormous and unquantifiable cost. In the worst cases, it can kill the company.

So, when is embarking on a large refactoring worth it for software companies? When the technology limits growth and revenue. That’s my heuristic.

Refactoring makes sense when a new feature or product for which customers will pay cannot be built without it. Refactoring is a worthwhile investment when customers will churn. Refactoring is like any other product and engineering initiative: it must be prioritized relative to the future revenue contribution to the business.

Revenue contributions for future products can be difficult to estimate. But in many cases, the answer is obvious. Even if my refactoring efforts had succeeded and I had optimized all those Java libraries, none of it would have contributed to a happier customer or more revenue. It would have been code poetry, which is a wonderful thing, but not a priority for a fast-moving startup.