This is the most commonly understood type of technical debt. This is when compromises are made in order to get a system up and running sooner.
The business benefit gained from this is obvious – if a system can be up and running two months sooner then not only does the business save two months of development costs, they also gain two months of benefit from having a working system.
“You Ain’t Gonna Need It”
This type of technical debt forms the basis of what the lean movement would call MVP (minimum viable product), which is the idea that the first release of any system should be the very minimum that will bring tangible benefit, and that this should be done in the quickest way possible. This is an extension of the agile philosophy of YAGNI (You Aren’t Gonna Need It) which says that you shouldn’t waste time building anything until it is actually needed. The MVP approach says that you should embrace technical debt as the best way to generate income and prove that potential benefit of a development.
The key thing to remember about technical debt is that, unlike financial debt, it never has to be repaid. Systems can exist, and continue exist for their entire lifespan with technical debt.
Paying back interest
There is, however, interest to be paid on this debt. Interest on technical debt is paid in two ways:
- The additional cost associated with introducing new features because of having to deal with the short cuts taken in earlier, and
- The reduction in benefit associated with the workarounds, manual processes and missing features in the system.
This interest will be increased if additional technical debt is being introduced with new features, and existing technical debt not being reduced at all. This is not an unusual situation in new systems where the demand for new features is intense.
So, when does this sort of technical debt become a problem?
With each new feature that is being introduced into a system there is a degree of benefit that will be gained, there will also be an additional cost associated with introducing the change because of technical debt issues within the system. At the point at which this cost exceeds the benefit gained, then you have a serious technical negative equity issue – at this point your technical debt needs to be addressed.
Remember that the additional cost associated with technical debt is made up of three elements:
- The physical extra cost because of the additional time and effort necessary to get the feature generated
- The opportunity cost associated with the additional time that it is necessary to wait until the benefit from the feature can be seen
- The competitive cost associated with being unable to be as quick to market with new features as your competitors
The key to managing this type of technical debt is to be aware of the technical debt that you are introducing, track it and be aware of the impact it is having.
More important is to be willing at a point before technical negative equity is hit to deal with it, and to reduce it in a controlled and proactive way. This can be done by maintaining a technical debt register or by creating technical debt items in your product backlog.
Other posts in this series:
- Introduction: Why Technical Debt isn’t all bad
- Positive Technical Debt part 1: A Director’s Loan
- Check back soon for Positive Technical Debt part 3, plus some negative types of Technical Debt (subscribe)