As we get older as IT people we have all been in a position to work on a system that can easily be categorised as a legacy system. As technical people it is all too easy to get into the slog of working on a system where it takes more and more time to do any changes. Perhaps you have been in the position where you are the only developer with the courage and clout to make changes?
No longer involve engineers to keep the system alive.
In the case that a system is good enough and we do not really need any changes, the obvious strategy is to freeze the system. Avoid any changes at all. We will still be using the system though.
There are obvious risks associated with this strategy. The main benefit of this strategy is that it does not cost the business any money (unless you have security issues associated with the system).
In the case that we can work without a system and the costs exceed what we are willing to pay, then the obvious strategy is to abandon a system. Throw it away. No more development, no more usage.
One reason to decommission is because there is a replacement system.
This case implies that the value the system delivers is less than continued maintenance.
Another very similar approach is to decommission over a longer period of time in order to ease the transition into new system that does not yet fully support all the use cases.
As people who have been involved in developing a system, the choice of 1 or 2 can be a drain. We have spent time together with customers trying to deliver the best system that fits the budget. We have perhaps stayed up late to make sure to help with urgent customer issues and been hailed as heroes? Our hard-won expertise has been deemed unnecessary. Perhaps the fact that we have not been able to get the customer to understand that there is a need for a budget to deal with technical debt has hastened the demise of the system? Developers heavily invested in an old infrastructure, or an old language can have trouble finding a new job. As a customer you might have thought that you have been able to negotiate a good price per feature only to at a much later point get a system that few can touch.
Keep on trucking! Keep paying for maintenance, new features, new or changed requirements.
If we do have some budget for a system and it is kind of small, we easily get into the trap…
This trap is not an uncommon strategy. Doing minimal maintenance but still trying to push new requirements and features.
I’ve been in teams doing this style of development, having a feeling of despair due the fact that we feel that other parties involved are not listening to our fear that it will only become worse (and then blaming it the company that delivers the software).
As a customer, you need to be able to be able to listen to what your technical people are telling you. It could be that it takes months for new developers to get into the code, that there is only a single person that is able to do most of the work…
This strategy implies that it might not be too late to pay off the debt. But don’t be too sure: If the bus factor is 1, you could become forced into another strategy.
A popular choice among developers is to abandon the old code and write it anew. The big rewrite. Throw away the old code and write a new system from scratch. Reading what someone else has written takes time and energy.
This strategy can be unpopular among businesspeople due to the simple fact that it requires time and money. If you have a legacy system, it usually costs about as much to create a new system as it cost to write the initial version of the system.
In some cases, there might not be anything left to salvage, you still need what the system does, so then you are forced into this strategy.
In other cases, we see that this strategy can be used efficiently for small to medium size system components. The main benefit of this is that you then can revisit requirements and evolve the architecture in more radical ways compared to when doing refactoring. It could be that there is no recognisable domain logic or that it is written in a way that makes it hard to read.
But say that there are good parts of a system. We as technical people have done a good job of delivering at least some parts that can be ported into a non-legacy system, then we can apply pick the raisins out of the bread (take the good parts and leave the stale parts): Recycle and adapt. We recycle code and requirements into an updated system.
This kind of strategy can be useful when there is some relatively clean domain logic code, where say the frontend or infrastructure is using outdated technology. See ports and adapters, hexagonal architecture, clean architecture, vertical slice…
In some cases, you can refactor a legacy system into a non-legacy system. This is not always possible. You need engineers skilled enough. You need to verify that it is possible within budget compared to writing it from scratch. It is a difficult and thankless task. I’ve seen this strategy succeed when you have the right team.
As a customer it means that the tempo that you get bug fixes and new requirements takes longer during a transition period. Slowing down to be able to go faster in the long run.
Working together we need to communicate about short term trade offs and long-term implications. If you can identify risks early you can save up money for renovation or replacement.
Oskar Gewalli
När du bokar ett möte med oss kan du förvänta dig:
