A technical debt is like a promissory note for a future development effort that should have been done today, but wasn't for the sake of expediency.
| Resource information | Details |
|---|---|
| Article title | Technical Debt: The Ultimate Guide |
| Authors | Stephen Watts, Joe Hertvik |
| Length | ~2,700 words, 10 min. read |
| Focus | Project Productivity and Sustainability |
Effective management of technical debt is a significant challenge in any software product. The concept of debt in a software product is the idea that certain necessary development effort is deferred but promised later in order to deliver something sooner.
Software teams are almost always confronted with choosing between doing work in the best way (most quality) or doing it in the fastest (most expedient) way. A problem with doing things in the best way is that it costs more to develop and takes longer to implement relative to the fastest way. On the other hand, the best way more likely preserves the non-functional requirements (NFRs) and keeps software entropy low. The fastest way usually neglects or undermines entirely one or more NFRs and increases software entropy.
The idea of promising to do tomorrow what you know you should have done today is like creating a debt to be paid off. Externally, the software may continue to meet user's expectations. Internally, however, it gets messier. That mess makes future development work costlier which is like adding interest on the original debt. If the mess gets bad enough, the interest on the technical debt will overwhelm the project.
The article, Technical Debt: The Ultimate Guide, provides an overview of these concepts and offers some best practices to manage them and prevent interest on technical debt from sinking your project.
