What is Technical Debt

What is Technical Debt?

Technical debt is one of those terms that is frequently used but not well understood. Part of my role as an Agile and software development coach is to inculcate better decision making practices. Designing and building software is as much technical as it is creative with a programmer making lots of tiny trade off decisions in the course of a day. It’s usually thought of that technical debt is accrued through big decisions, however most of it is accrued through the little things we do everyday.

So what is technical debt then and what does it look like? What we usually think of as debt may not be debt while debt could be hidden until it rears its ugly head, much like getting that credit card bill at the end of the month. As we get our paychecks, we could pay of the bill in full or pay partial to have some extra cash on hand but be aware that the principal will accrue additional interest.

Ward Cunningham used the metaphor of debt to explain learning through the normal course of solving a problem with code. There are always little things we could do to improve it, like refactoring, extracting code in to a helper method and having sufficient unit test coverage.

Technical debt slows you (or others) down in the future.

Technical debt doesn’t hurt until you have to work with that code again. Debt could slow you down in the following ways:

  • a piece of code that could have been reused if refactored. There are two choices now, refactored, write it again or cut and paste.
  • code that is difficult to understand.
  • code that strikes fear in your heart when you look at it resulting in “I’m not going to touch that” or “I’m going to have to be extra careful to not break it.”

Shortcuts.

While it may seem like a good idea at the time to save some time, shortcuts create longer term threats to the code. As such, just stay away form it and code it properly the first time.

Some examples of shortcuts:

  • God classes / methods.
  • Hard coded configuration values.
  • Magic numbers.
  • Cut and pasting.
  • Using code from Code Project, Stack Overflow, etc without understanding what it does.

Not applying learning in the course of working on the program

The only time we fully understand the problem we’re solving is after we solve it. The same goes with code. Frequently there’s a list of todos after we ship, like some refactoring, or cleaning up code. Unfortunately most times we don’t get to it.

This is another form of technical debt.

By not taking the time to fix these things, the code will slow get more difficult to work with. The three options then become:

  • Don’t ship the code with todos.
  • Schedule time in after the release to complete the todos. This is more than “we’ll get to it someday.” Actually schedule it in and get it done.
  • Don’t do and expect that development velocity will reduce over time.

What is not technical debt?

Having incomplete functionality is not a sign of technical debt. The following is not considered debt as it does not impede the development velocity with the code.

  • Pre-mature optimization.
  • Functional features (eg. automation).
  • Non-functional features (eg. performance, security). Note: Even though its not considered debt in that it doesn’t slow down developing with the code, it will impact quality and reliability.

How to use technical debt?

As we solve the problem through code, there will be items at the end (or even as you’re coding) that you’d think to yourself to go back and fix it.

Here’s some thoughts on how to manage this.

  1. Create technical debt user stories.
  2. Use code static analysis.
  3. Add a TODO to identify shortcuts.
// TODO: Convert this hard coded value to a configuration value. 

var key = "Some config value.";

Compile the list of TODOs before a release and as a team make a decision to release or not. Periodically review this list.

To summarise, code should be easy to work with, with not additional weight or burden. Just like carrying interest on a credit card bill from month to month, that makes it more difficult to completely pay it off. Code is the same, it should be clean, simple and a joy to work with. The only way we can keep it that way is to pay down our debts.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s