If you’ve come here hoping for a mathematically tinged romp through some NP-hard problem and the algorithms you might deploy to attack it, prepare to be disappointed. Sure, I have a BA in Computer Science, but I also have 15 years’ experience in the real world, and this is a lesson from the latter.

An industry veteran with more experience than there are years in my life (at the time of writing) once said to me that writing a system to replace an existing one is surely straightforward: you already have a working example to follow, after all.

And while that makes superficial sense, I’d like to go ahead and propose replacing an existing system as the hardest problem in computing.

And here’s why:

The users already have something. Even if they are itching for change - for something new, better, more modern, cheaper, faster and with fewer calories and less saturated fat - there is an unfortunate reality.

If they’ve had the previous system for more than five minutes, they will have found their way around it. And I do mean all of it.

Those three features you’re hoping to post down the memory hole to simplify everyone’s lives? Oops, Alice, Bill and Doris turn out to use them, even if the other 96 users do not. They won’t be happy if you take them away.

Those defects you’re itching to rectify? Double oops, it turns out that each and every one of them will have found its way into some soon to be poor sod’s workflow. So again, you can’t just “fix” those problems without understanding why that might be.

Oh, and that interface you’re proposing to put a lick of paint on? Don’t forget the re-training for everyone who knew how to use it as-is.

For sure, this is one man’s opinion, but every single time - and there have been several - that I try to replace something already in use, big or small, the above problems crawl out of the woodwork.

By contrast, if you’re building something new, at least you don’t have the weight of history to push uphill.