Technical debt accrues just like financial debt, and with similar long-term consequences

It’s all too commonplace. Facing a deadline or a budget crunch, organizations make decisions regarding their technology projects to meet one or the other – or both. Often, these decisions save on one resource now at the expense of another later. More often, the impact down the line ends up being greater, syphoning off more time, slowing down progress, and sacrificing quality.  

This concept is known as technical debt, and it accrues much like financial debt. A recent study by financial services firm, Stripe, estimates that developers spend up to 13.5 hours each week addressing technical debt and bad code. The impact? A $3 trillion blow to the Global GDP. Why? Because as technical debt grows, it becomes increasingly harder to manage, stalling and sometimes overwhelming development teams and causing projects to come to a screeching halt.

In other words, not too dissimilar to that one time the credit card balance got out of hand.

How Does it Accrue?

Like financial debt, technical debt also builds interest. Throughout the development process, poor quality code, antiquated architecture, subpar infrastructure, and inefficient development processes can all be contributing factors.

Low quality code pushed for the sake of saving time will accrue technical debt, as updates and patches could lead to a very costly and ongoing operations and maintenance period where core functionality could shut down completely. Aptly named “spaghetti code,” bad code that affects and is attached to other underlaying code can quickly create a maintenance nightmare, snowballing with every iteration, update, or patch, making that quick code push to save time or budget an unmanageable and unwieldy mess later on.  

Nearsightedness with coding decisions is another factor. Code that is written without consideration for scalability and the life of the application or solution will almost always need to be rewritten as more features and functionality are introduced. New evolving technology and emerging best practices also need to be taken into account to ensure long term compatibility with your project.

Obsolete architecture and weak infrastructure should also be taken into consideration. If support is dropped for a framework or package you are using, it could lead to vulnerabilities and force an entire project rewrite. Unplanned lag spikes or even down time in applications could put you further behind on your project timeline. Servers could no longer have support or updates and ultimately create a security risk allowing for the infiltration of hackers and loss of data and business continuity. IT resources, who spend all their time managing legacy systems, are unable to research and update to a more performant system. The list goes on.

What Can I do about it?

One of Cynerge’s favorite strategies is promoting Agile development methodologies supported by DevOps processes. Since Agile relies on short bursts of productivity (sprints), keeping an incremental eye on compounding interest becomes that much easier. With daily standups and constant communication between team members for addressing issues, technical debt can be better managed. Following each sprint is a retrospective, discussing problems and ways to improve in the future, which could also be used to address any identified technical debt. 

Using DevOps processes means leveraging automation, running automated tests for vulnerabilities, ADA/Section 508 compliance, and unit testing, to free time to address technical debt in the future. Project managers can even set a code coverage threshold to automate the amount of unit tests that are considered acceptable to the team. Dedicating time to build these pipelines can seem excessive initially, but once up and running, are far more efficient, reusable, and effective than manual deployments. In other words, a great way to reduce technical debt is to keep reusing what you know works and by not cutting those same corners (investing time now to save later) that introduced technical debt in the first place.

At Cynerge, we allow containers to do a lot of the heavy lifting. Containers hold application code, the core operating system, language, and all associated modules in a lightweight and transferable package. The initial time investment of building a container is offset in the event of any necessary changes in business requirements which would force a change in any aspect of the infrastructure. Containers also allow new developers a rapid way to get the current application installed and running on their machines, leading to less down time and quicker onboarding.

Considering a SaaS (Software as a Service) product or a third-party solution can also help alleviate technical debt. Purchasing a prebuilt and readily available solution may be pricier initially but could pay for itself in speed to market or by reducing the total footprint of the project. SaaS solutions are typically more robust, offer more support, and should offer long term support. 

Next Steps

At Cynerge, we start by diagnosing the problem after closely analyzing the code and infrastructure. Our business analysts often begin with stakeholder interviews, allowing us to understand the “why” behind an organization’s decision-making and to make recommendations for a better path forward.  

While there are many different ways to manage technical debt, based on the source, a thorough assessment of your business practices to identify the root of any technical debt is a good first step. Then, with the source identified, we can select the best path forward, whether it’s a cloud-based infrastructure, automation of development processes, or choosing a more incremental and iterative approach to development projects.