Rewriting a system so that nobody notices

Companies sometimes call me about an application that works. It has worked for years, people know how to use it, nobody complains about it. The trouble is that it’s built on a technology that’s aging — the security patches are drying up, it’s getting harder to find someone who knows it, and it plays less and less nicely with everything around it. Sooner or later it has to be rewritten.

And then the same question always comes: will it work exactly the same afterwards?

It’s exactly the right question. Rewriting a system someone uses day in, day out is riskier than writing something entirely new. With something new, nobody knows how it’s supposed to behave, so you agree on it. With the old one, everyone knows exactly — and every deviation is a bug.

First I record what the old one does

The method I use for this is called golden master, and it’s delightfully cheeky in its simplicity. I start recording on the old application and let it do its ordinary work on real data. I note down what went into it and what came out.

When the new version comes along, it gets the same inputs and the results are compared with the recording. Do they match? Done. They don’t? I’ve got work to do.

That means one important thing: the specification isn’t the documentation, it’s what the system actually does. The documentation for a fifteen-year-old application describes how things were meant to be. The recording describes how they are.

The bugs stay. On purpose.

This tends to be the only thing that really surprises the client.

When the new version differs from the recording, it almost always looks, at first glance, as if the new version is better. As if the old one calculated it wrong and it’s finally been put right. And I still change it back, so that it gets it just as wrong as before.

The reason is simple: someone has already built something on that bug. They’ve gotten used to it, they work around it, they correct for it on the side. If I quietly fix it, the ground shifts under someone who doesn’t know anything has changed — and they find out the moment their numbers stop adding up. So the new version behaves the same, and fixes are dealt with separately: I write down what I think is wrong, the client says yes or no, and only then does it change.

Never in passing, and never without their knowledge.

What the client gets out of it

Peace of mind in the most unpleasant week of the whole project — the one when people switch from the old system to the new. They’re not moving into the unknown, but into something that demonstrably does the same thing.

And if something does differ after all, it’s written down, along with who approved the change.