What Is Technical Debt? Examples for Managing Technical Debt

Technical debt, or determining how to manage technical debt in scrum, is a phenomenon and challenge usually encountered in and associated with agile software development. That said, the term is not always fully understood by business owners and stakeholders. For example, one study (6) found that 75% of their respondents initially indicated that they were not familiar with the term “technical debt.” 

The above-mentioned term, technical debt (aka: tech debt), in software refers to the problems that naturally arise when structural elements of an evolving codebase are left unaddressed—exponentially leading to an unsustainable buildup of increased operation and maintenance costs.  

While “tech debt” is commonplace in agile software engineering environments, the term, and its worrying implications (if ignored), is equally important to define in the construction industry—for the construction technologists overseeing the development of a company’s tech stack, to the inventory managers keen to solve their data bloat problems, to the business owners looking to stay lean in order to provide a better value chain to their customers.  

In a previous article, digital product manager Liz Haagensen drew the parallels between agile software methodology and lean construction. In this article, we take that observation a level deeper: Contextualizing an agile term, technical debt, for the construction industry, as well as outlining the technical challenges construction companies may face and how to manage technical debt. 

Jump Ahead:

The term ‘technical debt’ was first coined by Ward Cunningham, “when he described the phenomenon of meeting a release deadline by making adaptations and concessions in a product,” or so summarizes a 2016 review of the related scholarly literature presented by researchers in Information and Software Technology (4).  

Gartner defines technical debt as “accrued work that is ‘owed’ to an IT system, and it is a normal and unavoidable side effect of software engineering.”  

Technical debt, they add, refers to the “short cuts [or] workarounds [used] to meet delivery deadlines,” which “eventually cause the software to deviate from its prescribed nonfunctional requirements, and in the long-term[…] impact performance, scalability, resilience or similar characteristics of the system.”  

Describing technical debt to me, Robert LaCosse, a Senior User Experience (UX) Design Researcher at Milwaukee Tool, notes “In the most convenient metaphor we have, technical debt is painting yourself into a corner.” “Technical debt,” he explains, “refers to putting software solutions or potentially even hardware solutions into deployment that then create dependency on those solutions.”   

“If you’re stacking solutions, you might get into a situation where something big changes and you find yourself having to work back to your foundation to potentially overhaul major pieces of your digital environment,” LaCosse expounds. “And that has a cascading effect throughout your digital or even hardware ecosystem that causes a massive cost in retooling.” 

How It Applies to Construction:  

Technical debt in the construction industry could refer to literal software technical debt—e.g., the increasingly complicated software systems and manpower needed to maintain them (or replace them). At the same rate, technical debt of a construction company may refer to growing process inefficiencies when working alongside subcontractors, various specialty trades, and customers. 

McKinsey estimates (2) that tech-debt principal accounts for up to 40% of IT balance sheets, while most companies pay more than 10% interest on projects: i.e., if “tech equity” (net contribution of all technology to enterprise value represents 60-80% of a company’s total asserts, tech debt represents the remaining 20-40%.  

What’s more, nearly 70% of respondents reported they are using more than 10% of the new project spend to resolve tech debt. 

Infographic Credit: McKinsey Digital 

A 2022 article from McKinsey Digital (1) estimated the cost of tech debt to account for anywhere from 15% to 60% of every dollar spent on IT. The same study estimated that a company with 1,000 systems and applications together generate over $2 billion in tech-debt costs. 

In a conference paper delivered at the Proceedings of the 2015 10th Joint Meeting of Foundations of Software Engineering (3), 61% of respondents agreed that technical debt is strategically used to support business objects – respondents, furthermore, knew that tech debt existed, yet 66% didn’t pay down the debt or pay it down only when it became a roadblock.  

Further, a whitepaper from CodeSense cites multiple studies which estimate technical debt accounting for 23-42% of their development time. What’s worse, high-paid software engineers estimate that 33% of their time is spent dealing with technical debt, not building new features. 

How These Concerns Apply to Construction:  

The construction industry has a lot of work to do to upgrade legacy software systems, improve collaboration, and maintain visibility to jobsites. Consider, for example, the 2021 ConTech Report published by JBKnowledge (9).  

At that time, 42% of surveyed construction companies were not billing IT expenditures, with 44% lacking a dedicated IT department. Aside from the cybersecurity implications with the rising threat of ransomware targeting construction companies, the growing tech debt in the construction industry is worrying.  

Consider, further, that 21.4% reported using 3 mobile construction apps, while 23.6% of these companies reported using apps that don’t integrate whatsoever. Further, 51.3% of those respondents who transfer data when apps don’t integrate do so manually, introducing the likelihood of human error in data management. 

In almost 75% of technical debt instances, respondents believed the origins lie in legacy software (4).  

LaCosse tends to agree with these systems presenting an issue. “Banking software,” he offers as an example, “has traditionally been very slow to change because the dependencies built around it are numerous and nobody wants downtime in banking software,” he explains, quipping, “Downtime is quite literally money in banking software.”  

Closer to home in the construction industry, software technical debt for a construction company “Yeah, technical data at a construction company looks like heritage systems,” LaCosse explains.  “In some cases, these systems might date back to say like the late 80s or mid 90s.” 

That’s why integrated platforming over siloed heritage systems is so critical. In fact, project-level software concerns and disorganization as well as miscommunication in inventory control can lead to costly downtime in construction projects. 

Respondents from JBKnowledge’s ConTech Report (9), furthermore, voiced the need for integration and building toward interoperability:  

• “[I wish I could improve the company I work at with] communication between software systems. Integration would save so much time for our office staff!”
• “Seamless integration from pre-con to boots on the ground [would improve our processes].” 

One area of construction where businesses may accrue a significant amount of technical debt, LaCosse explains, is inventory—hence why an agile, cloud-based ecosystem is key: 

“In terms of inventorying, it’s easy to become complacent. It’s easy to say, ‘If it ain’t broken, don’t fix it.’ But software yields a competitive advantage. Yes, new software generally comes with slightly more complexity out of the gates: You have to learn the new system, you have to learn how to integrate it. But software powers your ability to scale through organization. This could be organizing tool location, tool count, ordering processes. And then, potentially, arriving at a point in history where software yields a predictive capability, so it’s no longer just streamlining the connection of point A to point B, and it’s no longer just about that in real time; it’s about getting ahead of the mark to anticipate and thereby optimize around your future business needs. Being cognizant of what technical debt means and how technical debt may slow down your business writ large is a key step in this evolutionary path. What if you were able to reasonably predict a need, say, a 50 pack of drills or drivers three months ahead of time? I mean, can you guarantee that the hardware store down the road has 50 drills on hand to purchase at any given time?” 

• In 2012, they presented a conference paper at the 6th European Conference on Software Architecture on the topic (8). They discussed how paradoxical costs associated with focusing short-term gains can “ultimately degrade the flow of value over time.” They contend that an “architecture-focused and measurement-based approach” is key to developing “a metric that assists in strategically managing technical debt.” The conference presentation was later awarded Most Influential Paper by the International Conference on Software Architecture (ICSA). 
• In a 2015 conference presentation for the 10th joint meeting of foundations of software engineering, researchers (3) worryingly found that 65% of respondents had no defined technical debt management practice, while the remaining respondents (25%) managed it at the team-level with no explicit standard approach for managing technical debt organization-wide.  
• A 10-year reflective look back on this topic in a blogpost (7) and a book project (5) look to educate business owners how to accelerate innovation in “existing systems, or build new systems that will be easier to maintain and evolve” through eliminating, reducing, and mitigating technical debt.  

LaCosse believes software retrospectives are key to any organization’s evolution—similar to how a project manager wrapping a construction project may lead a debriefing. 

“You could look at practicing good hygiene, which means doing retrospectives.” In scrum, LaCosse explains, a retrospective is the practice, post-deployment of a software release, of the team getting together to “reflect on the work that was done recently and by that process, the team gets more efficient over time – because the retrospectives are repeated throughout an agile sprint process.” 

“Retrospectives can also be done with larger entities or larger ecosystems,” he adds. “It can focus potentially on what solutions were implemented and then with a multidisciplinary panel, you can identify what the pluses and deltas of that implementation are with certain conversational tools and implement a process whereby all stakeholders or, more importantly, all disciplines have the ability to voice what they believe or know to be benefits and threats of any given implementation.” 

Software technical debt is a growing challenge of the construction industry as owners look to digitize their processes and address growing industry-wide labor shortages.  

To plan for and address technical debt in a construction company, owners should look to:  

• Streamline:  
  • Adopting design-build processes to simplify project pipelines.  
  • Adopting lean construction principles to minimize waste, remove impediments, and defining a clear value chain for customers.  

• Improve Communication and Collaboration:  
  • Take advantage of software integrations, like asset management and BIM, and real-time communication platforms to enable a clear flow of information from the back office to the field. 
  • Build rituals between key stakeholders to ensure proper handoffs and limit rework.  

References 

1. Blumberg, S, Das, R, Lansing, J,  Motsch, N, Münstermann, B and Patenge, R (2022, 06). Demystifying digital dark matter: A new standard to tame technical debt. McKinsey Digital. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/demystifying-digital-dark-matter-a-new-standard-to-tame-technical-debt  
2. Dalal, V, Krishnakanthan, K, Münstermann, B, and Patenge, R. (2020, 10). Tech debt: Reclaiming tech equity. McKinsey Digital. https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity  
3. Ernst, N,  Bellomo, S, Ozkaya, I, Nord, R, and Gorton, I. (2015, 08). Measure it? Manage it? Ignore It? Software practitioners and technical debt. [Conference presentation]. Proceedings of the 2015 10th Joint Meeting of Foundations of Software Engineering, 50-60. http://dx.doi.org/10.1145/2786805.2786848  
4. Holvitie, J. et al (2016, 04). Technical debt and agile software development practices and processes: An industry practitioner survey. Information and Software Technology (96), 141-160, https://doi.org/10.1016/j.infsof.2017.11.015  
5. Kruchten, K, Nord, R, and Ozkaya, I. (2019, 04). Managing technical debt: Reducing friction in software development. Addison-Wesley Professional. https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=546594  
6. Lin, E., Taksande, N, and Seaman, C. (2012, 11-12). A balancing act: What software practitioners have to say about technical debt. IEEE Software (29, 6), 22-27, https://ieeexplore.ieee.org/abstract/document/6280547/  
7. Nord, R and Ozkaya, I. (2022, 08). 10 years of research in technical debt and an agenda for the future. Software Engineering Institute of Carnegie Mellon University. [Blogpost]. Retrieved from https://insights.sei.cmu.edu/blog/10-years-of-research-in-technical-debt-and-an-agenda-for-the-future/  
8. Nord, R Ozkaya, I, Kruchten, P, Gonzalez-Rojas, M (2012, 08). In search of a metric for managing architectural technical debt. [Conference presentation]. Institute of Electrical and Electronics Engineers. https://doi.org/10.1109/WICSA-ECSA.212.17  
9. JBKnowledge. (2021). Contech Report. https://contechreport.com