What is Technical Debt?


What is Technical Debt?

Technical Debt (also known as Technical Debt or Code Debt) represents the consequences that occur when a development team takes action to speed up the delivery of a feature or project that later needs to be refactored. In other words, it's a result of prioritizing fast delivery over perfect code.

If you've been in the software industry for a while, you've probably heard the term "technical debt." Also known as design debt or code debt, the term (or more precisely the metaphor) is commonly used in technology. This is called a catchall and covers everything from bugs to legacy code to missing documentation. But what exactly is technical debt, and why do we call it that?

Technical Debt is a term first coined by software his engineer Ward Cunningham, who is not only one of his 17 authors of the Agile Manifesto, but is also known as the inventor of the wiki . He first used this metaphor to explain to non-technical people at WyCash why they had to allocate resources for refactoring.

He didn't know it at the time, but he created a new buzzword in the community. It has since been the subject of countless academic studies, debates, and panel discussions.

Years later, Cunningham explains how he first came up with the technical debt metaphor:

"Borrowing money allows you to get something done faster than usual, but you'll still have to pay interest until you pay it back. I thought it was a good idea to borrow money, and I didn't want to throw my software out in the open. I thought it would be a good idea to gain some experience, but of course I'll be back eventually, and I can pay it back by redesigning the program to reflect the experience I'm getting."


Is there a simple definition of technical debt?

The metaphor is abstract in nature, so the true definition of technical debt is up to interpretation. Over the years different people have developed their own personal definitions. Over time, some very differentiated descriptions have developed, but they are high-level.You can see some themes that help create a concrete definition of technical debt. .


it's a tool: 

Technical Debt is often used as a “moving forward” tool, in the same way someone takes out a mortgage on real estate before the price hits a ceiling in order to enter the burgeoning real estate market. Trey Huffine, founder of gitconnected, explains the role of technical debt from a startup perspective. His definition is simple. "Technical Debt is code that is being added now that requires more work to fix later, and is usually intended for quick results."


it has consequences:

Shaun McCormick's definition of technical debt focuses on long-term results. Note that I'm not saying bad (often subjective) or broken code. He suggests that true technical debt is always intentional, not accidental. Gaminer's explanation of what they call the technical debt fallacy focuses heavily on the concept of paying interest later. "Technical debt occurs when you write code and take shortcuts to get where you want to go faster, but at the cost of uglier code and more difficult to maintain." It's like technical debt, so it's called technical debt: you can get more done than you normally would today, but you'll pay higher costs later," they wrote in a Hackernoon article.


it's not a mess:

When trying to define a somewhat abstract concept, it can be helpful to understand what it is not.

Uncle Bob, a longtime software development consultant, wrote in an enthusiastic post: Confusion is just confusion. Determining technical debt is based on the actual project constraints. Risky, but can be beneficial. Choosing to wreak havoc is never rational. It is always based on laziness and unprofessionalism, which may not pay off in the future.Disruption is always a loss. ”

By his definition, taking up technical debt is constantly intentional and strategic. His rationalization helps McCormick's declare that awful code does now no longer qualify as technical debt. Later, whilst we deal with the numerous methods to categorise technical debt, you will see that now no longer each example of technical debt falls into this category.


An Academic Definition for Technical Debt:

With the big selection of opinionated definitions for technical debt, numerous educational works have tried to provide an unbiased, concrete definition for this summary concept. For example, a piece of writing withinside the Information and Software Technology Journal defines technical debt in very unique terms:

“Technical debt describes the effects of software program improvement moves that deliberately or by accident prioritize customer fee and/or venture constraints including transport deadlines, over greater technical implementation, and layout considerations…”

The identical article expands at the metaphor for technical debt, “Conceptually, technical debt is an analog of economic debt, with related ideas including degrees of debt, debt accrual over the years and its possibly effects, and the strain to pay returned the debt in some unspecified time in the future in time.”


Are There differing kinds of Technical Debt?

For as several definitions of technical debt that there ar out there, there ar even as many sorts of technical debt. For years, package development practitioners have wanted new ways that to classify and communicate technical debt.

In 2007, Steve McConnell steered that there ar a pair of styles of technical debt: intentional and unintentional. consistent with him, intentional technical debt is technical debt that one takes on consciously as a strategic tool. As hostile unintentional debt, that he calls “the non-strategic results of doing a poor job.”

A few years later, Martin Fowler took McConnell’s thought a step more and printed what he calls the “Technical Debt Quadrant.” This quadrant tries to categorise technical debt into four classes supported each intent and context. Fowler says technical debt is classified primarily based initial on intent: is it deliberate or inadvertent? then even more distinguished by whether or not it's prudent or reckless debt.