Author: Shawn Gaul with collaboration from Steve St Jean and Marty Donovan

This post is the start of a series that presents a new metaphor for describing and discussing technical debt. The series focuses on explaining how this metaphor can be used to change the way you look at this problem and thereby help to understand ways to overcome it. With that change in perspective, we’ll look at ways to tackle it and thus ensure your team continues to provide productive business value.

In one of my previous roles I had an interesting challenge. I’m sure I’m not the only one who has faced this challenge before, so I want to describe the situation and how I started looking at technical debt differently.

Before I go too far, Technical Debt is a metaphor created by Ward Cunningham, you can hear him explain it here ( https://www.youtube.com/watch?v=pqeJFYwnkjE ). In short, it’s used to describe the situation where technical shortcuts are taken to deliver software quickly. The metaphor looks at these short cuts as a sort of loan taken out on work to be done later. The interest on the loan is represented by the work a development team must do dealing with the presence of that short cut. If you take out too many loans without paying down your debt, sooner or later you will find your team spending all its effort paying the interest on the loans and not able to make any progress towards new development.

It is a very powerful metaphor. It helps to prevent loans from being signed by teams being rushed to deliver. It can also be used to assist in describing why there is work that has no tangible value to those who aren’t working on the system aka “we’re paying off our loans”.

Our team educated our Senior Leadership Team (SLT) on this metaphor. In our agile development process, we identified the backlog items that were Technical Debt. This gave us insight into how much we were spending paying down the debt. As we identified new technical debt, we added it to our backlog and our technical leads were responsible for prioritizing the debt. This gave us insight into the size of our known debt. Each sprint we allocated a specific number of points to Technical Debt (e.g. if our team was capable of 70 points a sprint, tech debt got 10).

This seemed to work very well for managing and reporting the debt, so well that we started to expand the usage of the metaphor. For example, let’s say our product team had identified a set of backlog items that were required for the initial implementation of the product. Let’s also assume some of those were not ready in time. Those items then became “Product Debt”. Our UX designer made compromises in the design to get the product delivered, those became “Experience Debt”. Etc.

Now don’t get me wrong these additional debt classifications didn’t hold small backlog items, they were significant features. They were deemed as not required for that minimum viable product. Whether they should have been tagged as debt or not is probably a debate for another blog post. For this discussion, they were.

The difficulty was that our ability to create or identify debt far exceeded our ability to pay it down. You see from the technical debt side; it wasn’t like we had started tracking the debt from the initial green field of the system. Not only were we logging new debt identified by the growth of the product, but we were also logging the existing debt.

Our debt backlog was growing at a far faster rate than the product backlog, which let me tell you, that puppy could grow very fast. Our SLT was getting very concerned. Much of our development effort was being spent on these debt stories. They started asking questions like:

How much debt do we have?

How much debt is too much debt?

When did we create this debt?

What percent of the code base is debt?

With the debt metaphor, these are very valid questions. Questions that any SLT faced with this scenario should be asking. They are leading questions into the possibility of starting from scratch. Which I agree, the life of every software system will eventually get to this point.

Our primary difficulty with that idea was a significant portion of our debt could be attributed to the previous incarnation of the system still being in place 6+ years after the current incarnation’s launch. The team had a very difficult time with the thought of having another incarnation being created when we didn’t have a track record of being able to retire our previous system (especially considering the much larger client base on the current incarnation). The idea that we would move faster on a new system while still maintaining two previous incarnations seemed very unlikely.

We needed a way of looking at this debt in a different light. The metaphor at this point wasn’t helping us anymore. In a lot of ways, it was painting a very scary image, one that was worse than reality. So I started to try and think of a different way of looking at the problem. A way that could explain the situation in a more productive way. One that gave us a means to not just prevent it but deal with it in more ways.

At the time, I lived in Minnesota. Had lived there for 8 years. Most people know it snows in Minnesota but they don’t realize the sheer quantity of snow that we get. More than that, the snow doesn’t just melt and go away the next day. Every year is different but in general it starts to snow around November and doesn’t start warming up until around April. Some years it can stay cold enough to keep the snow around until May.

It was around March, the time of year when you’re pretty much sick and tired of looking at snow. I was pacing around the office, deep in thought, trying to determine another way to look at this problem. While I was pondering, one of my coworkers stopped me for some small talk, it went something like this:

“Jeeze, it just keeps pilling up doesn’t it.”

To which I naturally respond:

“Tell me about it… “

“wait… “

“you’re talking about the snow!”

For me, it just clicked. Here was an excellent way to describe the situation. Not only were the similarities there, it provided a means to look at the situation in a more productive way.

Before we get to far, I need to shift your perspective just a little from that of Ward Cunningham’s. Ward’s perspective comes from the instantiation perspective. That perspective of a fully aware and conscience decision to take a technical short cut. Instead I want to shift to that of a developer’s perspective, one that is a year, two, three, or some distance away from the time the code and its design was created. When that developer looks at the code, he/she doesn’t care about whether it was a conscious decision, a decision made as a short cut to get a product out the door, or simply a lazy developer. All that developer cares about is that the code that they must deal with needs to be or should be refactored to accomplish what the business of today needs to accomplish. You see that change in perspective is the difference between thinking about how it was done and instead how to deal with it.

Fighting with the forces of nature that create snow doesn’t prevent it from happening or help with dealing with it. From the person standing in front of a mountain of snow that is blocking them from getting to their goal, the details of which storm or what decision was made to pile it up here isn’t going to help them clear it.

In the next series of posts, we’ll focus on explaining how this metaphor can be used to change the way you look at this problem and thereby help to understand ways to overcome it. With that change in perspective, we’ll look at ways to tackle the ever mounting snow, ways to forecast the snow storms and prepare for them to ensure your team continues to provide productive business value.

Next up Snow Happens!