A report published by OutSystems revealed that 69% of IT leaders found that technical debt fundamentally limits their ability to innovate. In addition, 61% stated that it negatively affects their organization’s performance, and 64% believe that technical debt will continue to have a substantial impact in the future. The report further explained that, in some cases, organizations may benefit more from investing in decreasing technical debt rather than innovation.
But what do you do when 80% of each dollar spent on your application budget goes to keeping the lights on? Certainly, maintenance, firefighting, and root cause analysis don’t usually fall into the “innovation” category. What kinds of technical debt contributes to a draw on company resources, and what can be done about it?
The History Behind the Term Technical Debt
Ward Cunningham, one of the Manifesto for Agile Software Development coauthors and the developer of the first wiki, once suggested that some issues in code resemble financial debt. The analogy is that it’s okay to borrow against your future if you’re ready and willing to pay that debt when it’s due.
The term “technical debt” sounds more like a financial term than a programming theory for a reason. While developing a financial application in the Smalltalk-80 language, Cunningham used the financial analogy to justify refactoring to his boss.
Some people continue to dispute the precise connotation Cunningham intended to convey: Is it okay to incur technical debt or best not to? At its core, Cunningham’s story identifies a crucial problem faced by many software teams.
Specific critical tasks such as refactoring and making improvements to the code and its architecture are delayed to meet deliverables and deadlines. However, these coding tasks must be completed eventually, resulting in cumulative technical debt. Before development teams know it, they’re overworked and burned out from trying to pay off all the technical debt they’ve incurred over time.
The True Cost of Technical Debt
Have you ever truly contemplated the cost of technical debt? By now, you likely realize that your technical debt is costing your team more over the long term than the perceived benefits of delaying paying off the debt. However, since technical debt isn’t as tangible as monetary debt, you might wonder how and where one begins to estimate its cost.
To understand why technical debt is so easy to ignore, one must understand why people pay tens of thousands of dollars in interest throughout their life rather than saving and paying cash.
CNBC Select looked at the amount of interest the average American paid on loans taken out throughout their lifetime. Its report found that when including a student loan, a used car payment, a single credit card balance, and a mortgage on a median-priced home, they paid on average $164,000 over their lifetime.
With so much hard-earned money going towards paying off interest, one would think that more people would resist taking financial “shortcuts.” But similarly to consumers who accept paying thousands of dollars in interest as a reasonable shortcut, IT professionals often disregard technical debt for an end goal that seems like a good idea — until they’re forced to repay it in interest.
For many borrowers, being able to possess that item now is more important than what they could gain over time by saving and paying cash. This is analogous to the way many IT professionals feel when they focus on getting software into production sooner without fully considering the technical debt accruing. Rather than methodically ensuring all past issues are resolved, they move forward to complete a new goal, leaving problems in their wake that, sooner or later, must be addressed.
An application’s budget for maintaining accumulated technical debt could be upwards of 87%. That leaves only 13% of its budget going towards innovation. Furthermore, aging frameworks represent a security risk while they contribute to the cost of technical debt. That makes keeping the lights on even harder.
Related: How Dynamic Logging Saves Strain on Developers and Your Wallet
The Many Faces of Technical Debt
Classifying technical debt will by no means suddenly make it simple and easy to handle. But the classification process focuses development teams and enables them to have more productive conversations.
Technical debt will always be a significant part of DevOps and how to effectively manage this debt should be regularly taught to both students pursuing a career in the field and those with years of experience. It’s also essential to constantly evaluate where and how technical debt is hindering your team.
Once you’ve identified these factors, it will be easier to increase overall productivity and deliver features in a timely fashion. While there are many types of technical debt, below are four examples of the types of technical debt many developers will encounter in their work.
1. Unavoidable Technical Debt
Organizational change and technological advancement are the primary sources of unavoidable technical debt. It usually occurs when scope modifications are solicited mid-project, followed by the immediate cost of those modifications.
An example could be adding a new feature to a legacy system to better support mobile systems. In other words, unavoidable technical debt is inevitably generated as new organizational requirements or advances in technology cause a systems code to become obsolete.
2. Software Entropy or Bit-Rot
Software entropy or bit-rot happens over the course of an application’s lifespan as the quality of software gradually degenerates. It eventually leads to usability issues such as errors or necessitates frequent updates.
Software entropy also occurs if numerous developers make cumulative modifications that increase a software’s complexity over time. Their changes may also slowly damage the code or violate non-functional requirements such as accessibility, data integrity, security (cyber and physical), privacy (compliance with privacy laws), and a long list of others. Refactoring is generally the solution for software entropy.
3. Poor-Quality Software Code
Agile software development depends on diminishing the scope of a release to guarantee high-quality code rather than prioritizing speed or release. By doing the latter, technical debt is passively generated when the scrum team discovers and tries to solve an issue. The number of times this process is repeated causes the cost of technical debt to increase, resulting in decreased efficiency and productivity as development teams repay their analogical debts.
Technical debt comes in the form of unnecessarily complicated, unreliable, or otherwise convoluted code. No code is perfect, but when it’s saddled with excessive technical debt, it can become a bigger problem than the issue it was designed to resolve.
The more technical debt found in a piece of code, the farther from the intended goal it becomes; The farther from the intended goal it becomes, the longer it will take to iron out the kinks.
Extemporaneous or absent developer onboarding and training, as well as insufficient coding criteria for developers, contribute to poor-quality software code as well. Additionally, having to rewrite outsourced code or poor scheduling adds extra stress to an already demanding job. These examples tend to increase the cost of technical debt exponentially compared to other instances and are common contributors to developer burnout.
4. Poor IT Leadership
Poor IT leadership is another major contributor to the cost of technical debt, as well as many of the consequences mentioned before. It materializes in various ways, with many IT managers either unaware or in denial of the problem.
Micromanagement is a perfect example of a leadership style that contributes to varying degrees of technical debt. While it usually works great for small-scale projects, micromanagement causes leaders to develop tunnel vision. Before long, they’ve lost sight of the bigger picture and begun to rub their team the wrong way. All sorts of complications arise from these types of toxic environments. The resulting technical debt only compounds matters.
IT managers contribute to technical debt by not listening, considering, or implementing feedback from their team or scheduling sufficient time in each release to address historical debt issues. By ignoring others merely because they view them as subordinates, errors are overlooked.
In addition to that, cloud and containerization trends evolve at a rapid pace, often bypassing the understanding of both end users and IT management teams. Nevertheless, some organizations don’t want to risk appearing unknowledgeable and thus make poor decisions or adopt unnecessary tools that complicate things.
Related: Monoliths to Microservices: 4 Modernization Best Practices
How Technical Debt Affects the Customer Experience
It’s important to remember that technical debt isn’t merely about short-term and long-term deficits. Depending on how much debt was left in an application, system performance can be drastically affected. When it’s time to scale up or add new features to a debt-laden IT infrastructure, the customer experience suffers.
For example, according to CNBC, online spending on Black Friday increased by nearly 22% in 2020 due to the COVID-19 pandemic restrictions. Many brick-and-mortar retailers scrambled to establish a competitive online presence. As a result, technical-debt-related issues such as website lagging, outages, and glitches plagued even major retailers.
Imagine the embarrassment of receiving complaints from customers about items vanishing from their carts at checkout. Worse yet, imagine losing tens of thousands of dollars to competitors during a lengthy crash.
The COVID-19 pandemic has forever changed how consumers interact with organizations. More crucially, the dynamic has shifted dramatically, with consumers having the power of countless choices.
Along with that, digital technology makes it easier for consumers to express their concerns about poor service experiences, posing more challenges than ever before but increasing awareness of a company’s weak areas.
According to The Wall Street Journal, “Some 66% of consumers surveyed in 2020 said they had experienced a problem with a product or service, up from 56% in 2017, when the survey was last conducted. Further, Gartner posits that an “effortless experience” is the key to loyal customers.
If your customers make it to the customer service stage to express their complaints, regardless of whether it’s with a product or an inefficient, glitchy platform, you may be too late. If they don’t, you may be a step ahead of your competition. Ultimately, the cost of technical debt can be much greater than you think addressing it should be a top priority for your company.
Don’t Allow Technical Debt To Drag Your Team Down
Senior developers find it difficult to illustrate the overall impact technical debt has on an organization’s bottom line to nontechnical executives and investors. Unlike financial debt, technical debt is a lot less visible, allowing people to disregard its impact more easily. When determining whether technical debt is worth it or not, context matters.
By employing the vFunction Platform, AI and data-driven analysis facilitates, accelerates, and focuses most manual efforts and does much of the heavy lifting. This saves architects and development teams from spending thousands of hours manually examining diminutive fragments of code and struggling to identify and let alone extract domain-specific microservices. Instead, they can now focus on refining a reference architecture based on a proper “bird’s eye” view. Contact us for a demo today and start properly managing your company’s technical debt.
