It’s inevitable—there is always some part of the company’s code base that your development team would like to see redone. Maybe the codebase is messy. Maybe it’s hard to understand how some obscure feature is actually working. Or, maybe your developers want to try out a new language or framework. Whatever the case, whether or not to start a software rewrite is a question that comes up at one point or another in most organizations.

You may think that rewriting a piece of software will make it easier to maintain. I’ve often heard the complaint, “This code is garbage, the person who wrote this had no idea what they were doing.”

That may be the case, but more often the original constraints or requirements for the program or feature simply haven’t aged well. Customer behavior evolves. New technologies emerge. Business processes mature and needs changes. Your software needs to keep up! In this post, we’ll walk through the factors that may point to the need for a complete software rewrite so you can make an informed decision for your organization.

Why are you considering rewriting your software?

I’m not saying that a rewrite of your application is never the answer. However, it should be used judiciously. The factors causing you to consider rewriting code can be an indicator that something serious is wrong in your organization or development team—something that needs an entirely different solution.

If you can identify why there is a belief that your code may be in need of a rewrite, you can better identify and understand the real problem. Take a particular feature that has become so cumbersome and difficult to maintain that no one wants to touch it, for example. Discuss as a team how you reached this place.

Is it that no one is taking ownership of this feature?

Is no one reviewing change requests to the code? Are code solutions not being thoroughly discussed?

Is your marketing team changing its mind on the feature every couple of days, driving updates in different directions?

If these are the issues you are facing, rewriting your software won’t solve them. Unless there are substantial changes in those areas of the business, you will end up back in the same position you are in now—you’ll have new code, but the same old problems.

Now, you may identify and flesh out the problem and still decide to rewrite your software. Or, perhaps after you’ve unearthed deeper issues, you’ll find that a refactor is the better answer. In either case, you will have made an informed decision.

When is rewriting software a good option?

There is no one-size-fits-all answer as to when code or a program should be rewritten, but you can use these guidelines to aid in your decision-making. This is a non-inclusive list of some clues that may mean it’s time to rewrite your application:

1. Your application has an extremely long deployment cycle.

How long deployment takes is relative to the size and scope of your applications. If the duration of your deployment cycle is adversely affecting your business needs, you may need to consider alternatives to your current software solution.

For example, if you have to make a deployment for each content update and your business heavily relies on content, it’s highly likely that your deployment cycle is negatively affecting your business.

2. There is a high risk of breaking things with new features.

Things break—it happens. However, if you are afraid of deploying each new feature for fear of breaking things, you are clearly hindering your development lifecycle.

Before you rewrite your application, make sure that your test coverage is sufficient and that you have fully documented the current feature set. In this process of testing and documentation, you may find that things suddenly stop breaking because you have a better idea of the scope of your application.

Even if you still decide that the best way forward is to rewrite your project, this process gives your team a head start in understanding what they need to build in the future.

3. Your software stack is or will soon be out of date.

When talking to a couple of different people on this topic, one person said that they were using a CMS that was no longer being supported. Here is a situation where a company is being forced to migrate away from its current solution and will most likely have to rewrite a good bit of code. As you continue to use antiquated software, you’ll find that there are fewer developers available who know that software (and you will have to pay them more).

How can we avoid the hidden costs of a software rewrite?

Every software project plan needs to account for potential unknowns. Hidden costs can cause major headaches, especially if there’s no room in the budget to combat them. Make sure you’re accounting for these factors in your software rewrite or refactor decision:

1. Understand that it will probably take longer than you think.

Most software development projects run longer than they are expected to, and the same is true with rewrites. It’s easy to think that because it has been written before that it will take less time to write it again, but that is not true. The reason you are rewriting it is because the old way was unsuccessful.

2. Know that your developers will be working on two projects at once.

Even as production is underway on your new application, someone needs to maintain the old one. Your developers either need to split up and work on the separate projects, or decide how each one is dividing their time between the old project and the new one. Either way, this is going to be hard on your developers.

I like to take an iterative approach, where you rewrite a small section of the application at a time rather than tackling the entire project as a whole. This way, your developers can maintain both the old and the new code. It’s a lot less scope that they have to deal with, and in the process, they will become very familiar with what they are working on.

3. Acknowledge that you won’t be able to work on new features as quickly (or even at all).

Know that you are likely going to have to pause on adding new features for the duration of your work on the new application. If you don’t, you will have to build the feature twice—once in the old system and again in the new one. It’s important to consider how long you will be without new features, and the effect it will have on your company.

Taking the leap: do you need to rewrite your software?

Whether or not to rewrite your software is a complex decision, often with wide-ranging impact on the business. The question internally may be, can we afford to allocate the time and resources needed to get to the heart of this problem and develop a new, comprehensive solution?

However, the real question is: Can we afford to keep trudging on with sub-par software?

We help companies like yours evaluate the opportunity, analyze the potential impact, and develop and implement software solutions that drive the greatest business results. You don’t have to navigate this process alone. Reach out to our team at Method and let’s see how we can help.