Trying to explain to a client the architecture of their legacy application is hampering modernisation efforts takes a bit to put into a context that they can understand. I often need to come up with analogies, or stories to help illustrate to the non-technical people the problem. In this situation, the client has a legacy application that was built quickly and was not architected for the growth that it experienced. As they continued to grow, they did not generalise or extract the common functionality.

During a modernisation attempt, this has hindered progress significantly. Below is the story that I used to convey the issue to the non-technical stakeholders.

RGB Paints – A Short Story

RGB Paints (a fictious company with no relation to any real company) is a paint company that started 20 years ago with a simple goal: to make blue paint. They bought a building and set up their equipment on the ground floor. Everything was going well until they saw an opportunity to expand into the green paint market. They decided to add a second floor to their building and install new machines to produce green paint. They were happy with their growth and success.

But then they noticed that red paint was also in high demand. They wanted to capture that market too, so they added a third floor to their building and bought more machines to make red paint. They were proud of their product range and diversity.

However, as time went by, they realized that blue paint was not selling as well as before. They decided to close down the ground floor and focus on the green and red paint. They thought they had made a smart decision to cut costs and optimize their resources.

But a few years later (10 years ago), they changed their mind again. They saw that blue paint was making a comeback and they wanted to get back into that market. They thought they could reuse some of the old machines from the ground floor, but they were too outdated and rusty. So, they built a fourth floor and invested in new machines to make blue paint. They hoped to regain their lost customers and profits.

But they had a big problem. They had neglected to maintain and update their machines over the years. They had taken shortcuts and patches instead of proper solutions. Their machines were noisy, inefficient, and unreliable. Sometimes, they would produce defective paint when the raw materials were not up to standard [invalid inputs] that would cause the manufactured paint to leak out of the windows [leaking PII]. Some kids would catch the paint and use it for graffiti [malicious actors]. RGB Paints was losing money, reputation, and quality.

This is how technical debt works. It is the result of choosing quick and easy solutions over better and more sustainable ones. It may seem like a good idea at first, but it will cost more in the long run. It will create more work and complexity that will slow down the development and innovation. It will compromise the quality and reliability of the product and the user satisfaction. It will require regular refactoring and improvement to reduce the debt and ensure the long-term health of the product. Or in this case, a radical overhaul.

RGB Paints – The Rearchitected Story

RGB Paints has hired an external consultant to aid in modernisation, and the rearchitecting of their application.

The consultant visited RGB Paints’ building and inspected their machines and code. They were shocked by what they saw: four floors of outdated, inefficient, and unreliable equipment, each producing a different colour of paint, but importantly almost all doing the same process(es) with minor differences. They also noticed that the paint was leaking out of the windows and kids were using it to graffiti on the walls.

The consultant interviewed the developers and managers and learned that they had been taking shortcuts and patches for years to meet deadlines and customer demands. They had no coding standards, no automated testing, no code reviews, and no refactoring. They had accumulated a huge amount of technical debt that was slowing them down and hurting their reputation. The developers knew this, and they had attempted in the past to convey this but did not have the right words.

The consultant presented their findings and recommendations to RGB Paints’ executives and directors. They explained that technical debt was the result of choosing quick and easy solutions over better and more sustainable ones. They warned that if they continued this way, they would eventually lose their customers and their market share.

The consultant looked at the overall problem, and identified three short term quick mitigations, and four long term options that will make the overall system better rapidly.

Quick cheap mitigations:

1. Monitor the input standard and validate the raw materials before being used.
   • Deploy a Web Application Firewall.
2. Install security cameras and a video recorder.
   • Deploy event logging and log collection systems.
3. Employee security personnel.
   • Deploy anti-malware and security software onto the hosts.

Long term options:

1. Rebuild from the ground up.
   • Use of the Strangler Fig Pattern to have both the current legacy, and a new modern system operating side by side.
2. Large scale refactoring.
   • A dedicated project where feature development is paused, but the code is improved, updated, and modernised.
3. Small scale refactoring.
   • Find areas of the code that can be quickly refactored.
   • Embed and embrace refactoring as part of the ongoing software development, take a hit to the time to develop new features to prolong the life of the current system.
4. Continue on as now.
   • Do nothing. This is always an option.

Option 1 and Option 2 are where evolution vs revolution of the systems to be changed are discussed with the directors and senior executives. In this instance, Option 1 would also allow for a complete redesign of the overall system, taking the learnings from the past 20 years and applying them to allow for more flexibility and more customisation to the clients. This is a revolution approach. While Option 2 would need to be a more incremental without allowing for major changes in the way that the system is architected, while this is an evolution approach.