Technical debt is an important fundamental concept in the software engineering world, mainly because it pops up quite often in most real-world software projects. As much as I’d like to put the concept in my own words and sprinkle some personal experiences on it, Steve McConnell already wrote two good posts on the topic last year.
The term “technical debt” was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.
Ward didn’t develop the metaphor in very much depth. The few other people who have discussed technical debt seem to use the metaphor mainly to communicate the concept to technical staff. I agree that it’s a useful metaphor for communicating with technical staff, but I’m more interested in the metaphor’s incredibly rich ability to explain a critical technical concept to non-technical project stakeholders.
Technical Debt and Technical Debt Decision Making [from 10x Software Development]
[…] By rushing the project, you create a lot more defects on the way, not to mention that you unnecessarily stress out your team. It is quite common to see the scenario above end up taking 4 or 5 months to finish because of the extra effort needed to deal with the problems caused by rushing. In other words, a bad case of Technical Debt. […]
[…] By rushing the project, you create a lot more defects on the way, not to mention that you unnecessarily stress out your team. It is quite common to see the scenario above end up taking 4 or 5 months to finish because of the extra effort needed to deal with the problems caused by rushing. In other words, a bad case of Technical Debt. […]