Top Qs
Timeline
Chat
Perspective

Technical debt

Qualitative description of the cost to maintain a system attributable to its low quality From Wikipedia, the free encyclopedia

Remove ads

Technical debt (also known as design debt[1] or code debt) is a qualitative description of the cost to maintain a system that is attributable to choosing an expedient solution for its development.[2] While an expedited solution can accelerate development in the short term, the resulting low quality may increase future costs if left unresolved.[3] The term is often used in the context of information technology and especially software development.

Technical debt is similar to yet differs significantly from monetary debt. Incurring either generally makes future goals more challenging to attain. But unlike monetary debt, technical debt is often incurred without intention. The choice to minimize development time and cost, an ever-present aspect of business, is the primary factor. Technical debt is generally only assessed retroactively; after a development effort.

Properly managing technical debt is essential for maintaining software quality and long-term sustainability. In some cases, taking on technical debt is a strategic choice to meet immediate goals, such as delivering a proof of concept or a quick release. However, failure to prioritize and address the debt can result in reduced maintainability, increased development costs, and risk to production systems.[4][5]

Technical debt results from design and implementation decisions that may optimize for the short term, but at the expense of future adaptability and maintainability. System aspects that incur technical debt are can be described as a collection of design or implementation constructs that make future changes more costly or impossible, primarily impacting internal system qualities such as maintainability and evolvability.[6]

Remove ads

Origin

The term technical debt was coined by Ward Cunningham in 1992.[7] After reading Metaphors We Live By, Ward devised this debt metaphor to explain to his boss the need to refactor the financial product they were working on.[8][9] He wrote that:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."[10]

Ward Cunningham

Similar concepts had existed before this. In 1980, Manny Lehman had published a similar law using an "architectural metaphor" for the deteriorating nature of software. Manny's Law states that:

"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."[11]

Meir Manny Lehman

Remove ads

Causes

Common causes of technical debt include:

Pressure to minimize development time
An ever-present aspect of business.
Unexpected and ill-defined features and changes
The implementation of last-minute specification changes or changes that are insufficiently documented or tested,[12]:4[13]:22[14]
Gaps in knowledge or skills
May manifest as a lack of process understanding, insufficient knowledge, poor technological leadership, or inadequate mentoring or knowledge sharing practices.[13][13]:17
Issues in the development process
Such as sub-optimal solutions, insufficient requirements (from process inefficiencies), conflicting requirements on parallel branches, deferred refactoring, or delayed upstream contributions.[14][13]:29
Non-compliance with best practice
Such as insufficient software documentation, poor collaboration practices, lack of ownership, rewrites for outsourced software, inadequate attention to code quality, tightly coupled components, lack of a test suite, or failure to align to standards (including ignoring industry standard frameworks).[12][12]:7[13]
Remove ads

Consequences

Summarize
Perspective

By increasing the cost of ongoing maintenance, technical debt makes it harder to predict release schedules. "Interest payments" result from incomplete work and escalating integration costs due to changes in the upstream project. Increases in complexity and the amount of uncompleted work make it increasingly difficult to accurately estimate effort, resulting in delays, missed deadlines, and stress on engineering teams, which can result in higher staff turnover, compounding the problem.[15] Carrying technical debt into production increases the risk of outages, financial losses, and potential legal issues due to breached service-level agreements. Future refactoring becomes riskier and costlier, with modifications to production code introducing greater chances of disruption.[citation needed]

Failure to address technical debt can cause productivity to decline and slow down the delivery of features. The cumulative effects of technical debt result in increasingly fragile systems that can make bold improvements difficult. The domination of incremental changes, along with delays to critical refactoring, can result in stressed systems with inconsistent design, causing users to suffer from degraded performance and limited functionality while developers struggle to maintain quality.[1][16]

Planning

Kenny Rubin uses the following categories to help manage technical debt:[17]

Happened-upon
The development team was unaware it existed until it was exposed during the normal course of performing work on the product. For example, the team is adding a new feature to the product and in doing so it realizes that a work-around had been built into the code years before by someone who has long since departed.
Known
Known to the development team and has been made visible using one of many approaches.
Targeted
Known and has been targeted for servicing by the development team.
Remove ads

Limitations

Summarize
Perspective

The concept of technical debt presumes that an overly-expedient development effort results in additional future costs and that the costs would be avoided if different decisions were made during the effort. While true, other considerations impact the potential cost of expedient development decisions. For example, if the system does not survive long enough to be modified for a subsequent release, then the savings due to the expedient development choices are true savings since there is no future development cost.[18]. Also, future events or advancements may render expedient and "long-term" designs obsolete,[19] Also, new tools and techniques might reduce the cost of future rework, challenging current debt assumptions.[19]

Given the uncertainty of the future, what appears to be technical debt today may ultimately prove to be pure savings. Furthermore, traditional calculations of technical debt tend to focus only on development time, overlooking broader costs such as training and onboarding when debt affects code readability,[20] licensing, tools, and infrastructure needed to manage or resolve the debt,[21] and opportunity costs related to delayed features or lost market opportunities.[21] Without accounting for these factors, technical debt assessments risk oversimplifying complex trade-offs, leading to suboptimal decisions.

Remove ads

See also

Remove ads

References

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads