« Technical Debt: A Game of Perspectives

In software we like to use puns and metaphors — mostly to be cute, but sometimes it gets a point across. “Technical Debt” as a term, luckily for its creator Ward Cunningham, is both cute and useful.

A system has Technical Debt if it incurred faults along the road to completion. These faults may be shortcomings in the design, infrastructure, test coverage or stability. The shortcomings may result in a brittle system, slower future development, numerous bugs, performance issues, the list goes on. Both engineers and product managers want these things to be resolved; however, the two groups see things very differently. Those two perspectives can look like a black-and-white conflict, but it’s really more of a spectrum and a conversation.

Technical Debt has varying levels of importance. People have varying levels of interest or priority they would place on this Technical Debt due to their role or perspective on the issue. From an engineering perspective, we see less bugs, faster code on a reduced-Debt horizon. From a product perspective they might feel the time needed for Debt work reduces new feature releases and current bug work. Neither perspective is necessarily wrong. Since both parties have different directives, perspectives and priorities, a common language needs to be found in order to have a productive discussion on the topic Debt.

Flavors of Technical Debt

Technical Debt has emergency debt and reasonable debt. Think credit card debt versus a mortgage. Just like money Debt, Technical Debt is on a sliding scale of urgency. The placement on the scale is also a moving target depending on what’s currently being worked on or what will be worked on in the future. The placement on the scale is also skewed by your perspective within your team: technical lead, junior engineer, product manager, project manager, etc.

Let’s talk a bit about where the Debt comes from before we get in depth on perspectives and scales. Let’s say a project is distilled to the people working on the project, a timeline, and feature-set to be built. Whenever the combined result of people and time doesn’t equate to complete feature-set a few choices must be made: add more people, change the timeline or change the feature-set. The Mythical Man Month tells us adding people is a questionable decision depending on where in the project you’re at. Let’s say you manage to find a way to keep the timeline and the feature-set. Generally that brings in a fourth component to our project distillation: design integrity. If you lower the quality of the internals of your system, or leave out any future consideration, you may be able to hit this date with other given requirements. You will inevitably end up spending resources paying down this Debt, with interest, in the future.

The Parties that Care

Earlier, we talked about varying perspectives. In an organization you might see departmental roles like Engineering or Product. Personal perspectives will often come into play. Infinite things may play into each person’s understanding process. Let’s focus on the Engineering and Product relationship.

I’m an Engineer. Over the recent years I’ve been called a Junior Engineer, Senior Engineer, Tech Lead and part of Architecture teams. At each stage I saw things differently and so did the people around the table. I was able to use my past perspectives to mix up my thought process but I had a current role to play. As a Junior I was concerned about code style, how to get today’s bug done. As a Senior I was concerned about the quality of code coming in from the others around me, trying to set up design patterns for others to follow. I was constantly trying to invest time in bettering our code, making it more failsafe. As a Tech Lead I was explaining options we had as a team for how to build things, where the cost/benefit lay and helping the team implement those. Each role offered a new perspective, formed from a mix of what my role’s function was and what information I had at my disposal. The core decision process of an Engineer is seeking an efficient, stable and maintainable application.

I am not a Product Manager. However, Product Managers are often described as the CEO of their product. Their main goal is to, with the resources afforded to them, build a business around the product. They’re ultimately responsible for the business failure or success with regards to their product. Oftentimes engineers have a hard time getting the time they feel they need to get the Debt paid down on choices they made because of pressures from the Product department or above. Their goal is to build a successful business; not a science project, not a piece of art — the dollars in and the dollars out are what matter.

The vastly different interests of these two parties may seem tedious, but it’s very useful. You need the differing perspectives to push and pull the business in the correct direction at the correct time. Technical Debt is an example of this. Even a pragmatic engineer will occasionally obsess over the specific design of some framework or library. They’ll analyze style details, or maybe just over test their code. On the contrary, a product manager would rather see progress, features that can be added and posted on the marketing website. “When’s that next feature available? Is it shipped yet? Can I have it an hour ago?” they ask. Their role trains them to ask for the next thing or how quickly can that last bug be fixed. It can be hard to explain to a product manager that, if there are options, why the longer-route or why that bug really is worth the expense.

Paying it Down

In order to argue productively about whether or not Debt is worth spending time on, you need to be able to describe the benefits or downfalls in more measurable terms. That puts the entire discussion on a level playing ground for managers and even other engineers to discuss. I may want to fix a rat’s nest of code. If I then post in Slack that I’m going to spend some time on this, some might “get” it, but others might wonder why. I could argue “it’s crappy and hard to work with,” but what does that really say? Instead, approach the assertion that we need to spend time on this Debt with something more tangible: “We use this library for all of our permissions across this platform, it takes up 2 people’s time to explain how to use it, there’s a bug reported every 2 weeks and it has performance issues that fundamentally hinder our platform’s speed.” That’s a lot of things wrong with some imaginary system and suddenly everyone understands that we have a mini fire. We just said that if we invest some time and energy into a new solution or refactored solution we could move faster as a business. Developers could work faster, not be taken away for periodic bugs and the system could run faster.

Use your ability to describe the measurable benefits of investing in Technical Debt to decide if it’s worth investing in at all. Fixing an ugly area of the system because it feels gross is not worthy of your time. It’s not only silly, it’s irresponsible. As far as you know, that part of the system works right now. Your “prettier, better” version that doesn’t measurably change something for the business is fundamentally scary because it’s not in production, might not work and has potential to cost more than never touching it.

Checks & Balances

Everyone needs to think about the fact that other people have different perspectives and motives. It’s not bad that they do — in fact that’s intentional, it keeps you in check. It may force you to spend more time reasoning about an argument. That time may allow you to realize that it’s not worth bringing up or give you insight into others’ reactions. It’s a superpower of sorts. One day I’ll find a way to talk in the dirt about how an engineer can avoid or fix their project’s Technical Debt infection. I know it’s a topic lots of people want concrete answers to. There is no silver bullet that I’ve found, though. You can end up with Technical Debt by over-designing a system too. With some experience it comes down to a mix pragmatism/YAGNI and forethought/design patterns.

Other cool people write about Technical Debt too.

I am a Software Engineer at Highrise.

Find out more about me at http://jphenow.com.