Almost everyone who works with computing, or at least works closely with an IT team, has heard this sentence: “We have to rebuild the system!” The result is a new system version released frequently.

There can be many reasons:

• Replacing outdated technology
• A new platform
• Or the most genuine reason: providing maintenance to the code is becoming impossible.

The consequence of this is a large number of systems being rebuilt. Looking around, I would estimate that 1/4 of IT personnel are “redoing” a system (this estimate is not statistical nor scientific).

I’ve noticed two serious errors in this context.

Error 1: Turn Off / Turn On

When a system is rebuilt, fully replacing the old one with the new one should be avoided. Ideally, the transition should be continuous, with the new version gradually taking the place of the old one.

A very common decision is: “Let’s begin from scratch, and when it’s ready, we replace the old system with the new one.”

This decision poses several risks:

• Taking a lot longer than expected (I’ve seen a 3-month estimate turn into 3 years)
• Dividing the team’s attention between the new and the old system, which can be implemented in two ways:
  • subdividing the team, which can undermine the motivation of the sub-team that works only with the old version,
  • or allowing everyone to work on both systems (a slightly better option), but in this case the team will face constant changes of context
• New functionalities have to be included both in the old and the new system, which can explain why the estimates are so poor – the scope keeps growing
• High chances of incompatibility when the new system is launched (and more delays as a consequence)
• Growing dissatisfaction among users, who don’t see improvements in the system they’re using (despite the great effort being made in the background)
• User dissatisfaction when the system is launched, because they’ll have to learn everything from scratch
• For a long time, the new system has no real users, and without exposure it can have several issues that will only emerge when it starts being used

So what’s the suggestion?

STRANGLER SOFTWARE

The idea is to build new software that is able to coexist with the legacy software, preferably in such a way that the user has the impression that it’s a single system (even if part of its interface looks nicer, for instance). The metaphor Martin Fowler used for that was inspired in botany, like a fig tree that wraps around another tree and, after years, strangles it completely [Martin Fowler, Strangler Application].

The objective of the first Sprint should be to create a mechanism for both systems to coexist.

The degree of difficulty in doing this depends on the implementation of the legacy system. For example:

• If the system to be replaced has SOA architecture, it will all be much easier
• Otherwise, call interception is an option
• With MVC architecture, one possible tactic is replacing the interface (view), gradually substituting the Controller and the Model
• The final option is system communication through the database

It’s also recommended to surround the system with acceptance tests, to make sure that whatever was working well will continue to do so.

Even if the decision has already been made or if it’s impossible to follow the suggestions above, there is still another serious error to be avoided…

Error 2: The functionalities should be maintained

In the scenario of rebuilding a system, we commonly see a backlog based on functionalities of the old system.

As every agile developer should know, setting up to work on a system with a huge and detailed scope has several drawbacks:

• There is no priority, and the focus is on completion
• There’s a tendency to break down work into technical stages, because the system will only be ready when everything has been implemented
• Items under uncontrolled development (non-limited work in progress)
• Higher management cost, because the quantity of specified items is huge from the start
• Repeating usability problems that could be optimized
• Reimplementing functionalities that aren’t being used

So what’s the suggestion?

A good backlog should focus on the problem, not on the solution.

This means that User Stories should describe problems to be solved, and as they are being sliced, solutions start to emerge. The old system will inevitably serve as a source of inspiration, but ideally this should not even happen.

Another important point is to prioritize the backlog, taking into account the reason why the system is being rebuilt.

Starting from the most problematic or critical module makes the validation of suppositions happen sooner, thus reducing the risks.

SUMMARY:

When rebuilding the system:

• Avoid turning off the old one to then turn on the new. Make them coexist simultaneously!
• Don’t start from functionalities of the old system to describe the new one. The focus should remain on the problems the system is meant to solve.