Refactor vs. Rebuild: The Next Generation Application Development Dilemma

One of the toughest choices an IT organization must make is whether to refactor an existing application or rebuild from scratch. The economic stakes are high; time to market is always critical; and the end-user community usually wants something new by tomorrow – at the latest. IT teams begin looking at the refactor-versus-rebuild decision when…

One of the toughest choices an IT organization must make is whether to refactor an existing application or rebuild from scratch. The economic stakes are high; time to market is always critical; and the end-user community usually wants something new by tomorrow – at the latest. IT teams begin looking at the refactor-versus-rebuild decision when the application:
  • Lacks key functionality because it hasn’t evolved with the business (e.g., mobility or cloud integration)
  • Performs poorly
  • Becomes hard to maintain and upgrade.
  • In addition, the technologies once used to create the application may have become obsolete and no longer align with best practices for software development. Even worse, they may no longer be supported by the vendors that created them.
Here are six key factors you need to consider as you decide whether to refactor or rebuild your application. 1. Determine Quality of Code To state the bottom line bluntly, if your application code is virtually impossible to decipher, you should start over. In truth, good programmers won’t want to touch it, and bad programmers will make it worse. High quality, well-organized code might allow you to upgrade your application on a component-by-component basis over time. 2. Judge Your Knowledge of the Code In some cases, enterprise applications may be eight to 10-years old or even older. The honest truth is that unless your development team knows the code inside and out it’s better to start over. There is a 100 percent chance that better tools and programming methods have come along that will make the application development process smoother, faster and of higher quality. 3. Evaluate the Architecture of the Application Componentized software architecture is more likely to be a candidate for refactoring. During development, you can replace or add components one-by-one. Otherwise, extracting components in a sprawling code base isn’t worth the effort. 4. Know Your Budget Rebuilding applications costs more upfront, and you still have to maintain the legacy application during development. Refactoring, on the other hand, is a constant development effort that could cost more over time. Rebuilding applications requires two teams: one to maintain the old software and one to build the new software. Before you start, make sure you can afford the outcome you want to achieve. 5. Embrace the Cloud To paraphrase Leonardo DiCaprio (playing Howard Hughes) from the “The Aviator,” Cloud Computing is “the wave of the future.” Almost every enterprise is implementing a cloud strategy for its applications and data center infrastructure. The honest truth is that custom applications may not even be able to reside in the cloud, no matter which model you choose. Instead of moving an old application to the cloud, you should consider rebuilding software to integrate with the cloud. 6. Don’t Underestimate the Impact of Mobile The last key aspect is mobility in the enterprise. Today, the crush of data from mobile applications and business communications can simply overwhelm – or even break – enterprise applications and servers. Mobile users in the enterprise tend to access frequent bursts of data. Current capabilities may not be able to handle this facet very well – if at all, which can raise development costs for rebuilding or refactoring. Deciding whether to rebuild or refactor software is a difficult choice. Keeping these six considerations in mind will help you decide which course of action is best for your project.

Share:

Categories:

Featured Posts:

Subscribe to our newsletter