Before you rewrite an existing system
To rewrite an existing system takes time, money and effort. The decision should not be taken lightly. A large number of resources (money, man-hours, management) will be poured into the new solution. A fair amount of analysis will also need to be done upfront, with estimates of new hardware requirements, technology costs and the training learning curve that will eat into your developer’s time.
When considering a rewrite, you need to think about your existing codebase (quality, versions and architecture), the software you use (e.g. hosting operating system, database management too) and the obvious time/money/quality equilibrium.
What is legacy code/software?
Defining legacy code/software can be challenging. Here are some of my favourite definitions:
- The code I checked into source control this morning
- Software that is no longer supported by the company that published it (e.g. Windows XP)
- Software or code that has a very limited number of developers in the world that specialise in it and is older than 5 years.
It really boils down to this: is your legacy software holding you back from scaling your business? do you want to grow your business, but don’t have the ability due to constraints?
The maintenance/green fields dilemma
Most developers want to work on new systems. They want new technologies, new challenges and to create something fresh and challenging. Whoever the person is that will need to maintain the solution – well, that is irrelevant. In my experience, I see and hear many developers who leave a company as soon as they are forced into a support role.
Having said that it is challenging for a business to start a project from scratch again. The reason as all the business rules are hardly ever documented. Spending a year in an attempt to get business analysts to assess the solution is also not necessarily viable – especially for small and medium-sized businesses.
As with all things, in business there is a trade-off between quality, time and money. It is often believed that staying with the status quo will be more cost-effective.
The real cost of legacy systems
When I was still working as a fulltime developer, I sat in a meeting where I explained to my (then) boss that the code was a mess and it was just impossible to manage. We also didn’t have unit tests, continuous integration or any means to note if something broke. His response was simple: “Well, it is working”.
I find that software developers cannot always tell the business what is really happening under the hood in the code. Here are some factors to consider and discuss before doing a rewrite – and some to discuss with your tech partner:
- Developer turnover – what is the cost of training new developers on a legacy system? What if your current developers leave?
- Legal implications – what would happen if changes need to be applied or the system fails due to spaghetti code?
- For example, if your code base generates legal documents in different locations. A legal change has to be implemented, but your developers cannot guarantee that all the changes will be implemented in all the locations.
- Financial impact – With the amount of support, inflexibility and constraints, is the legacy software stopping you from expanding your business?
Legacy code has a much bigger impact on a business than we would like to believe.
Complexity and the rewrite
Many business systems are very complex – some with good reason (such as complex financial systems). Other systems tend to be boiler-plated and made more complicated to future proof the system (e.g. dynamic configurability).
When rewriting a system, it makes sense that one would want to have the code as open and as extendible as possible – yet one needs to consider the maintenance, learning curve of new developers and the resources that are wasted by not getting to market quickly enough.
I don't want to rewrite my existing system
Any system will at one time or another become legacy. Your system will need an upgrade at some time in the life of the business. It is also fair that there might not be an opportunity today for the rewrite.
Let us take the following scenario. An MVC (C# .NET) solution was written about 10 years ago. The version of MVC is outdated, it is running on SQL 2000 and contains more than 10 years of business logic and fine-tuning. As a stable system, it makes sense that you don’t want to tinker too much with it.
There are however certain elements that one can change to upgrade the solution incrementally:
- Set a day every week that will be spent on upgrades.
- Consider upgrading the testing servers/database first. The testers will be able to find issues fast here
- Upgrade the packages and linked libraries to the latest versions.
- Have a rule that unit/integration tests be added whenever a bug is fixed.
- Consider extracting the code logic – This could be done in a separate project, into DLL libraries or an external solution in some cases. This will make it easier to rebuild the solution when the time comes.
Keeping software clean and well maintained can assist when the time for a rewrite comes. It also gives the team a sense of pride and accomplishment.
I need a rewrite
When the risk becomes too big, it makes sense to rewrite a legacy system. In this case, it would be prudent to:
- Find a minimum viable product that would cover at least a small business case. Start with this small dial lifting change and then grow your business. Get something out to the client or business as soon as possible.
- After the MVP, focus on the next small feature that will have the biggest impact on the business
- Make sure that the software is well documented – this might not be important right now, but will be exceptionally important later on.
- If the old and new systems can be run in parallel, then do so until the new system fulfils all the requirements.
Not all legacy code needs to be rewritten – and not all systems should be upgraded to the latest versions. We need to understand that there is a risk to keep old code and software as-is in our businesses.
Make sure that the risk will not drive away developers or leave the business cripple once the system falls over due to a vulnerability, exploitation or hack.
When deciding on rewriting your legacy system, start with something small – focus on dial lifting changes that will make a big difference in the company. These should be small chunks/sprints, so that direction can be changed quickly without costing too much.
Keep your pulse on the technology, cost and maintenance.
Enjoy your business.