A New Explanation of Technical Debt: The Painter and the Paint Bucket
A New Explanation of Technical Debt: The Painter and the Paint Bucket
Technical debt has to do with the consequences of doing incomplete work. The metaphor of the painter and the paint bucket provides a simple way of thinking about it.
Join the DZone community and get the full member experience.Join For Free
Technical debt is a metaphor that explains about the consequences of doing incomplete work. Software development problems are compared with a debt acquired by means a loan, relating those problems to both the principal and the interests of that debt. This analogy will be understood if the target audience has somewhat common management abilities. If the public does not fully understand those financial concepts, this awareness will be more difficult to transfer.
To cope with this problem, a simpler metaphor is proposed based on the joke of a painter and the paint bucket, which involves more ordinary elements and situations of daily life and therefore should be easier to transfer to a more diverse audience.
The technical debt metaphor describes the consequences of the decisions taken during software development in terms that a manager can understand. This way, Ward Cunningham explained the problems they had in the project using a concept from the financial world: a loan.
In his explanation, Cunningham commented that for each new release, a debt was generated in the same way as when requesting a loan. Each release allowed the development team to show progress and generate business value, but this debt must be paid back, otherwise they will be paying interests on that debt while they keep elaborating on the code base that was not-quite-right because of the loss of productivity they may incur.
Cunningham's metaphor worked to sensitize managers because the audience was specialized in financial concepts. The message was understood. However, what if the audience was not versed in finance? Not all persons, even being specialized professionals in some given discipline, are literate enough to financial concepts, even those relative to loans.
In this post, a new explanation for the technical debt metaphor is proposed based on the joke of the painter and the paint bucket. This exposes the audience to concepts that are both easier to visualize and assimilate, and by those means, help the software professional to increase awareness on the subject.
The Painter and the Paint Bucket
The new explanation is based on a joke that highlights the absurd productivity problems associated with technical debt:
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."
The joke presents a worker with a clear objective: to paint the center lines of a road. To accomplish this objective, he counts with a paintbrush and a bucket with the necessary paint in it. The worker is given free will to accomplish his job the way he wants. The business process that describes his job consists of several activities with different degrees of physical and mental difficulty, some of which he may choose not to do:
- Soak the brush in the paint bucket.
- Measure the width of the road to determine the center.
- Paint a line on the road.
- Walk to the next road sector that needs to be painted.
- Walk to the paint bucket.
- Lift the paint bucket.
- Move the paint bucket to a new sector.
- Drop the paint bucket.
Activities one through four are part of the painting process and are essential to fulfilling the objective. Activities five through eight are part of the bucket management process and can be executed optionally, however, some activities imply others (for example, moving the paint bucket implies previously lifting it and dropping it afterward).
As in any other work, it is composed of activities that are required either because they represent the essence of it (like painting a new strip) or because they are imposed by the company culture (like ethical behavior). Other activities are important parts of the job even if not always necessarily executed (like walking to a new road sector) and others are at the discretion of the worker.
The reasons of why the painter decides not to carry with him the paint bucket may be varied. In terms of the technical debt classification quadrants proposed by Fowler, they could be:
- Inadvertent and reckless: "I didn't know I could carry it with me."
- Inadvertent and prudent: "I could save a lot of time by carrying the bucket with me."
- Deliberate and reckless: "My top priority is to paint only."
- Deliberate and prudent: "I can't move the bucket because it's too heavy."
According to Fowler's classification, the joke represents an example of an inadvertent and reckless technical debt, taking for granted that the man is not experienced enough to perform the task at hand.
The whole process suffers from scalability problems because of the decision to always leave the bucket in a position where the painter started painting, as he needs to walk back and forth with a loaded paintbrush to the new road sector to paint. While the painting process can be executed with different degrees of efficiency and quality, it is the bucket management process what introduces technical debt, that is, there are activities that are not done quite right that affects the final result.
Under the decision of not carrying the bucket with him, suppose that the worker is pressed to complete the job in certain time, he would have to make concessions about the way the work is carried on: running instead of walking to the paint bucket, knowing this is a short term solution as he could not do this the whole day. Another option would be to decrease time in the painting process, maybe affecting the final quality of his work.
This problems are easily extrapolated to software engineering. Think as if the road defines a new release of the software under maintenance, where each meter of the road to be painted represents a new feature to add (functionality, bug fix, etc.). All the activities carried on to reach the release contribute to the final quality and the development schedule.
Following the definition here, the principal of the technical debt is "the cost of repairing quality issues in software systems to achieve an ideal quality level." As you may have guessed, if the painter makes the necessary effort to carry the paint bucket with him all the time, then there is no need to walk to the bucket and no time is spent on it and represents the ideal quality level. Conversely, as the bucket is farther away from the painter, he needs to spend time walking to the bucket each time.
The effort to keep the paint bucket near the painter is what correspond to the notion of Principal of the technical debt, and it is proportional to the distance between the painter and the bucket. In order to pay back technical debt, actions must be taken to bring both near each other.
Consider the interest as "the extra maintenance cost spent for not achieving the ideal quality level." The increasing distance between the painter and the bucket implies an extra effort, that is, walking back and forth to the next road section to paint.
As a result, the interest is represented by the effort of the walks, which will increase over time, unless some of the principal is paid back; that is, unless the bucket is carried over closer to the next sector to paint.
As the concept of technical debt permeate to other professional disciplines besides software engineering, the need to reach a wider audience to sensitize about their effects require us to find simpler metaphors. The joke of the painter and the paint bucket is an example of an explanation that is simpler to visualize than the original one, which involves being acquainted with financial concepts related to loans.
Technical debt will increase as the painter make progress and the paint bucket is farther away from the next road sector to paint (the principal of the debt), and this distance will increase over time (the interest of the debt) unless something is done to decrease it. This analogy is simple enough to be able to extrapolate them to other business processes or professional disciplines, including software engineering.
Nugroho, A., Visser, J., & Kuipers, T. (2011, May). An empirical model of technical debt and interest. In Proceedings of the 2nd Workshop on Managing Technical Debt (pp. 1-8). ACM.
Published at DZone with permission of Gabriel Belingueres . See the original article here.
Opinions expressed by DZone contributors are their own.