“The second vice is lying, and the first is running in debt.” Benjamin Franklin, The Way to Wealth

While no organization wants to run into debts, lack of foresight, poor coding practices, and equally poor-quality code, patchwork, existing legacy architecture and increasing pressure to remain competitive means that unerringly they end up in the black hole of tech debt.

According to American programmer Ward Cunningham, “Accumulating technical debt is similar to the accumulation of monetary debt. It simply escalates if you do not act in time.”

What Causes Tech Debt?

Even today, many organizations are still relying on applications that were written several decades ago. There is no question that these have become obsolete. The application’s lifecycle has run its course and both from a technology perspective as well as from a business perspective where the organization must assimilate dynamically fluctuating business needs, the application’s utility, or its ability to match pace with changing needs has eroded. However, as the cost of migrating to the tech stack is extremely prohibitive, and because there is a chronic shortage of skills required for implementing that migration, organizations have stayed manifested with redundant tech stacks. To make matters worse, employees who had knowledge about the intricacies of the platform are either leaving or retiring and so over a period of time organizations have fewer and fewer people to understand what is was going on. They were also operating on very limited information.

How does Tech Debt Build Up?

Two industry examples to illustrate how tech debt builds up to the point of crashing application or making any new feature or value addition prohibitive

1. A large commercial bank involved in payments had hardcoded some counters which are affected by the volume of payments transactions going through. Typically, during times of uncertainty or upheaval such as an election where the incumbent could get defeated or let’s suppose a scenario such as the one that happened in Great Britain where a sudden shock announcement of a mini-budget sent the economy into a tailspin and the currency crashing, resulting in a lot of payment transfers, a tech debt build-up due to some variables hardcoded in the system, could cause the system to crash as it is unable to handle the increased workload. In the process, people will not be able to transfer money to meet the liquidity or safety requirements.
2. While some technical debt is manageable, as perfection even in the technology realm is near impossible, the accumulated weight of maintenance costs when things do not work as planned can be a constraint as observed in the case of a prominent insurance company. The company was utilizing an extremely old and archaic policy administration platform for processing. Problems cropped up every time the insurer came up with a new insurance product or feature addition primarily because the product was managed on the archaic administrative platform. As the platform was saddled with tons of tech debt, extensive changes had to be made every time a new product or new features were added making it an unsustainable exercise.

Tech Debt more than a Manifestation of an Engineering Problem – A Pictorial Depiction

Primarily a manifestation of an engineering problem, but there’s a cultural angle to it as well as multiple teams and stakeholders are involved often holding diametrically opposite views in the decision-making process. Technical debt arises when a project takes much longer than expected to ship. That is to say, it metamorphizes from a sound-looking plan on paper to a source of never-ending expenditure (a black hole of spend), with project delivery nowhere in sight.

So, here’s a question for you. Can you spot how one can end up accumulating technical debt taking cues from the illustration (courtesy: vincentdnl) below?

Clearly, there is a dissonance between what is expected and the end result.

• The leaky roof cannot be just patched up. That’s an example of poor engineering strategy. A band-aid or patchwork approach is only useful in the initial stages, when projects scale, it is simply not enough.
• Someone has clearly not paid attention to the foundation. Alignment problems exist. (In software it translates into code defects) In software it translates into code defects. Not enough attention is paid to the testing of code, and inconsistencies, bugs, and legacy code defects have spiraled into a humongous never-ending problem.
• There are pillars but clearly not functional.
• There is an obvious lack of responsibility and poor technical stewardship. The pressure of early release has resulted in quick fix testing.
• The team has been using a band-aid or patchwork approach to getting the work done.
• We also think that the definition of “done” is clearly not understood or ambiguous. Standards evidently do not exist.
• End result: Delayed timelines, Spiraling costs, technical debt Black Hole

Reasons for Tech Debt

1. Technical debt is generally thought of as an application code problem. Sometimes either deliberately or inadvertently, some gaps are either introduced or allowed to remain as is as it is more important to release a product than make it picture perfect. If the underlying code issues are not addressed in time, teams could end up confronting a “code smell” which is a signal that things would have to be worked all over again.
2. Documentation debt: This is yet another significant yet underestimated cause of technical debt. This occurs when teams create code but forget to pay attention to supporting internal documentation, such as code comments that explain how the program works and what was the intent behind it. Also, code comments should be in a form that dispels confusion instead of creating new ones. There are long-term repercussions and costs arising due to poor documentation. Each new member would have to start all over again in the absence of proper documentation.
3. With new age born-in-the-cloud institutions like Monzo, Starling, Robinhood, etc., giving stiff competition to the bigger players there is increasing pressure to revamp the crumbling legacy architecture and give it a new look by hosting their legacy applications in the cloud. However, if you simply rehost the application on the cloud as-is without considering other factors that might affect its performance and functionality you might end up with elevated costs and significant operational issues.

Our Magic FinServ’s Accelerator to the Rescue

We understand the complexities of the Fintech and the Capital Markets business and have a thorough understanding of the current scenario. We go through source code and whatever limited documentation is available to understand what is happening and the gaps that exist therein.

Our strength happens to be our very strong QA automation practice. And of the key aspects of QA automation practice is to follow the functional feature from start to end.

• Adopting an Agile Approach to and following a continuous cycle through design, coding, testing, and analysis.
• Catching the bugs early with automated regression tests whenever the code is altered
• Introducing test automation incrementally through the development cycle.
• Having room for quick ramp-ups

We can use all these techniques to understand what is happening.

We can take care of documentation debt and once it has been identified and is under resolution, we then take care of tech debt.

We also take care of technical debt, for instance by building code on microservices. Microservices are ideal for developing, testing, deploying, and updating services independently, resulting in faster deployment.

Replacing front-end UI/UX modules with better UI/UX modules using microservices and connecting it to the backend platform using APIs.

Gartner has defined three application categories, or “layers,” to distinguish application types and help organizations develop more-appropriate strategies for each: Systems of Record, Systems of Differentiation, and Systems of Innovation. This is ideal for applying what to retain or which is most valuable in the existing application, and simultaneously carving out and replacing things that add to the tech debt by replacing it with microservices and connecting to APIs.

Conclusion:

Technical debt is more than house cleaning. It causes damage in more ways than one. It demotivates teams, creates chaos, and most importantly slows down the modernization process. The best way to deal with it is to quickly underwrite a strategy to cut technical debt costs before a stink is raised. For more on how we can help, write to us at mail@magicfinserv.com.