#confoo 2016

Should You Maintain or Rewrite Your Legacy Web Application



Jacques Berger



Goals

  • Evaluate if a web application should be rewritten or maintained.
  • Communicate guidelines to lower rewrite costs of projects.

Overview

  • Legacy web applications
  • Maintain or rewrite traditional applications
  • Benefits and drawbacks
  • Financial aspects
  • Other factors
  • Particularities with web applications
  • Guidelines

What is a legacy web application ?

  • A web application already deployed
  • Might be old
  • May be using outdated technologies
  • Seems unpleasant

Just to make it clear

When I talk about rewriting a software, I mean rewriting it from scratch. I consider rewriting parts of the software and refactoring as maintenance activities.

Should we maintain it or rewrite it ?

The answer may vary depending on who you ask.

  • Developers tend to rewrite.
  • Managers tend to maintain.

History

In web development history, web applications were disposable softwares. This is changing, as web applications are becoming bigger and much more complex.

What about traditional applications ?

This is an old problem. Managers and developers are asking themselves this question since the beginning of software development.

Benefits of maintaining the software

  • The application is stable.
  • Users are used to it.
  • You already know the maintenance costs.

Drawbacks of maintaining the software

  • In some situations, you cannot maintain anymore.
  • Might be less exciting for developers.

Benefits of rewriting the software

  • Opportunity for change (better features, better UI, newer technologies).
  • You know all the pitfalls from the previous development.

Drawbacks of rewriting the software

  • Your new application will eventually become a legacy application itself.
  • You will create new bugs.
  • You have no guarantee that the new software will be better.
  • You might face some resistance to change.
  • Looks like the initial investment is lost.

Let's talk about money !

Costs is the most common argument used to defend this decision.

How to evaluate, in terms of costs, which solution is best

Considering that the current software is already paid

Maintenance costs

  • AMF : Annual Maintenance Fees
  • ERYU : Estimated Remaining Years of Use

$ = AMF * ERYU

Rewrite costs

  • DC : Development Costs
  • PAMF : Projected Annual Maintenance Fees
  • ERYU : Estimated Remaining Years of Use

$ = DC + (PAMF * ERYU)

What it tells us

The maintenance costs of the future application must be much lower than the maintenance costs of the current application to worth the investment.

Conclusion: If we consider only the financial aspects, most projects will cost a lot more to rewrite than maintain.

There is more than just money

Other factors can influence your decision. Some are good, some are questionable.

Good factors

  • You cannot access or modify the code.
  • Technology is unsafe or not supported anymore.
  • The domain changed so much that the current software is now irrelevant.
  • No one can read this programming language anymore.

Questionable factors

  • The code is difficult to maintain.
  • Maintenance costs are too high.
  • The UI is outdated or not user-friendly.
  • Features are unknown (lost knowledge).
  • The software is slow.
  • We are using newer technologies now.
  • Developers are not motivated to work in this code.
  • It is difficult to recruit developers knowing this stack.

What about web applications?

Web applications have particularities that we do not see in other types of software.

Architecture

A web application is in fact 2 applications: the frontend and the backend.

Those 2 applications are different in nature and does not evolve at the same speed.

The frontend has a lot of dependancies toward the backend and the backend does not have any dependancy toward the frontend (generally).

Quickly deprecated technologies

Frontend development is filled with quickly deprecated technologies.

It is moving really fast. Technologies from 3 years ago are not used anymore.

What can we do about this (for your future projects)?

  • Make sure that the backend is maintainable.
  • Make sure that the frontend is disposable, so it will not cost a lot to rewrite.

Disposable frontend

  • No UI logic in the backend.
  • Keep the business logic in the backend as much as possible.
  • The frontend should be as thin as possible.
  • Reduce coupling between the frontend and the backend by using a well defined API.

Stuck with a legacy web application that does not follow these guidelines?

You can still maintain it.

By investing in refactoring activities, you can slowly change or rewrite parts of the application to tend toward these guidelines.

You can identify parts of the code that change often and invest in these parts only.

You do not need to refactor a feature that never change.

Conclusion

  • Rewriting the frontend only might be enough for most needs.
  • It lowers the rewriting costs and does not void your initial investments.

Closing thought

If you are ready to invest a large amount of money on rewriting a software, why not invest in refactoring and modernization?

It might cost less.

Thank you for listening!

Any questions?