Here’s a scenario common to IT professionals. The requirements for the new functionality are finally in and all we need to do now is estimate and plan how we will extend the application to support these requirements. What happens when retrofitting an existing application with new features is harder than fitting a square peg through a round hole?
Many people in the IT circles are always eager for a chance to redo something their way, using the latest and greatest technology. While this is not a good reason to replace a working application, there are some legitimate circumstances where a total rewrite is the best option, such as:
- The application has gone past its shelf life. This can be due to changing business processes, scope and intended audience. For instance, providing mobile access is often a driver for moving towards newer development platforms.
- The application is inherently limited. In many cases, implementing new requirements within the existing framework will require a major overhaul. Piling on functionality to an inadequate architecture is often a recipe for disaster as the scope and audience of the application grows.
- Obsolete technology represents a risk. This could be due to reliance on software components no longer in support or shortage of developers with skills to maintain the application.
From a technical standpoint, you know that a full rewrite is the best option to sustainably address short- and long-term requirements. But what do you do when you are dealing with decision makers whose idea of a budget does not allow for that option?
When presenting the alternatives to decision makers, it is important to stress the intangible pros and cons for both the extend and rewrite options, focusing on the risks of the existing architecture versus the usability and support improvements of the rewrite. It may not be possible to present a scenario where the rewrite costs are less than the extend option. However, if you can keep the cost difference close enough and work on the messaging to articulate the added benefits of a new application, you can significantly increase your chances of getting approval for the rewrite so that users get the application they need, and the IT department is in a better position to provide ongoing support.
I recently dealt with the extend vs rewrite dilemma with one of our clients. Their leadership understood why a rewrite was needed. However, their budget made it difficult to find a rewrite scenario that would provide the necessary features at a reasonable cost. Our team found a more-feasible “partial rewrite” option by identifying and focusing on essential requirements, resisting the urge to rewrite more adequate components and finding development optimizations.
Distillation of Requirements
An in-depth view of the existing application allowed us to find the superfluous functionality that we could eliminate from the partial rewrite scenario to reduce our development efforts and control costs:
- Unnecessary redundancy. Identifying multiple (redundant) ways to perform some operations, not all of which worked to perfection. By determining the most natural, common path used, we reduced the scope of the implementation, along with time required for testing. Most importantly, we reduced the potential for bugs.
- Overcomplicated functionality. Simplify whenever possible is the mantra. Frequently, however, we are asked to implement what users “think they want,” so they can then see what “they would really want.” For example, too often there is a strong desire to compartmentalize access and be overly restrictive about “who can perform certain action or see specific information.” While some core access restrictions are important, overly complicated security models are inefficient and not worth the cost. A simpler model usually is just as adequate, easier to maintain and better suited to promote the necessary collaboration to increase productivity. Notifications is another example. Users will get excited about how the system will alert them of all that is happening. Once they start getting the e-mails, however, they realize that it is too much. This is another opportunity for simplification.
- Unused functionality. Frequently we are asked to implement features “in case” the functionality was needed or for business rules that are not fully defined. Usually, there are one or two areas where it does not seem possible to fully get requirements, but since these are within scope, we are forced to make our best guess, implement what we know and hope for the best. For this partial rewrite project, our philosophy was that it is hard to predict requirements when the business process is not well-defined. If we made a guess, we would most certainly have to correct it when users identified their real requirements. So, why bother? Our approach was to leave these items out of our scope and implement them at later phase, when and if the business was ready for this functionality.
Rewrite Most, But Not All
Sophisticated applications are seldom monolithic or consist of only one component. Usually, there are different parts that make up the application. In our case, we were dealing with the following pieces:
- Application database
- ETL routines (to integrate with another application)
- Service layer
- Web client
- Mobile client
While there was rationale on how each of these pieces would benefit from a rewrite, a full rewrite was not a feasible scenario from a cost perspective. We stayed within budget by carefully choosing our rewrite targets and finding a way to make newer and existing components to work together. We used our rewrite dollars for the foundational layers (database and service) and the web client, which had the broadest user audience. We planned for adapters or wrappers so that the existing ETL and mobile clients could remain virtually unchanged. (We often think of wrappers as a pattern for integrating different and/or third-party systems, but sometimes these systems can be two different evolutionary steps of the same system.) The effort to develop these wrappers was significantly less than rewriting these components. What’s more, deferring major changes to a subsequent phase resulted in significant cost-savings.
Optimize Development Cycles
We relied on two common strategies to optimize our development. The first was to be very diligent about common functionality that could be used on higher-level generic classes/objects to avoid code duplication. The second was to invest in a UI controls library to make it easier to deliver an appealing user interface with the bells and whistles that users expect in less time than it would take to implement them from scratch.
Granted these are basic concepts, but they are often overlooked. What may seem to be an expensive development tool can actually be a very cost-effective option when considering how many development hours it will save.
Remember: It’s a Process
A comparative analysis of an extend versus a rewrite—or to split the difference with a partial rewrite as we did—is not an easy one to make. It requires a lot of work, research and effort to “find a way” to choose the best technical alternative possible within the constraints of the budget. No matter what the decision is, however, in the end you will end up a more valuable software professional and have a better understanding of your current implementation and user requirements. Plus, you will certainly know what you will do differently in a full rewrite. Maybe you will do that detailed audit log this time! What better way to prove that a certain feature is not needed than to show there are barely no entries for it in your audit log?!
POSTSCRIPT – Halfway through the initiative, our client’s project managers, in part because they were pleased with progress to date, decided to extend the functionality scope. This made the economics for the full rewrite scenario much more attractive. Given this development, the project evolved into a full replacement and all components were re-written. Adopting best practices for software development, with clear distinctions between service and user interface, resulted in many efficiencies as we replaced the components that we were originally intending to adapt. While our new, shiny application dream came true, the key takeaway is that we always had a plan.