Student loans are a different kind of debt.

Student loans are a different kind of debt.

Technical debt is a term coined by Ward Cunningham to represent the work not done or the shortcuts taken when delivering a product. In almost every circumstance there are multiple paths than can be taken to deliver a functional product.  For example, when documenting the code you are writing there is a difference between explaining exactly what the code does in detail and being terse and a bit oblique (I can hear the rationalization, “they can just read the code”). The code runs, but if there is ever a problem it will  take longer to diagnose the problem. Whether fixing a defect or rewriting the code, if there is a delay caused by figuring out the code, that represents the ‘debt’ of technical debt.  Technical debt is applied to software, but the phrase can be extended to any deliverable or product.  The work that is not done may or may not be fixed in the future.  Until the technical debt is paid back, the debt accrues interest.  Whether or not that interest is important depends on your situation.

In a perfect world there would be no technical debt.  Work would be done according to all organizational standards and no corners would be cut.  However we live in reality.  Calendar time is the enemy of perfection.  Today’s business environment is dynamic with advantages appearing and disappearing rapidly. The ability to bring products to market quickly to capture a market advantage that might be fleeting can lead to technical debt. A limited amount of technical debt can be used to accelerate delivery.  Clearly some technical debt can be acceptable.  The question is, when does the debt have to be repaid?

Possibly never. The technical debt accrued when building functions or applications that have a short lifespan may never need to be addressed. This is where the metaphor of accruing interest breaks down a bit.  If these short term functions are retired quickly enough the debt need not be paid back.  However functions or applications that have a long term future will need to be refactored to remove some or all of the technical debt.

Technical debt is a metaphor for all of the corners we cut as software is developed.  Technical debt is not a metaphor for defects in the code. Technical debt creates drag by making code harder to understand, more likely to break when changed or slightly off the architectural standard. The effects of technical debt can usually be measured in the additional amount of effort required to make any specific change or in the amount of planned refactoring a team feels they need to allocate to keep the development process moving efficiently.  The choices to manage technical debt are fairly stark, in the long run technical debt has to either be repaid, serviced to keep it manageable or the code needs to be retired.