We Need To Replatform

There’s this phrase that I hear a lot from software companies. I hear it so often that it has become a bit of an inside joke for us. It goes a little something like this:

“We need to replatform.”

Or I hear one of its many variations: “We need a rewrite.” “Do you think we should replatform?” “Should I replatform?” “What are your thoughts on a rewrite?” “I’m thinking about a rewrite.”

In reality it’s a call for help. There are significant problems with their current application, team, or business. The problems are hard to identify and it’s unclear how to solve them, or they seem too big and impossible to pull apart. They think a rewrite is their ticket out.

But I’ve fielded this question so many times that it’s allowed me to perfectly hone the most helpful response:

“Why?”

If you’re considering a replatform, and you don’t have a solid answer to that question, then you need to keep reading.

But it feels so good to say yes!

Every couple of weeks someone reaches out to us and says, “I need to replatform to Node, Rust, Go, TypeScript, Haskell, etc.,” which allows me to ask my expertly crafted question: “Why?” The responses I get can range from technical debt to developer availability to “We need to be WEB SCALE!!” But more often than you might guess, the response is simply that they feel their current platform is using “old technology” and they need something newer, something fresher, something shinier. Progress, am I right?

That probably makes me sound like a grumpy curmudgeon, but believe me, I get it. I love to work with bleeding edge technologies. What is more fun than getting to stand up a greenfield project in a shiny new language and experience all of the cuts that come along with it? Make no mistake, it’s the sharp edges of new technologies that excite software engineers – we love the scars we earn and stories we get to tell about solving all of the problems that come along with leveraging cutting edge technology.

Software engineers start their careers because they love learning and they love solving problems. Combine those two things and you get an industry that pushes forward at a breakneck pace. It’s easy to feel like you’re getting left behind.

The problem with that shiny new platform you’ve got your eye on is that it will become the clunky old dinosaur in a few years. If you chase down every new tool/technology/platform that comes out, chasing is all you’ll ever be doing.

Why rewrites are often a mistake.

You might feel like you’re making great progress by rewriting software but, hear me out on this, rewriting code into another platform rarely solves any real problems. If anything solves old system problems in a rewrite, it is usually the rewrite itself, but the new technology always gets the credit.

You should never rewrite working code if you can’t communicate your reasoning. You need significant, compelling reasons to perform a large scale rewrite or replatforming. This leads me to the first, and most important, thing to remember when embarking upon a rewrite:

Your rewrite will take much longer, and cost much more, than you initially estimate.

You’re not going to rewrite a system in 6 months that took 10, 15, 20 years to build, no matter how many people you throw at it. Are you able to maintain, and add features, to your existing system for an extended period of time while also putting resources towards building out a new system? This is an existential question for many software companies.

The reality is that your new system will likely take some significant fraction of the effort it took to build the original system. Software engineers might tend towards pessimism, but ask them for an estimate and suddenly they have more positivity than a self-help guru. So unless your application is really simple, you’re going to be in for a much longer slog than you expected. You’ll create an estimate, then you’ll double it, and you’ll still be way under.

Software systems are deceptively complex, and by the time you fully realize just how complicated your system is, you’re deep enough into the rewrite that you can’t turn back. That’s the sunk-cost fallacy hard at work.

And guess what, the dirty little secret about rewrite estimates is that they are often intentionally low because the people who want to rewrite the software know the business would never sign on if they knew the true costs. Gasp!

The true cost of a rewrite.

The “true cost” of a rewrite isn’t just getting from zero to a “feature complete” release. It encompasses the long tail of bugs and edge cases that were unintentionally baked into the existing system. Over time your software accretes a lot of knowledge, and every line of code becomes a manifestation of how your business works. That logic can often be subtle and unexpected, or even emergent, and when you do a rewrite you can accidentally break workflows or functionality without even realizing it.

Another thing to consider with a rewrite is “second system syndrome.” Also known as “second system effect”, it gets its name from the second system that an engineer writes. They were cautious and conservative with their first system, but now they’re ready to do a rewrite and have a huge list of fixes and functionality they’ve been wanting to make. That second system becomes, as Fred Brooks called it in The Mythical Man-Month, “the most dangerous system” an engineer ever designs.

“The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says, is a ‘big pile.’”

In other words, be very careful about what you bite off as part of a rewrite. It’s so easy to over-engineer when going into a rewrite, and all the easier to slide into when you have a team of really smart engineers that don’t have a ton of experience.

Is replatforming always a bad idea?

So now that I’ve told you that your rewrite is going to be painful, costly, and turn out badly, you might be wondering if I have anything good to say at all. The answer is yes! Here you go:

Your existing platform probably has a lot of value. Maybe more than you realize. And that is awesome.

But if you just scratched “Rewrite” off your ideas list, I’m gonna need you to slow it down. There are a few solid reasons to replatform, so let’s go through a few of those and discuss before you make your final decision.

Your platform is no longer maintained or supported

This one is a no-brainer. If you’re on an unmaintained or unsupported platform, then you need to make plans to replatform. You usually can’t afford the maintenance of a platform yourself, and you need to know that security issues are going to be addressed. If the platform you’re working on is dead, then you need to start planning for a rewrite.

Your application is an absolute nightmare to work with

This one may depend on your pain tolerance, but there are some systems out there that are so cumbersome that they cost more money to maintain than to rewrite. I’ve worked with systems where every change kicks off a Rube Goldberg machine of madness.

One such system had numerous multi-thousand line stored procedures that called each other, sent emails, made network calls, and maintained a ton of global state. Changing the smallest thing resulted in unexpected side effects and ridiculous amounts of regression testing and then inevitably bug fixes. The bug fixes then caused more bug fixes. Systems like this may just need to be put down if you can’t reasonably refactor your way out of them.

Your application is 50 years old

Okay, so 50 years is extreme, but my point is that every platform and technology has a lifespan. Your technology will eventually reach the end of that lifespan and either you won’t be able to find folks to work in it, or you won’t be able to find systems that can run it.

Recruiting

This might sound a little crazy to some people, especially those outside of our industry, but recruiting should be a strong consideration. Talent is the most critical factor of success in our industry. Software engineers love learning and solving problems and many of them are drawn to the latest tools and technologies like a moth to a flame. Working with a modern technology stack will often do wonders for your recruiting.

Approaching rewrites

A detailed guide on how to approach a rewrite is a topic for another time. I couldn’t even begin to scrape the surface here of how to perform an application rewrite. There are an unimaginable number of patterns and strategies out there. But the one strategy that is almost universally applicable is to use an incremental approach. Don’t go for the big-bang rewrite.

If  you’re able to carve off pieces of the system and rewrite them in an incremental fashion, then this is almost certainly the way to go. If your team is able to rewrite incrementally and slowly replace a legacy system, then you’ll be able to show continuous progress which will result in:

1. Higher productivity and team morale, since the project won’t seem like never-ending drudgery.
2. Greater stakeholder satisfaction, for the same reasons stated above. No one likes to see a project that can only show its value at the very end – especially if that project takes longer than a few months.
3. A better quality system. If you’re able to deploy your system incrementally, the lessons you’ll learn along the way will improve the rest of your project.
4. Less risk. If you rewrite as a whole, then it’s likely you’ll have to just switch on the whole new system one day, which carries a ton of risk. If you’re able to roll out replacements to existing functions of the system slowly, then you’ll be able to minimize this risk and maybe even roll back if things don’t go as planned.

I know everyone is “agile” these days, which seems to mean “just start doing stuff without a plan,”(sorry, just showing off my Curmudgeon Card again) but a rewrite really does require significant planning. You need to understand all the different parts of your system and their dependencies, and have a detailed plan for how you’re going to approach the rewrite. The more planning you’re able to do at the outset, the better off you’ll be as you progress.

Don’t take my word for it.

I hope you think about the things I’ve said here, but determining whether a rewrite or replatforming is right for your business and application is a very contextual and personal decision. You’ll have many factors at play, but I’d always urge you to consider whether a refactoring, rather than a rewrite, will serve your business better. If you’re determined that a rewrite is the only course of action, then make sure to spend plenty of time planning, and to allocate enough time to do the job right. A bad or rushed rewrite or replatforming will cost you way more money in the long run.