Technical Debt in Software Development

Dr. Luddy Harrison | Tue Mar 29 2022

What is technical debt?

When software systems are developed by writing lines of code, and by using libraries, platforms and third-party dependencies, the system will have a tendency to become more and more complex over time. Often, if the developers aren’t able to make time to properly maintain the architecture of the application, or the system, and keeping its underlying structure in good shape, then technical debt accumulates.

Technical debt basically means how much effort it will take to untangle from all of the compromises that we’ve made along the way in developing this system, in the interest of simply getting things done – meeting release deadlines. So technical debt is really an accumulated compromise in the structural integrity and architecture of a software system. And mostly, this comes down to a problem of volume.

That is to say, a small program, by its nature, won’t suffer too much from technical debt, because one can always stop and reorganize that program fairly easily, just because it’s not so voluminous. But in big software systems, which may comprise hundreds of thousands or even millions of lines of code, and that are built over a long period of time, technical debt is a real issue. It’s also a problem that’s compounded by developer turnover. Such as, not only has the system evolved over time in ways that have compromised its structural integrity, but also the original people who designed that system had left. So it may be that the current developers of the system aren’t even aware of its original architectural design intent, while the original developers may fully know where the architecture wasn’t structured properly to deal with the features later added. So, one may often find in software systems that exist over a long period of time, and especially systems that come under a lot of time pressure for release, this accumulated technical debt.

What’s the connection to low-code environments?

The main reason is the same – volume. It’s the same property that causes technical debt to be a bad problem. When you write lines of source code, this property is prominent as it were in a local environment. It’s just reduced radically by the sheer volume of what’s needed to represent that program. The idea is that if you use a graphical representation that has high-level properties, and the relationships and connections of the application, when expressed effectively, then a lot of detailed logic doesn’t need to be coded in lines of conventional source code. Then you have effectively a small program again, at least relative to the very big system that it’s replacing. Therefore, this greatly reduces stopping and re-architecting the system. The work is a lot less daunting.

Why are low-code environments potentially a solution for this problem?

In the case of a system like Coreograph, there are some additional advantages that really help in addressing technical debt. And those advantages are different forms of readily available programming, restructuring and refactoring that make it a less radical transformation to remedy a program suffering from technical debt – one where its architecture has maybe been overwhelmed by the features that have been added to it.

One of the principles of Coreograph for AWS is that the basic unit of executable logic (a piece of function or program) is a computation from HTTP request to HTTP response. Based on this fundamental purpose, Coreograph is about building APIs.

An application in the cloud is typically an aggregation of APIs in different shapes and sizes – no matter if running on serverless platforms or on long-running servers. They are typically combined together to make the whole application. But with Coreograph, it’s very easy to pick up these pieces of HTTP processing and plug them from one executable environment, such as Lambda, into a different executable environment, like EC2, without having to disturb that underlying computation. So that you can manipulate the architecture of your application to structure the application directly. So as an operator, you can go about your business of fixing technical debt directly, without being overwhelmed by all the incidental, very detailed source code changes that are typically required to remedy significant technical debt.