Most rewrites serve the engineer, not the business

For a few weeks one summer I woke at 4am to rewrite code my employer had already paid someone to write. It ran in production every day, and it was built on CakePHP. I barely knew CakePHP, so every file looked wrong to me. I knew Laravel, and I loved working in it. So on my own time, unasked, I ported the thing piece by piece, swapping in Illuminate packages until the old framework was gone.

We merged it. We started the next project in Laravel too. And I never once made the case for why it was worth doing, because it wasn't, at least not to the business. The application did the same job for the same users at the same speed as before. The rewrite improved exactly one thing: how the code felt to me.

That is the pattern worth naming. Most rewrites answer to the engineer - what they want to learn, what offends their taste, what looks good in an interview - and not to the company paying the salary.

Working code is a ledger of bugs someone already fixed

The strongest case against a rewrite is not the effort. It is memory. Code that has run in production for years is a written record of every bug someone hit and quietly fixed. The odd conditional, the retry with the suspicious timeout: most of it is scar tissue, and each scar marks an incident you never saw. Joel Spolsky made this point in 2000, calling the full rewrite the single worst strategic mistake a software company can make.

Throw the code away and you throw away the fixes. Then you meet the same bugs again, in production, in front of the same users.

I have worked on a Perl system that was already more than ten years old, and a homegrown PHP CMS of about the same age. Neither looked anything like what I would write today. Both just ran. The companies never reinvested in them, and that was the right call. The code had paid for itself long ago, and every quiet year it kept serving traffic was pure return.

Unfamiliar is not the same as broken

Here is the tell I missed in my own story. I was sure the CakePHP code was wrong, but I had never actually learned CakePHP. Unfamiliar is not the same as broken. When you don't know a tool well, everything built with it looks like a mistake, because you can't yet see the reasons behind the choices. That feeling of "this is all wrong" is often just the sound of you not understanding it yet.

... continue reading