Whether it’s the catastrophic crash that results in financial losses measured in millions or a simple inability to cost-effectively maintain a legacy platform, the volume of technical debt that DevOps teams are expected to manage is becoming unsustainable.
Much of the application code that has been written over the years is deeply flawed. Misconfigurations of IT infrastructure are commonplace. Vulnerabilities that cybercriminals can easily exploit are found almost everywhere. IT leaders now find themselves forced being forced to choose more often between developing additional applications and fixing legacy IT environments.
Technical debt is something of a necessary evil because organizations often need to cut corners resulting in known bugs that go unfixed so an application can be delivered on time. Application code is often not as thoroughly tested as it should be. In some cases, it turns out what was intended to be a minimally viable product doesn’t scale all that well. Quick fixes needed to improve performance are also frequently undocumented. Inefficient code also winds up consuming more IT infrastructure than required, which adversely impacts everything from cloud cost to the amount of carbon being generated.
As IT teams struggle to maintain an application environment all these deficiencies take a toll. A recent survey of 500 engineering and software development professionals in the U.S. sponsored by Chronosphere, a provider of an observability platform, found engineers spend, on average, more than 10 hours per week attempting to triage and understand a wide range of various types of incidents. That equates to a quarter of a 40-hour workweek being allocated to essentially servicing technical debt. At the current rate organizations are deploying applications it’s apparent there may come a day when organizations are spending more time servicing technical debt than they are building and deploying new applications.
Of course, one of the primary strategies many IT leaders rely on to reduce technical debt is to replace one application with another. The hope is that a new higher quality application deployed, for example, as part of a digital business transformation initiative, will enable an organization to retire one or more problematic applications. Unfortunately, business units tend to embrace change reluctantly so even after a new application is deployed it may be years before an application is finally taken offline. There’s also no guarantee that a new application won’t introduce additional issues so, in the final analysis, that application might only serve to increase the technical debt accrued.
It’s not likely any organization can ever eliminate technical debt completely. Instead, the goal is to manage it. There will always be instances where the better part of valor is to address a known bug after an application is deployed. The issue is remembering to devote resources to fixing those bugs before they collectively overwhelm an IT team. The challenge is there’s always a natural temptation for developers to want to move on the next great project. Ongoing maintenance of legacy applications, no matter how crucial, is for the average developer not all that exciting. In many instances, the developer that may have originally created an application may not even be with the company anymore. Understanding how a code base someone else has written functions is a major undertaking.
It can take weeks to onboard a new developer. Even once they gain an understanding of how an application works it’s rare when anyone stands up and cheers when a bug is fixed. Debugging software is often considered to be the digital equivalent being asked to take out the garbage. It’s necessary but nobody really want to do it. Like it not, however, the need to devote more DevOps resources to fixing legacy applications has become all too apparent. A recent survey of 879 enterprise developers and architects from Vaadin, a provider of framework for building Java applications, finds maintainability is the top-ranked motivation for modernizing Java applications (32%), followed by security (20%) and ongoing maintenance costs (10%.
IT leaders, naturally, don’t typically like to talk much about technical debt. It can result in some uncomfortable conversations with business leaders that have often been led to believe IT operations are operating at peak efficiency. Unfortunately, a technical debt issue that has long been a dirty little secret among IT professionals is approaching a level of crisis that can no longer be ignored as more organizations than ever come to depend more than ever on software to not just automate processes but also actually function as a modern business.
