The Technical Pie (Yet-Another-Tech-Debt-Analogy)

Yesterday, I was listening to a talk by @TitusWinters on why the current metaphors for “technical debt” are insufficient and fail to capture the reality of the situation. So, before going into the metaphors, what is the definition these metaphors try to capture?

Here is a definition from wikipedia:

In software development, or any other IT field (e.g., Infrastructure, Networking, etc.) technical debt (also known as design debt[1] or code debt) is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.

Here is another definition from a Dagstuhl in 2016:

In software-intensive systems, technical debt is a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible. Technical debt presents an actual or contingent liability whose impact is limited to internal system qualities, primarily maintainability and evolvability.

Although I don’t remember the exact wording, Titus had another definition that I really liked, where the basic idea was “technical debt is the difference between the software we have, and the software we wish we had”.

So, these are some of the definitions. Even though there isn’t an agreement on a fixed definition, probably all engineer have some internal conception of it. Technical debt is sometimes the doc or the test we didn’t write, sometimes the one edge case we didn’t handle, sometimes the design we know will force us to a redesign but we are using for now. It doesn’t even have to be this negative, sometimes it is the decisions we take in conditions we know will change, where we have to make a choice even though we know that’s probably not the right one.

What about the metaphors? There were four of them in the presentation.

1. Debt. This is the classic example. It’s very intuitive, we think we are borrowing some time/money from our future selves. The interest rate acts as the cost of pushing the effort to future.
2. Pollution. Pollution is an interesting metaphor. The idea is basically that you are creating some pollution in your coding environment, which will require some cleanup at some point in the future. You are not the only one affected, other members, teams or organizations are also affected by the pollution you create.
3. Cooking. Cooking has a more intuitive connection to software development, as it relays the idea of product development. When you are cooking, you might take shortcuts, you might leave some item on the sink at a particular moment as it is convenient, but you’ll have to pick it up in the future. If you leave too many things, you might suddenly encounter a full kitchen sink, representing the non-linear nature of technical debt, which is not really captured with the debt metaphor.
4. Gardening. Gardening is taking the cooking metaphor one step forward. You are not just crafting a product, you also have to maintain it. Additionally, gardens are scalable, so you might be able to imagine a very large garden you need to attend to as you think of a bigger project. For cooking, it is hard to imagine how scaling up works.

None of these metaphors perfectly captures the underlying idea of what software developers talk about when they mention technical debt. One could imagine how “not writing docs” convey into cooking. If you don’t write your recipes properly, how would your apprentice learn to use them? On the other hand, how does “not writing tests” convey into these examples, I don’t really know.

The solution Titus had to this rather incompleteness of these metaphors was to throw them out. Instead of trying to talk about debt, pollution, failure to organize the kitchen or the garden, talk about inefficiencies. Tech debt is a problem because it creates other problems. It creates inefficiencies for the future of our engineering teams. Why don’t we just talk about inefficiencies and how to mitigate them?

I have 2 disagreements with this idea;

1. People tend to become very attached to powerful metaphors. Metaphors and analogies travel around, affect people much more deeply than arguments. Inefficiencies is much more abstract than debt, hence I don’t think it’s really possible in practice to make people talk about inefficiencies when talking about technical debt.
2. Inefficiency is such an umbrella term, it is rather applicable to almost any domain, any concept. This generality makes it easy to classify virtually anything on the efficiency scale. I think that’s harmful because it makes tech debt “boring”.

I also come up with another suggestion for a new metaphor, The Technical Pie.

The technical pie relies on the fact that functional requirements are both related, and also orthogonal to quality requirements. I view the development of software as a non-linear journey.

Think of the black dot as the beginning, each line as a functional requirement along the way. We sometimes struggle with the requirements, we go around, but we consistently move as we develop our project. What happens when quality requirements also come into play? I argue that our previous stack-like line based process becomes a circle.

Whereas each layer of the circle represents a feature we develop, the direction of the arrow represents our perfect process. Within a perfect process with perfect quality, we would be moving alongside this perfect line. Yet, this isn’t what happens in real world.

Consider these two examples. The left(green) case showcases a path where we finally align with the quality requirements, whereas the right(red) case shows that even though we have reached our functional goals, we are far from the quality requirements.

So, what is technical debt?

Technical debt here is the blue slice, in other words, The Technical Pie. As you are developing a product, you have a target quality that can actually change in different phases. That is your baseline. Your efforts, as well as allowing you to develop your features, push or pull you towards this ideal quality line. The Technical Pie is the difference. To eat the pie, you either need to create a long term path to close the gap between the ideal and the reality, or quickly close the gap by pausing development of new features for a while, or some hybrid option between the two. You can also always change your ideal results.