Aging Applications Don’t Always Need To Be Replaced

Written By Bob Karman

rewriting aging applicationsSo, you just learned the hot new technology that promises blazing performance and a beautiful, intuitive UI—at the same time reducing bugs and making your application scale infinitely. And you have this application that has been around so long that no one remembers the faces that go with the names on the original commits. It is practically begging to be replaced and sent to the app retirement home.

We have all felt the temptation, but though it’s a powerful one, before you charge headlong into the breach, you should carefully consider whether replacing the app with a full rewrite is the prudent course of action. After all, many hours have been invested in creating this product, and many more will be required to replace it.

In addition to developer time, the users have also taken the time to learn how to use the software and become comfortable with it. You will have to take this into consideration when you roll out your new app. Training sessions or tutorials will need to be created, not to mention marketing material to explain why the new app is better than the old one.

The truth is, aging applications are often very costly to replace. Sometimes it’s better to give them a facelift or find a way to replace them over time rather than all at once. In this post, I will show you the pros and cons of rewriting vs. maintaining an aging application. I will also present a third option that strikes a compromise between the two. This way, you’ll have some guidance as you decide on which option is the best for you and your requirements.

The Case for Rewriting

Rewriting the application from scratch is the most exciting option. You have a green field to architect and design as you please, using the latest technologies to help you along the way. If given the option, most developers would choose this route. After all, you spent a lot of time keeping up with the latest tech trends; don’t you want to put those skills to use?

Of course there still need to be other reasons than “the developers are bored” to justify a full rewrite. Unless an app is meticulously maintained, there are bound to be some corners cut at some point. A hard-coded value here, some spaghetti code there, and before you know it, the logic becomes hard to follow, and no one is sure of how the thing keeps working.

This becomes especially problematic once developers start to turn over and the in-house expertise is no longer at the level it once was. This will lead to more time spent fixing bugs and less time available for new feature work.

Another reason to do a full rewrite is that the application simply doesn’t meet the needs of the business anymore. The UI may be hard to use, and the backend is slow to process requests, causing lost business opportunities. The business may have changed to the point where the original reason for the application to exist at all is no longer valid.

At some point all of these problems will add up, and it will become clear that starting over would be worth the investment.

The Case for Maintaining the Current Application

Just because an application has been around for a while doesn’t mean it needs to be put out to pasture. If it still does its job well and the code is fairly easy to work with, there is no reason that it can’t continue to do so for the foreseeable future. That being said, efforts need to be made to keep it that way, such as regular framework and package updates and constant vigilance to keep the quality of the code base at a high level.

If the app still has many users, most developers will have no interest in learning how to use a new application. For the most part, people do not like change.

Developers have been adding features to the app for years, and as a result there is a humongous code base. The development and testing of any new app would take a lot of time, and you do not want to miss any functionality that was popular among the user base.

Doing a full rewrite of an application is an enormous investment of time and money that could be spent creating new products. Do you have a mobile app? Can Spanish-speaking customers view your website in their native language? These new products could help expand your business by attracting new customers.

The Compromise

rewriting aging applicationsThere is a middle ground between replacing the application by totally starting over and simply leaving the app in maintenance mode. You can slowly replace the old app piece by piece. This works especially well if you want to move from a monolithic architecture to a microservice architecture.

Using the principles described in Domain Driven Design—particularly the concept of bounded contexts—you can break up complex domains into a network of bounded contexts. Once you have identified these bounded contexts, they can inform you as to how to build your micro services.

Splitting up your application one piece at a time will allow for replacing the aging application without any dramatic changes to the way your users work. Testing will also be easier, as the QA team can focus on one area of the application at a time.

You can also give users the impression of a new app without having to replace the whole thing by updating the UI and re-skinning it. A clean, modern UI can do wonders for the way users feel about the app. They won’t mind slow performance as much if they are looking at something pretty while they wait.

An Aging App Can Still Do Its Job

However you choose to move forward with replacing an aging software portfolio, you must take the time to plan an effective course of action. Moreover, carefully consider how your decision will affect all stakeholders involved.

Making the wrong decision can set you back years, so be sure to take an honest look at whether or not the existing app is still doing its job, whether developer effort can be better utilized on other projects, and how difficult the current app is to maintain. An additional consideration is can the app be replaced piecemeal, or does it require a total rewrite from scratch?

As we saw in this post, there are pros and cons in both rewriting and maintaining an aging application. There is also a middle ground. Knowing what each option offers you, you can decide what the best course of action is for your particular circumstances.