As a metaphor, technical debt relies on the fact that those who hear it understand the financial concepts that the metaphor relies on. You may think that the concept of taking out a loan and having to pay interest on that loan as being simple enough for almost everyone to understand - but if you add onto these concepts the language of software, the meaning of technical debt can be lost in translation. To communicate technical debt to a larger audience this post presents a new, simpler, and more accessible metaphor for those who fail to grasp the finance-software relationship of the original metaphor.
When Ward Cunningham first developed the metaphor he explained that in each new release a debt was created just as when you take out a loan. Every release allows the development team to add value to their software offering but if that loan is not paid back on time, the interest on it will compound in the form of having to work on a codebase with code that was made quick and dirty. You will waste time and lose productivity, and this will cost you.
The metaphor worked because it was directed to managers who were well versed in financial concepts. But as we mentioned at the start of this post, the assumption that all specialized professionals will understand the devastating consequences of not paying back a loan is not full proof.
A new analogy for the productivity issues associated with technical debt is highlighted in this post. It goes:
"A man is hired to paint the lines on the road.On the first day he paints ten miles and his employers are amazed. But the second day, he painted just five, and on the third day, he painted only a mile of the road. Disappointed, his boss asks what the problem was. The man replies, "Well sir, every day I have to walk farther and farther to get back to the paint bucket."
Just as in technical debt there may be a possible explanation for what in retrospect looks like incompetence. There are diffferent types of technical debt, and those different types can also be used to explain why the painter would not carry the bucket with him as he painted:
The analogy outlined above represents an inadvertent and reckless form of technical debt: the painter's boss did not realize the painter was not experienced enough to perform the task as he desired. This joke also represents how even if the task at hand is being performed (painting the road) there are other implied tasks (the management of the bucket) that need to performed to a certain degree of effectiveness in order for the central task to be completed efficiently.
There are ways that the painter could make concessions to complete painting the road on time but leaving the bucket at the start of the road: he could run to the bucket each time he needs to refresh his brush. But these sort of concessions can lead to a decrease in the quality of his work. He might leave paint splatters along the road as he run or paint crookedly as he is out of breath every time he starts to paint again. These problems can be easily reapplied to software development: if the road is a software release and each mile of road is a piece of functionality, then every mile of road will contribute to the ultimate quality of the release.
It is known that incurring technical debt also comes along with the interest to pay it back. Interest is usually defined as the extra work needed to resolve the issues of quality that arose as a result of missteps that resulted in technical debt. In the painter example, the interest materializes itself as the effort required to walk back to the bucket. The longer the technical debt goes unaddressed the more effort it will take to pay it back (i.e. the distance to the bucket will get farther and the walk will get longer).
The purpose of reframing the technical debt metaphor to the painter example is to widen to audience that understands what technical debt represents in a software project. Ensuring that more people understand what it means to take on technical debt will help to ensure that it is taken as a serious development issue and one that needs to have resources spent to resolve it. It ensures that rampant technical debt and technical failure don't creep into a system and decimate a project's software quality.
To read the full post visit here.