To rewrite or not rewrite a software ?

Writing a software is a incredible difficult task. When the time has come for the software to know the retirement : should we rewrite it ? or have an progressive approach ?

TL;DR

Here are my thoughts on that subject.

In a previous article, I wrote about how to migrate a legacy software. I have planned, programmed, handled several software progressive migrations using dedicated tools in my career. I have created a small company Byoskill, to handle these subjects.

Since, I have been using some facts to decide between a full rewrite and a progressive migration.

The presentation below has been produced for a customer software some time ago and I will use it as an example.

Why writing a software is difficult ?

Let’s be honest together. Writing a software is incredibly difficult. Your latest framework choice won’t change the thing. Neither the most beautiful functional language.

A good software takes team players, the right environment, some skills and experience, efforts and luck. Capers Jones has written several interesting articles about the success and the failure of Software projects.

These tables illustrate the difficulty to lead to a successful project.

Capers Jones interesting articles here and here.

My first argument to be taken into account in the debate pro or con rewrite is the following :

A legacy software is a software that had enough success to ages. Thereby a convergence of facts allow ed him to born, grow up with new features, get fixed and finally ages.

My second motivation based on Capers Jones observations and a lot of similar experiences I encounted in the business of software migration.

Big software projects aka big rewrite are doomed to fail.

The fluctuating market

The conditions that enables the current software to live have probably changed in the recent years. Basically, our software is fighting against the following tendencies :

• • Complexity is the software is increasing
  • Market is not waiting for releases and its appetite is growing for new features
  • Disruption is everywhere : competitors, startups , pricing war
  • ROI law has changed in favor of the scalability and the  number of users rather than higher license prices
  • Low-qualified workers used for maintaining an existing software  are not a appropriate answer to create state of the art technologies.
  • Creating new software (aka rewrite) requires true software leaders and informed product owners
  • Change management is a tricky and nasty affair

The situation has to be evaluated precisely. Will your customers wait for this brand new version ? How will you managed their expectation for the new features ?

Can all the software be saved ?

This tricky question is probably the real rationale behind the pro/con debate in favor of a rewriting.

Basically you have three choices in front of you :

Outsourcing developments

The easiest and safest choice for a manager. To not decide anything 🙂

Basically, transfer your legacy software to a company that will promise cheaper rater and cost. Keep the possibility to switch when the outsourcing company will increase their rates.

Blame them and plan your future new projects while keep the cost indicators low for the current solution.

Sole problem : you do not know when you will be able to launch the new projects. Your budget is most likely melting as your maintenance cost.

The Big Rewrite

 

To enable a big rewrite, you need to basically have the following warranties :

• You have enough time to build your new software
• You have the full endorsement of your customers, your users and your stakeholders
• Your business knowledge is perfect and synchronized with the current market need
• Your users are not expecting the same software ( features, workflow and yes bugs)
• And all basic conditions to lead a project (cleancode, software craftmanship)

I believe that a successful rewrite project is basically not a rewrite.I would even recommend to not call it “new version” of the product. Rather a new name, a new UI, a new customer/user journey. Calling it a new version of a product where most of the features are missing is always a bad idea.

Progressive migration and automatic migration

Even if these two approaches are fundamentally different, the progressive migration and the automatic migration shares the same goals.

The goals to achieve could be the following ones :

• Reduce the time of migration : shorter is the project, higher will be the success probability
• Keep the most useful features, saves money for the new ones
• Performs critical technical debt operations
• Avoid any complications in the change management (political issues, conservative users)

I would recommend these scenarios when you have optimal working conditions. Indeed you will have to handle some highly technical software re-engineering.

• a great motivated team
• a supporting management (refers to point 1)
• a whole set of features
• difficult constraints (time, political, market)
• some experimented programmers and architect oriented.
• a evolutionary technology stack allowing easy interactions with a new stack (no proprietary languages, no 4GL)
• possibility of functional data layering

This article has been already too long to detail the refactoring steps.  I will encourage you to reed the other articles on my blog like this one for a preview.

I hope you will have learn one thing or two about the decision process about rewriting a software. If you have arguments in favor or against what I have advised it, please let a comment!

All these informations are extracted from my experience with byoskill.com. I am offering cleancode courses and support for automatic software migrations.