If & When You Should Rewrite Software - 3 Tech Stack Rewrite Scenarios




Our top engineering leaders answer the question, "when should you rewrite your software?"

Old technology is a hurdle for companies, from an actual technical standpoint, but also from a recruiting standpoint.

According to Stack Overflow Developer Survey 2020, working on the newest technology is at the top of things developers care about in a job.

There's also the issue with eventually becoming "that product" that looks like it's from the 90s if your tech stack is never rewritten.

However, both of those things are balanced out by the difficulty and cost of rewriting software,  especially since, it's almost always more disruptive and costly than expected.

So what's the solution? Are you just stuck with old technology unless you can dedicate tons of resources to it? What if the job market continues to make it harder to find engineers (which seems likely)?

Should you rewrite your tech stack? And if you should, when’s the best time?

The Life Cycle of a Tech Stack

Tech comes and goes in 5-10 year cycles. That means around year 8, it’s declining (although not The Worst). This decline isn’t necessarily bad for your users, but it can start to be problematic for recruiting developers. After year ten, it can get rough for your users as well--they may start to notice the dated interfaces and slower speeds of your tech stack.

So what should you do? Rewrite your tech every 8 years and keep your devs happy? Or should you keep your stakeholders happy by holding off until year 15? Will that cause you to lose users? Will it cause you to spend more money in the long run?

Woah, that’s a lot to unpack.

As an engineering leader, you need to balance your rewrites with your budget.

While you maybe “should” rewrite your tech stack every few years (purely for recruitment sake), you’re always going to run into a budgeting problem. So the question becomes: when does old tech become too big a risk? When does old tech start to cost more than a rewrite?

Tech Stack Rewrite Scenarios

Weighing the pros and cons of rewriting software vs. saving money is both an art and a science--which is why we asked three Devetry software experts their opinions on the matter.

Since every company is different, and it’s impossible to know your specific tech rewrite, we’ve created three common scenarios.

Company #1 - Declining Technology That’s Impacting Hiring

The stack is React and Ruby on Rails. It is generally reliable with good tests and clean code. It’s been in development for about 7 years. However, they struggle to find new software developers because Ruby on Rails is declining technology. Should they rewrite their tech stack?

Brian, Staff Engineer - “Avoid looking specifically for “Ruby on Rails” programmers. Web developers are good at picking up new tools, and it probably won’t take as long as you think for them to learn on the job. Ruby on Rails does a lot of things right, even though it may be unfashionable in some circles. It receives frequent updates and has a large community.”

Allan, CTO - “This one is a toss-up, but I’d lean slightly towards keeping the Rails backend for the time being and improving the frontend as much as possible to help entice engineering candidates. The cost of a rewrite is likely just a bit higher than the cost of finding Rails engineers, for now. Plan to do a rewrite in a few years most likely.”

Daniel, VP of Engineering - “If the only problem is finding Rails devs, likely they should hire someone more junior, have them learn it all with the expectation that eventually, they’ll be able to support and add to it. However, struggling to find developers is probably not the only problem, and just one symptom of the larger problem: declining technology.

“Maybe not right now, but in the near future, packages/libraries will stop getting updated regularly, security patching will slow down, new web patterns will come and can’t be followed, etc.

“We can certainly all agree that most of the time it doesn’t make business sense to rewrite a platform in a different language. But if the time and money are available, and the stakeholders are on board, why not? Even if it’s only marginally better now, but saves headache, time, and money in the long run, why not? If you want your software to work for decades, there will need to be major work done on it eventually. If that time is now; do it. Because you might not get another chance in the future. “

Company #2 - Declining Technology That’s Impacting the Platform

This platform is written in PHP, a 15-year-old language that’s on the decline. They’ve gotten to a point where the technology is maintainable but mediocre. Should they rewrite their tech stack?

Allan, CTO - “Since it’s both affecting your users and your ability to hire, I recommend a rewrite now. It’ll be costly, but it’s worth it in the long run. It may be viable to piece off parts of the architecture and rewrite them in smaller chunks.”

Brian, Staff Engineer - “Identify the specific problems with the product and understand their source. What makes it mediocre? Slowness, unintuitive UI? PHP is as fast as most languages used in web programming, so maybe the issue is in the data access patterns? Could we paginate data somewhere or add a database index? Profiling and logs can help locate speed issues.”

Daniel, VP of Engineering - “There are a few things they could consider in PHP specifically. Some of the latest versions of Laravel (PHP) are now modernized, so the first thing would be to upgrade their version of PHP. It would definitely take some effort, but it’s likely worth the time.

“If that’s not possible, find the highest risk areas and most essential features. Write those parts in a different language as “middleware” can be a good solution. This also gives a path to eventually rewriting the platform but without all the cost upfront. Piecemeal the rewrite over a year or three to work your way into a better place.”

Company #3 - A Mess of Architecture in a Dying Framework

This scenario’s platform is a mess. Their mobile app is built in a dying framework (Appcelerator). Their backend is PHP. How should they go about rewriting this tech stack?

Allan, CTO - “Rewrite it as a high priority. Everything else you do is mostly wasted money building on something that will be thrown away soon anyway. You can likely rewrite one part at a time (either the backend or the app first).”

Daniel, VP of Engineering  - “In this case, you have to start putting a plan together for a rewrite asap. Because of technical debt, the longer you do nothing, the more you’ll hemorrhage your budget in bug fixes and maintenance.

“From a business perspective, this can be a lot to take on, so I’d suggest planning a multiphase approach. Start with the backend web app, move to the mobile app, and then the frontend web app. You can only limp through for so long. If you don’t take action, you’ll likely keep digging your hole deeper.”

Brian, Staff Engineer  - “If both the backend and frontend are a mess, and the mobile framework makes it difficult to support the app, it may make sense to consider a rewrite. As an exercise, imagine you’re making the app from scratch. What user interactions need to be supported? What data do you need to collect? Use this information to come up with an estimate of how long it would take to replace the app completely. Double your estimate, because the pain of the current architecture probably has its thumb on the scale, pushing you to rationalize the decision of starting over.

“Are you comfortable making zero changes to the code for that duration? Remember that if some urgent feature or bug fix that can’t be delayed comes up, it extends the timeline for the rewrite. If your team is busy keeping the lights on for the existing app how will they focus on making the new one?

“If you decide to go forward, consider how you will migrate users to the new platform. Can the data be easily migrated, or even left where it is with the new code accessing the existing database? What’s your plan for making the new mobile app easy to upgrade to? What level of action is needed on the part of your users? The goal should be to completely turn off the old code. Splitting time keeping two platforms alive will not solve the problem.”

Need help rewriting your tech stack? Reach out to our team of software developers and consultants! We can help you bridge the gap between where you are and where you need to go.