In spite of what you might think, technical debt isn't what happens when you max out your credit cards on the latest tech gadgets. It's a metaphor used in software development, referring to the result of poorly written code for the purposes of fast shipping. In laymen's terms, it means doing the quick and dirty in order to get the product out fast. However, the assumption is that the code should be cleaned up later, hence the debt that needs to be repaid. If the developers continue working on top of the messy code, the codebase will just get harder and harder to work with, until it becomes a big ball of mud. This is the interest that you will be paying, and in technical debt, just like in financial debt, interest accumulates on top of interest. 

The term "technical debt" was first coined by Ward Cunningham, the programmer who developed the first wiki, in a 1992 experience report:

"Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise. 

Although it's most often used in the context of software development, technical debt is something that can be found in many aspects of the working world. It can happen whenever a foundation (literal or figurative one) is not properly set, affecting everything that will be built on top of it thereafter. And the more is built, the more problems arise, because the foundation does not allow for good quality work to be built on top of it.

Technical debt outside of software development

Here's a simple example illustrating this: a student that starts cramming a couple of days before a test by memorizing the textbook, without making an effort to understand the material and only to forget everything the moment he finished writing the test. The student is taking on the debt of studying the material later. But the course goes on, and there is more material to learn, building on the previous knowledge that the student should already have. The more new study material there is, the more interest there is on the student's debt. And he will have to pay interest on the new material that he can't study properly because he doesn't have the basic foundation. 

Another example would be a video editor that doesn't take the time or doesn't know how to properly set up files in Final Cut. If it's a short term project, this might not even matter, but depending on the project's time frame and the number of people who will need to work on that project file, the initial setup can cause many headaches. And the more video is being edited on the incorrect setup, the bigger the debt becomes.

If you're familiar with Holmes on Homes, you're already familiar with technical debt in construction. The HGTV reality show follows Mike Holmes, the host of the show and a contractor himself, as he cleans up the mess left behind by other home contractors who took a shortcut. Sometimes, he needs to destroy entire rooms in order to fix the problem. Even if the shortcut seemed insignificant at the time, there was so much built upon it that "making it right" (Holmes' catchphrase) requires tearing apart entire rooms.

In some cases, it is possible to pay out the principal all at once, without incurring interest. These are examples of work where you do a sloppy job to deliver something quickly, but then go back and fix it, without any effect on work that builds upon it. This can happen, for example, when an accountant is too busy to file away her paperwork, leaving her with mountains of paper to file at once.

It seems easy to say that technical debt can be reduced with better time management, but technical debt can be incurred for any number of reasons. In software development, they can be caused by time and business pressures (which can sometimes be a conscious decision to incur technical debt) or by the inability to write code. And when lack of knowledge meets lack of collaboration between senior and junior developers, the juniors' lack of knowledge will surely incur debt. 

Technical debt is very, very bad… or is it?

I'd argue that the secret of efficient work is knowing when incurring to incur technical debt. As hard as it is to accept this, we don't always need to be perfectionists. The truth is not all tasks require minute attention to detail. Sometimes we need to do quick work because a task is simply time sensitive. That's why technical debt is common in startup incubators. During our own time at TechStars, Sandglaz incurred technical debt for demo day. But it in this case it made business sense. Some amount of technical debt is ok if it helps you achieve a time sensitive goal, like delivering a presentation or meeting a customer deadline, and if you can budget time to repay the debt later on.

But unlike financial debt, there are cases where the debt need not be repaid. Take for example the student who learns the material by heart instead of taking the time to understand the underlying principles. If the student's purpose is simply to pass the test, then there's no need to pay the debt. Another example would be when you deliver something to the customers but then realize that it doesn't actually solve a problem and you decide to scrap it altogether.

Discriminating between good and bad technical debt

Just like in software development, everyone has a front end and a back end to their job, even though it's not always as obvious. The front end is what others see - customers, supervisors, even co-workers. The back end includes the work we do behind the scenes and the process of how we get that work done. Technical debt becomes a huge problem when people other than us will have to interact with the back end - and in most cases, we simply don't work as isolated entities.

Another way to discriminate between good and bad technical debt is by going deeper into the financial metaphor. If the debt you incur for a certain task is high interest (it will take a lot of time and effort to pay it back), then it might not be worth it to take on this debt. But if the interest is small, the short term gain is worth it and/or the task is extremely time sensitive, technical debt might be your best ally.

Technical debt and team work

Within the context of a team, technical debt can be highly sensitive. It simply sucks to be the person who has to clean up after someone has reaped all the glory from meeting a deadline/ brilliantly fulfilling a customer need/ saving the day in a superhero fashion while leaving a mess behind. This can happen both in the world of software development - when programmers crank out herculean amounts of crappy code, leaving others to fix it instead of creatively writing code of their own.

When someone else needs to pick up the technical debt, it damages morale and crushes any sense of team. The employee that needs to fix the code or doesn't get the chance to creatively respond to problems that might arise in their own work will soon become jaded with the job. They can also feel as if they are not fulfilling their managers' expectations, instead being always stuck dealing with others' technical debt.

Technical debt can cause lack of flexibility within a team, if the person who creates the technical debt becomes the only one who can decipher and manage what they've created - be it code or Photoshop layers or Final Cut timelines. Allowing one team member to become the sole expert on a piece of work they've (messily) produced is a sure way to crush the productivity of the whole team when that person becomes unavailable.

Kissing technical debt goodbye

In an ideal world, there would be no technical debt. But in the real working world, that notion borders utopia. You can, however, prevent technical debt by trying to stay as much as possible in the not urgent/important grid of the Eisenhower Matrix. The not urgent/important grid is where you can work on something important while having the time to do it properly, allowing you to produce high quality work without incurring technical debt. Creative work is just one of many examples of work done better in the urgent/important grid.

Limiting work in progress is another great way of diminishing technical debt. By breaking work down into manageable tasks and focusing only on a handful of them daily, you ensure that those tasks are getting done the right way.

Whether you're a developer or not, when you do incur technical debt, remember that it's not the end of the world. Make sure that you don't pile on debt after debt, but that you budget out a repayment plan. Imagine you have several credit cards. You will prioritize payments on the one that ends up giving you most value. This can be based on interest or on the outstanding balance. It's up to you to decide which is better in your circumstance. 

How have you experienced technical debt in your profession? We'd love to hear your thoughts in the comments below.