Despite what the average consumer perceives by using apps such as Facebook, Uber and Airbnb, the majority of today’s consumer and business applications do not use bleeding-edge technology. Unfortunately, the use of older technology and development practices can lead to significant challenges for companies, often leading to the need for a complete software rewrite.
But it’s not as simple as saying “let’s rewrite the application from scratch.” There are different approaches you can take to a software rewrite, each of which affects the process, team and time it takes to complete. To know which approach will work for you, let’s examine the process of rewriting a software application: what it means, how you can do it and how long it could take.
Understanding technical debt
How often have you, as a business user, asked yourself, “Why doesn’t this app work the way I want it to?” Many of the underlying issues with legacy software applications are tied to a software development term called technical debt.
Technical debt happens when software developers have to make compromises on code or design to get the project done. These compromises have the potential to affect maintenance, testing and future development.
As such, technical debt represents a price that must be paid in the future, either to fix the underlying issue or continue to pay an ongoing cost because it remains unaddressed. Technical debt is also often related to things like a lack of documentation, certain development practices and even the types of third-party tools used.
Of the technology businesses we evaluate on behalf of private equity investors, a large number have more than the normal amount of technical debt. As a result, at some point many of them have to consider a complete rewrite of a customer-facing application.
Just like financial debt, technical debt is not inherently a bad thing. It’s only bad when it’s irresponsibly managed (we’re looking at you, Great Recession). While people have attempted to try to calculate the actual cost of technical debt, the attempt is usually fraught with underlying errors and is often an attempt by unsophisticated technology leaders who have ulterior agendas.
Also, like financial debt, ignoring technical debt gets exponentially worse as time goes on. Those who choose to actively or passively ignore it will eventually need to repay it or file for bankruptcy (which, in the context of technology,effectively means starting all over and rewriting the application).
When to rewrite software?
Often, we find situations where application development management teams believe their product to be “feature complete” and simply “turn off” the spigot to their development – usually by ending the contract with an external team. While it is possible to build a software application that is “done,” it’s more the exception than the norm.
One of the main reasons software is rarely “done” is because the environment in which applications operate changes at a faster pace than the software does.
A great example of this was the explosion of mobile devices in the mid to late 2000s. Many software application developers who had legacy technology frameworks that could not integrate into mobile applications were left stranded when their clients demanded mobile functionality. Not only that, but the ability to adapt to mobile-only became increasingly more difficult as time went on.
The Y2K bug is another example of building software that didn’t support future needs. In this example, developers building code during the mid to late 1900s used the short form for the year — i.e., 60 instead of 1960. As 1999 neared, there was great concern that computer systems would not recognize the year 2000, instead think it was reading 1900, because the year code would be “00.” Reading the year code wrong could mean serious problems for companies, especially financial companies and high-tech firms. As a result, a lot of work ensued to fix the year code problem, redesigning applications to recognize a 4-digit year code.
As history has shown, it’s inconceivable to think that our environment will never change. Thus, software rarely is ever “done” — which is why software rewrites happen. Some of the typical rewrite scenarios include:
- The architecture represents an aging system paradigm.
- The underlying framework is poorly supported, completely unsupported or incorporates design patterns that are inefficient or clumsy.
- Some new environmental change is either impossible or technically challenging to adopt without material changes in their cost to serve (e.g., supporting the system requires more people and introduces more bugs).
- Original code is hard to understand, wasn’t written well, isn’t well documented or has resulted in increased customer service response times, increasing costs.
- The current development team didn’t write the original code base.
What does an application rewrite look like?
While there is some nuance to this, there are generally three options for completely rewriting a system. There is never one right answer that applies to every situation.
Instead, you need to consider the dynamics of the business. For this reason, we do not provide recommendations to our clients without a full appreciation for the overall business situation and transaction thesis.
The three generally accepted options for an application rewrite are:
- Incremental strangler: Incrementally rewrite the system and “strangle” the old one.
- Full rewrite: Using the same development team, build the system entirely from scratch while continuing to maintain and advance the old one at the same time.
- Cannibalized full rewrite: Build the new system completely from scratch with a completely separate and isolated team, and then eventually cannibalize the old user base.
Let’s examine each option in more detail.
Incremental strangler
When you adopt the “incremental strangler” approach, you are slowly developing out of the old system. The development team writes all new functionality in the new technology architecture. Over time, you incrementally refactor old functionality using the new architecture. This can be a potent option to accompany scalability within your technology and organization on the whole.
This approach allows clients and users to introduce software into their workflow gracefully, but it’s not without its pitfalls:
- Strong project management is critical for this approach because you will need to decide what’s more important at any point in time — new functionality or refactoring old code.
- If not properly managed and without a plan in place to have the old code refactored into the new architecture by a specific time, you could potentially never finish the rewrite.
Full rewrite
A full rewrite means you are developing a new version of the software alongside the old version using the same team. This approach can work because the team building the new system has the knowledge of how the old system works.
However, the advantage of using the same team can also be a disadvantage. As software development takes place on the new system, the development team must also continue development on the old code due to customer demands.
Side-by-side development can result in mixed priorities for the development team. The new code is not only trying to catch up with the current code but also with any newly developed code for the old system. This is akin to starting a marathon 10 miles behind with an equally skilled runner and expecting to end the marathon at the same time.
Cannibalized rewrite
A cannibalized rewrite means you are using a separate, isolated team to build the new system from scratch, cannibalizing the old user base. Essentially, you are developing a competing application with all the same functionality (think Skunk Works).
This approach comes with some common pitfalls and risks:
- Strong product management is necessary because there is often the desire under the new architecture to introduce different workflows, patterns and functionality that are potentially adversarial to users.
- It’s impossible to know if customers will easily adopt the new version of the application, resulting in a risk of unknown unknowns.
- Both development teams can build animosity towards the other for different reasons. The old team sees their jobs in jeopardy due to the potential loss of users, as well as being jealous of not working with new technologies. The new team may look down upon the old team for what they consider poor development practices or decisions and feel they are better suited to build the new application.
- Customers may become frustrated or concerned that changes are happening and start looking at competitive options.
How long does a software rewrite take?
It’s nearly impossible to calculate how long a complete rewrite will take. After observing these type of situations play out more than 50 times in our collective experience, there are a few conclusions we can confidently draw:
- It will almost always take longer than developers think.
- It will almost always cost more money than developers think.
- Simply adding more resources will not unilaterally make development go faster.
Unfortunately, it comes down to human nature. Developers, and humans in general, are overly ambitious about their capabilities and thus tend to overestimate their ability to enact change. As has been proven over and over, planning large scale projects, regardless of industry and domain, is wrought with planning fallacy. The only known solution is for experienced outsiders to provide a third-party objective view.
From Planning Fallacy by LessWrong):
A similar finding is that experienced outsiders, who know less of the details, but who have relevant memory to draw upon, are often much less optimistic and much more accurate than the actual planners and implementers.
In our experience, these types of endeavors usually cost 1.5x-2x as much as estimated, are 1.5x-2x as long, and should only require resources for skill gaps and where a service-oriented architecture can isolate modules to individual teams.
Want to learn more?
Rewriting can be part of an overall plan to scale technology and grow as a company. This is where Crosslake can help; as a trusted advisor we have years of experience navigating a variety of extremely complex rewrite situations. If you’re looking for help navigating the challenges of a software rewrite, please reach out.
