{"id":5398,"date":"2015-09-14T06:00:31","date_gmt":"2015-09-14T13:00:31","guid":{"rendered":"http:\/\/thinkapps.com\/blog\/?p=5398"},"modified":"2015-11-09T15:02:04","modified_gmt":"2015-11-09T23:02:04","slug":"technical-debt-definition-importance","status":"publish","type":"post","link":"https:\/\/thinkapps.com\/blog\/development\/technical-debt-definition-importance\/","title":{"rendered":"Technical Debt 101"},"content":{"rendered":"

We’re starting a new series on technical debt<\/a><\/span>. In this first post, we explain what technical debt is and why it’s important.<\/em><\/p>\n

It’s been four years since <\/span>Marc Andreessen<\/a> quipped that \u201cSoftware is eating the world<\/a>,\u201d a statement that is\u00a0even more true nowadays\u00a0than it was back then. <\/span><\/p>\n

You can find cars, phones, houses, aircrafts, and a plethora of devices we use in our everyday lives that are controlled by some type of software system. And in the last one to two\u00a0years, article after article has appeared talking about the fact that software is everywhere and recommending that \u201ctraditional\u201d companies change the way and the pace at which they deliver software. <\/span><\/p>\n

Now that everyone is aware that software has indeed eaten the world, we need to understand why <\/strong><\/span>technical debt is eating software<\/strong>.\u00a0<\/span><\/p>\n

Right about now you’re probably thinking, “Wait a minute. What do you mean? What is technical debt and how is it affecting the software we use?”<\/span><\/p>\n

In this post \u2014 the first in a new\u00a0series on\u00a0technical debt and software quality \u2014\u00a0I’ll try to explain in simple terms what technical debt is and\u00a0how it affects software and businesses in general.<\/span><\/h3>\n

\"Technical<\/a><\/p>\n

Image credit<\/a><\/em><\/p>\n

The Kitchen Metaphor<\/span><\/h2>\n

If you Google the term \u201ctechnical debt,\u201d I’m sure you will find many good definitions,\u00a0descriptions, and explanations. <\/span><\/p>\n

However, when I introduce a new word or idea, I always prefer to discuss it in a\u00a0simple way before diving\u00a0into the technical details. So, let me explain the concept of\u00a0technical debt using a kitchen metaphor. \u00a0<\/span><\/p>\n

Imagine that you are an excellent cook. It\u2019s Friday night and you have invited some friends to your place for a dinner party. You want to prepare a delicious meal. But, at the same time, you want to spend as much time as you can with your guests. <\/span><\/p>\n

When dinner is ready to be served, you decide to leave the kitchen without cleaning up and go back to your friends. The next morning, you wake up and want to make a\u00a0quick breakfast before starting\u00a0your day. The kitchen is a mess from the previous night’s meal. But you woke up late and\u00a0don\u2019t want to lose the whole day by doing a deep clean. <\/span><\/p>\n

So, you set the scouring pads aside and decide to just clear\u00a0some space by stacking the\u00a0dirty dishes in the sink. Your breakfast is ready in five minutes\u00a0and you move on to the other items on\u00a0<\/span>your Saturday task list.<\/span><\/p>\n

\"Technical<\/a><\/p>\n

Image credit<\/a><\/em><\/p>\n

Now imagine that you and the rest of your household\u00a0do this same thing for a whole week. You prepare meals but always leave the kitchen worse than you found it. <\/span><\/p>\n

It\u2019s very probable that after 10 days it will be impossible to work in the kitchen. Even worse, it will be a nightmare to properly clean it up. So, you take the brave decision and blow it up.<\/span><\/p>\n

The above example makes absolute sense to our topic of technical debt if we think about the following analogies: <\/span><\/p>\n

The kitchen is the software system. <\/span><\/p>\n

The dishes you prepare are some cool new features that customers expect to get in the forthcoming release. <\/span><\/p>\n

The preparation of those dishes is the code you add or modify in the codebase, and the mess left after those 10\u00a0days is \u2014 yes, you guessed correctly \u2014 the technical debt.<\/span><\/p>\n

\"Technical<\/a><\/p>\n

Image credit<\/a><\/em><\/p>\n

Should Technical Debt Always Be Avoided?<\/h2>\n

After reading\u00a0the kitchen metaphor, you might assume that technical debt is an evil thing that must always be avoided. It turns out that is both true and false. <\/span><\/p>\n

The meal preparation example again comes to the rescue and will help make this concept easier to understand. <\/span><\/p>\n

When you are making something to eat, you probably use some cooking pots, a cutting board, a few utensils, etc.\u00a0<\/span>Unless you are a cleaning maniac or you want to use the same pot again, you rarely wash them before you eat. <\/span><\/p>\n

I usually eat, take a nap, and then I clean everything up later. And most people would agree that it\u2019s absolutely fine to leave the kitchen a mess for a little while. <\/span><\/p>\n

The same applies to software. It\u2019s OK\u00a0to have technical debt for some period of time. Actually, since there\u2019s always someone who is\u00a0cooking in the kitchen (since developers add\/modify\/remove code all the time),\u00a0there\u2019s no such thing as software without technical debt<\/strong>. <\/span><\/p>\n

Instead, the\u00a0key question to ask is: How long are we allowed to leave the kitchen in such a mess? There\u2019s no one-size-fits-all answer.\u00a0I can\u2019t give you a specific\u00a0number in hours or days or even weeks. <\/span><\/p>\n

Instead, I prefer this approach: Before someone else wants to use the kitchen, clean it up and put everything back in its place. <\/span><\/p>\n

To put\u00a0this same sentiment in terms of software development: Before you move to the next feature or bug fix, make sure that you haven\u2019t created any new technical debt in the codebase. <\/span><\/p>\n

How Does Technical Debt Affect Software Development?<\/span><\/h2>\n

What kind of mess can developers create when they make changes to the code? <\/span><\/p>\n

When a new file is added but it\u2019s not covered by unit tests, when they copy and paste some code that they\u00a0believe works and looks close to this new\u00a0task, or even when they\u00a0don\u2019t document some design or architectural change, technical debt can occur. <\/span><\/p>\n

In other words, all those little things that developers\u00a0know are wrong when they’re doing them but don\u2019t have the time to fix contributes to technical debt. There are\u00a0always better things to do than refactoring this 2000 line class, right?<\/span><\/p>\n

Certainly you will not need to blow up your system after 10 days like we would have to do with the kitchen. However, the cost of fixing a bug or adding a new feature to a module that is so over-complicated that a single code change would break everything is something that you should care about.<\/span><\/p>\n

You might be tempted to compare technical debt with financial debt. At first glance,\u00a0this might sound reasonable. If you don\u2019t pay the debt now (fix the code today) you will have to pay some interest<\/strong> in the future (spend more time to fix the same code). The big difference, however, is that financial debt is usually relatively stable, whereas technical debt increases exponentially over time. <\/span><\/p>\n

So, that’s why it\u2019s important to always pay attention to\u00a0technical debt. And to keep your team motivated to do so, here are some of the rewards of keeping technical debt in check:<\/span><\/p>\n