Why not just rewrite?

As we know, we have multiple options when dealing with legacy solutions, which I discussed in the first Life Cycle Extension article. Often the question is, why don’t just rewrite the application? With a rewrite, we can benefit from a new platform and eliminate two types of technical debt. A rewrite would get rid of debt related to the application and any potential technical debt that is correlated to the actual software platform. It sounds like a win-win situation on paper. Many software companies have already tried different paths in dealing with their legacy software, including rewrites. Periodically, the Standish Group researches the successes and failures of software projects giving us meaningful insights into the practices of others, which I will highlight later in this article. First, let’s have a look at technical debt.

Technical Debt

Technical debt related to platforms exists because the paradigm that drove application development has changed over time. One classic example is represented by the multitude of 4GL language-based platforms that appeared between the seventies and nineties.

These platforms promised and delivered unmatched productivity. 4GL gives vendors a more accessible development language and environments, plus it provides database independence. Yet now the industry faces a new series of challenges like window-based interfaces, web-based applications, interoperability, and service-oriented architectures and so on leaving many of the vendors who support these 4GL platforms struggling to keep up.

New paradigms

The new paradigms created opportunities for upcoming vendors, which excited the new generation of developers. They no longer were interested in developing on older platforms, which meant that vendors of mature software products would in time be starved of bright young resources. The decreasing pool of mature developers would not be able to sustain the market demand, in the end, leading to a diminishing client base and a not so bright future.

Low-code platforms

Although the lack of developers willing to learn and work on the niche and older platforms is, in itself, a considerable management challenge, it is not always related to technical debt.

But the promised and delivered productivity is. Most of these platforms were also making advancements into low-code environments or model-driven architecture to increase productivity. Every solution tends to evolve until it creates a new set of problems, and most of the time, the effort for maintenance is significantly higher than for the initial development. Combine this with a platform that increases developer productivity by assisting in creating new functionalities, and it will result in a ‘clone and change approach’ that generates a very large, very poor architecture code base.

4GL and 3GL platforms

The 4GL platforms that have aged better did so by managing to support never patterns of architectures and developments like object orientation and multi-tier architecture. Few projects, however, really benefited from these as most of the time, they came late, making an effort required to re-architect existing application code very substantial.

Technical debt can creep into 3GL or mainstream programming language like C++, Java, or C# as well. These languages are still going strong, but the frameworks and libraries on which a solution relies may become obsolete over time or stuck in an ancient version with no easy upgrade paths to anything modern. As time goes on, your team will rejuvenate as newer, younger developers join. Then it is only natural to desire getting rid of the old system and to build a new one from scratch. And that would be great, except that complexity and size are silent project killers.

The Standish Group’s research findings

The Standish Group does a periodic study on success and failure criteria in software projects published in the CHAOS report. They report that only 29% of the software projects manage to finish in time on budget and deliver value. Project size is the most important criteria of all to have a significant impact on the outcome of a project. Small projects have a 62% chance of being successful while for the large projects, the success ratio drops to only 6%.

Another essential factor is complexity, while 38% of the simple projects were successful; the rate dropped to 15% for the very complex ones.

In the above assessments, the size was based on team size and development costs. A team of six or fewer members and a project under one million US dollars was considered small. On the complexity side breaking new ground, new technology, multiple teams, multiple stakeholders increased the complexity.

But this is not something new; those who have been around long enough can probably tell horror stories about rewrites that went wrong.

Degrees of change

If we try to classify the type of major changes that we can perform in a software system, we would have the following situation:

System Cleanup
A cleanup is good preparation for any modernization project. It focuses on eliminating artifacts which are not needed but continue to be maintained and executed. Unfortunately, application programming code does not rot, so every piece of functionality that was written, unless removed, is still there and will probably be maintained.

Data Change
Just like the famous Y2K problem where date fields in the databases needed to be refactored, it implies changes in the data structure. Correcting some of the issues that affect application databases can have a major impact on the cost as well as on the quality of any modernization or extension effort done on top of the existing application.

Modularization
This is a significant refactoring, especially in monolith-based application breaking it apart into smaller pieces that are more manageable.

Modernization
Intentional improvement or enhancement of the current capabilities of the system while keeping the current.

Migration
Migration is the big bang approach to modernizing systems. It seeks to understand the existing system from a code and process perspective and build new applications on this basis.

Just as with complexity, the CHAOS report supports evidence of different risk profiles associated with each degree of change. At the safe end of the spectrum with a 57% success ratio is purchasing an existing application and performing no modifications. Then modernizations follow with 53% success ratio. But the chances drop to 22% for a migration which is developed from scratch.

Conclusion

Assessing the opportunities correctly to extend the life cycle of our legacy application can have a dramatic impact on the probability of success of such an endeavor.

Just by opting for modernization as opposed to a rewrite, we can double our chances of success due to the decrease in size and complexity of the work required to align the system with the new business requirements.

Remus Pereni, CTO at Yonder