What is the definition of technical debt?
0
Add a comment
|
4 Answers
The Technical Debt Metaphor is meant to evoke an analogy to Financial Debt.
Financial Debt can be used as a tool to bootstrap a business: you need machines to make money, but you need money to buy machines. You break this catch-22 by taking out a loan to buy machines, and then repaying the loan using the money you gained using the machines.
Technical Debt can be used as a tool to boostrap your understanding of the domain: you need to play around with the software to figure out what it's all about, but you need to know what it's about to write the software. You break this catch-22 by writing the software as best as you can using the partial understanding you have currently, then rewrite the software using the understanding you gained from playing around with it.
Just like Financial Debt, Technical Debt needs to be small, needs to be paid back, and it accumulates interest if it isn't paid back.
It's very important that Technical Debt is a tool for understanding. It is not an excuse for bad code, bad design or bad decicions. It is not about getting a product out of the door.
It is about getting experience. (Note that getting a product out of the door might very well be a prerequisite to getting experience, but it's not what Technical Debt is about.)
Ward Cunningham originally coined the term when he was explaining to his boss why refactoring was important. The software they were working on was financial software, the company was a financial company, the boss was a finance guy, so he used a financial metaphor.
Since you specifically asked about a definition, here's mine:
Technical Debt is the difference between your current understanding of the domain and the understanding that is reflected in the current version of the software.
answered Nov 14, 2010 at 15:14
-
This is the correct answer. Hear it from the guy that coined the term– BkinsCommented Jan 14, 2015 at 0:00
-
@Bkins: IIRC, I had watched that exact video a couple of days prior to writing this answer. Feel free to edit in the link. Commented Jan 14, 2015 at 0:05
-
"It is not about getting a product out of the door." - I think that's the somewhat idealistic view of someone conciously leveraging the benefits. However,in practive from my experience, what you describe is more like prototyping while "technical debt" is something that people rarely realize as such. It's much like financing a new car with those ultra-low rates at the beginning. People see the apparently dirt cheap offer, but ignore the fact that ultimately the full debt has to be paid back, plus interest.– JimmyBCommented Nov 25, 2015 at 11:14
-
Cunningham used the wrong metaphor. "Capitalization is the funding that allows a business to open its doors". This is recorded on balance sheets as an asset, and is depreciated over time. It is not a debt.– user251748Commented Mar 30, 2018 at 18:30
It pretty much means the bad design choices made during software development in order to get a product out of the door.
The idea being that you will "pay the debt" later on and fix the bad design when you have the time.
Wikipedia has a more detailed explanation.
-
To expand on this a bit... The idea is that we can "pay a little now" to design it properly, or "pay more later" to retro-actively fix it (since changing code is generally easier in the design phase than in the support phase). Thus, much like credit debt, it does accrue interest. In the end, more is paid to get something done quickly (like buying something before one can afford it with credit.)– DavidCommented Nov 14, 2010 at 14:45
The original term was coined by Ward Cunningham, and the idea is that if you cut corners in the short term, you’re borrowing against the future maintainability of the software and that at some point, not unlike a credit card, you’ll pay down that debt by going back and fixing the hacky solutions that were put in place.
See the blog post here for more information and how to mitigate it:
Technical debt is the result of trading code quality for something else you deem more important at that moment. It can be going to market fast to get feedback. It can be shipping a vulnerability patch quickly. It can be focusing on doing one (other) thing well.
Technical debt is a conscious tradeoff. It's different from making a mess.
