When developing software, there are several times at which you can choose among quick&ugly hack, which will incur higher maintenance headaches in the future, and slow&clean design. Usually, the slow&clean design is the way to go. But life is complicated and has a way to contrive an exception for each rule. Therefore, one should know how to manage the consequences of quick&ugly hacks.
This is the subject of technical debt, written about by people like Steve McConnell.
Roughly, you incur technical debt whenever you make a design or implementation decision which will require future rework or higher maintenance workload. The decision could be also something trivial such as not bothering to invest in documenting your present design, causing the future maintainer to waste time learning your design before modifying it.
Technical debt is written off when the software package in question is taken out of use due to replacement by a newer software package, the application area becoming irrelevant, or the company going bankrupt.
References:
- Technical Debt – Steve McConnell’s classical blog article. It does very good job of pointing out the different kinds of technical debts, making analogies to financial debts, the business trade-offs, and how to talk to business managers about technical debt.
- Developer Debt – an article in the Follow Steph blog. It has a propagandaful tone about the evilness of out of control technical debt.
- Technical Debt – an article in Martin Fowler’s blog. As dispassionate as McConnell’s article, but much shorter.
- Complexity As Debt, Technical Debt – items in the c2 Wiki. They are brief and have reference to several related concepts.
- Technical Futures – another c2 Wiki article. It is about another concept borrowed from the financial realm to software development realm.
