In projects – especially software ones – one can perform any activity in the best possible way or degenerate to a level that barely works: this degeneration introduces Technical Debt whose interests shall be repaid later, during the evolution of the product, int arms of an extra maintenance effort.
The concept of technical debt is best explained as:
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. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.
-Ward Cunningham
I am currently reading some work about TD and so I am also trying to place individual tiles into a big picture puzzle. Currently there is much interest around this idea and a working group on the topic has been created.
So, this is how I figured it out by myself:
Any time we degrade the quality of our work we introduce new issues (e.g. defects, hard-to-understand code, tangled design etc.) that will induce extra maintenance effort, i.e. additional costs.
The interest we pay on debt corresponds to the difference between the present value of future cost of extra maintenance minus the cost we save by choosing a less than optimal practice.
Did I simplify it too much or made it too complex?
Marco Torchiano 