Technical Debt and Your Website

^{Image by CreditDebitPro}

You’ve requested a new feature for your website and your developer tells you that there is some technical debt that should be dealt with first. Technical debt? Your hosting is paid up, you don’t have any outstanding invoices, the website looks great, and everything seems to run just fine. So what are we talking about here?

What is it?

The term Technical Debt was coined in the early ‘90s by programmer Ward Cunningham as a metaphor for what happens when a choice is made in development to do something the fast way rather than the right way. Taking a shortcut today borrows against time that will need to be spent fixing that code in the future. Simply put, if a feature will take ten hours to build correctly, but the decision is made to create a passable version in two hours, revisiting that feature in the future to do it right will still take ten hours of work. In the end, you’ll pay your developer for 12 hours of work on a 10-hour project. It sounds like a bad deal, but technical debt is just like financial debt: ideally you have none, but if borrowing now puts you in a position to more than make up the difference by generating revenue faster it’s probably a smart decision.

Compounding Interest

As it is with financial debt, technical debt accrues interest. Our example of spending 12 hours on a 10-hour feature assumes that the 10-hour debt is paid off rather quickly by refactoring the code in question after launch, and before adding additional features. In practice, however, what often happens is that after launch there’s more desire to add additional features than to pay off the debt, and often that necessitates working around issues created by the original piece of technical debt. The extra time required whenever a developer needs to work around some piece of technical debt without fixing the issue at the heart of the debt is equivalent to paying the minimum payment on a credit card. You can pay that interest for years without ever making a dent in the principal. Workarounds require more workarounds, hacks are piled on top of hacks. 10 hours of technical debt becomes 20. 20 hours becomes 40. Every workaround increases the complexity of the website and makes it that much harder to untangle in the future.

What Does It Mean For You?

photo credit: Russ Allison Loar Pawn via photopin (license)

Technical debt can be the result of bad choices, such as a developer not understanding how to build something the “right” way and choosing to patch it together in a way that gets the project over the finish line, or it can come from very reasonable business decisions, like the need to get an e-commerce store online and earning money as soon as possible, with the assumption that corners that were cut today can be fixed once the website is generating revenue. But what if your developer starts talking about fixing your technical debt and you never had a discussion about going into debt in the first place?

From the perspective of a website owner, technical debt is more than the result of well-thought-out decisions. For our purposes, technical debt begins to accrue when a decision made during development, whether conscious or unconscious, is eventually negated by factors such as a change in usage or scale. Today’s good decision could be tomorrow’s regret, depending on changes over time. New features, new scope, or new focus can paint those choices in a different light.

Let’s say you own a music store, and your initial site build includes a lessons page listing your three guitar instructors. It’s a small store, you don’t have a huge budget, and since you only have three instructors it doesn’t make sense to set up a guitar instructor content type and a guitar instructor template. Your developer builds this page as a one-off. Two months after launch, guitar lessons are going so well that you’ve decided to offer saxophone lessons. You request another page on the site to list your saxophone instructors. Does that mean it’s time to create a content type and a template? Or since it’s just one more page, do we build the saxophone lessons page the same as the guitar lessons page? Our decision is easy if we know that this is the last lessons page we’ll add, and it’s easy if we know that this site is going to evolve into an expansive directory of music instructors in a variety of instruments and genres. What started out as a unique, one-off page could eventually become the centerpiece of the website. Scope changes, focus shifts, and technical debt accrues.

Technical debt resulting from good decisions, bad decisions, evolution, or incompetence all add up to problems that need to be fixed, and time that needs to be spent. When you’re deep in technical debt, how you got there matters hardly matters. You’re in it.

What Now?

While financial debt is a great metaphor for technical debt, there is one point where it falls apart. With financial debt, you receive a statement every month showing how much you owe, how much interest has accrued, how much of the principal you’re paying. Technical debt has nothing of the sort. Technical debt is difficult to quantify, and often accrues in the shadows. Our original example of deciding to build a 10-hour feature in 2 hours with a specific plan to go back and fix it later is a rare beast indeed. More likely it adds up a little bit here, a little bit there, until one day your developer says, “We need to talk.”

Whether you’re planning a new project or maintaining website that has been plugging along for years, communicating openly about technical debt will always be beneficial. On a new project if decisions are made that create debt, catalog it, and have a strategy for dealing with it before the interest compounds. On an older project, make sure your maintenance budget has room to address these issues, and schedule time to do so whenever you have the opportunity. In the long run you’ll save money, you’ll save stress, and adding new features will be much easier.

Do you need help getting out of debt? Get in touch.