Time for a Rewrite Part 1: Motivation
For the next couple of posts(ish), I’m going to share my thoughts on rewriting legacy applications.
How many times have you heard the following about an application in your organization: “this sucks, we should just rewrite it”?
I’m sure I’ve said it at least a few times. For a while, the smart money was on generally avoiding rewrites and for good reasons. However, as new tools make it easier to maintain velocity in a software project, a rewrite shouldn’t just be thrown out on principle.
There are some great questions to ask yourself if you’ve ever thought about rewriting a deployed legacy system. Today’s post centers around the question “Do you have the right motivation?”
In other words, are you considering a rewrite for the right reasons. Some good reasons include:
- The application can no longer make company and/or performance business requirements. This one is obvious, but, especially in cases of performance, make sure this is the case (more on this below).
- The application technology stack is becoming too costly or difficult to support. Maybe the application requires expensive proprietary servers or people who are skilled in the technology powering the application are becoming harder to find and more expensive to hire. Another example of this might be that the framework or platform the application was written in is deprecated to the point that it is hampering interoperability needs or upgrades to strategic and important new technologies.
- It is too difficult to add new features due to extremely excessive code bloat and smell. This one is tough to quantify (see below), but can be a good reason to start anew if it is to the point that it is hurting the company’s competitive edge.
- The application development is outsourced and the working relationship with the primary vendor has soured. This may not justify a full rewrite, but there are circumstances (don’t have a license to modify the source code, can’t legally add new hardware, etc.) where this makes sense.
- The application development is internally maintained and the platform makes it difficult to acquire and keep good talent. If you see engineers roll their eyes or shrug their shoulders when you try and make Struts 1 development sound exciting, it might be time to move to something good engineers are excited to work on. Obviously, you can’t let the latest technical fad decide everything, but there is a pretty obvious line when all the good engineers in your group start jumping ship to work on cooler stuff.
Some bad reasons to perform a rewrite include:
- Someone in the company just got wined and dined by a vendor. Enough said.
- Political motivation such as a new president trying to show off their chops by beating up on legacy technology or making a play for control of another group.
- The application development is internally maintained and you hear casual complaining over code quality by engineers. As I stated above, code quality should be considered for sure but this could also signal that a couple of iterations are required to clean up and refactor the code. If the engineers are complaining about the lack of testing, take a couple iterations to add tests. Before making a decision to drop everything and start from scratch, see if engaging the right engineers to take ownership of the problems they complain about helps to fix them.
- Offhand determinations that the application doesn’t perform well or doesn’t meet business requirements. These sorts of decisions should be decided using real measurements and with a good understanding of the entire process. If a transaction seems to take a long time, understand what it’s doing and if it’s really the application’s fault. Maybe the application is interfacing with another internal process that needs to be optimized. Maybe the UI has poor speed metaphors and just adding a throbber will make it feel faster. Make sure there is hard data to support this.
Next time, I’ll talk about basic things you’ll need to help decrease the likelihood of failure during the process.