In our profession we sometimes find that it is hard to find an layman analogy that properly describes tendencies and properties that characterize our craft.
A codebase can be purposely characterized as being “rigid” or “brittle”. We may laugh at how appropriately it describes specific components. But aside from a good laugh, this is something that we should be more familiar with as it helps to communicate to other professions than programmers.
Sometimes an analogy is so powerful that it becomes an industry standard.
One such term was coined by Ward Cunningham who worked with clients in a financial institution and was bogged down by codebase riddled with issues. The end functionality was satisfactory and the clients were initially unwilling to invest 2-3 months of work without an increase in added business value just to “improve the quality of the code”.
The qualities of the codebase, aside from functionality, were invisible to the clients. They did notice, however, that:
· Estimates more frequently went into weeks.
· Small changes broke unrelated stuff.
· Programmers are reluctant to visit certain parts of the system.
Cunningham introduced the term “Technical debt”. And with this simple context switch, suddenly its financial aspects were apparent to the client.
It simply means that you have borrowed something, most commonly time, from somewhere. As with any debt, you will have to keep paying your mortgage until you have paid it back. If you decide to not pay, interest will accumulate.
It doesn’t have to be time, it may be understanding the component or technology. You have found a nice little place where you can insert a discrete “if-then” sidetrack to patch up or filter away some data that passes through some random snippet. You are both confident that you haven’t broken anything and you count yourself lucky that you didn’t have to understand the complete context of the snippet.
The problem is that the code rots. If you never decide to give pay the borrowed time back, you end up with most functions not doing what they claim to be doing. The code is not coherent at any one level. You need to constantly deep dive to figure out how it “really” works. Soon, “if-then” is all that you dare do.
Technical debt will accumulate exponentially, especially since management will frown upon a decrease in productivity. So, the developer “steals” more time from the pool of technical debt.
Technical debt is, like ordinary debt, something that is not inherently bad, but it should be responsibly managed. It is a tool. If a business never went into any kind of debt, it would lose all agility and could not respond to its market, but would be at the complete mercy of its technical underpinnings.