The Painter and the Paint Bucket: A new explanation for Technical Debt


Technical Debt is a metaphor that explains about the consequences of doing an incomplete work, in which 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 have 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 easer 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 that 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 were “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 where 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, helping 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 by the absurd the productivity problems associated to 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 only 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 freewill to accomplish his job the way he want. 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:

  1. Soak the brush in the paint bucket.
  2.  Measure the width of the road to determine the center.
  3.  Paint a line in the road.
  4. Walk to the next road sector that needs to be painted.
  5.  Walk to the paint bucket.
  6.  Lift the paint bucket.
  7.  Move the paint bucket to a new sector.
  8.  Drop the paint bucket.

Activities 1 to 4 are part of the painting process, and are essential to fulfill the objective. Activities 5 to 8 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 afterwards.

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 it is imposed by the company culture (like ethical behavior). Other activities are important part of the job even if not always necessarily executed (like walking to a new road sector), and others are at 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 be saved a lot of time by carrying the bucket with me”.
  •  Deliberate and reckless: “Top priority is to paint only”.
  •  Deliberate and prudent: “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.

Technical Debt

The whole process suffers from scalability problems because of the decision on leaving the bucket always in the position where he 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 in [1], 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 with him the paint bucket all the time, there is no need to walk to the bucket, therefore no time is spent in it and represents the ideal quality level. Conversely, as the bucket is farther away from the painter, he needs to spend time to walk 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” [1]. 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 be 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 be 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 analogies are simple enough to be able to extrapolate them to other business processes or professional disciplines, including software engineering.


[1] 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.

Leave a comment

Your email address will not be published. Required fields are marked *