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

Continuous Integration as an Innovation Engine

Innovation – that’s an increasingly used buzzword in business today. As more companies have become more efficient, through the use of well known operational processes (e.g. TQM, Six Sigma) and the proliferation of IT has enabled more firms to adopt these methods quicker and cheaper; firms find it increasingly hard to be more successful then their peers. Hence, creating innovation is the latest business trend – and that’s a good thing.

Innovation does not mean that a firm has to invent new products. It does not even mean generating radical ideas. Innovation is about bringing together ideas and inventions that are already there, in a manner which solves an existing problem and generates real economic value.

However, innovation also means failure. Most attempts at innovation will fail and how could it not? The act of innovation is to experiment and try new things and not all of them would be success. Therein lies the contradiction: firms say that they want to be innovative, yet fear failure. To be truly innovative, a firm has to build an environment that not only tolerates failure but to encourage it; to remove the stigma of negativity from the acts that fail would embolden the organization to try bigger and ever bolder experiment, with greater payoffs.

In the business of software engineering, there is ever the contending forces of adding new features and making sure nothing breaks. Most of the projects which I have worked on would inevitably reach a point where the rate of new features added would be outstripped by effects to maintain its stability. Tell tale signs that your projects are nearing this stage is having your application described as spaghetti code, cutting and pasting code as to not “break something” and rejecting a feature request, not because it lacks value, but its deemed to be too difficult.

That’s why continuous integration can be your development team’s innovation engine. An application with a mature continuous integration environment would ensure that the code is healthy and the application works as it is expected. The team is allowed to freely innovate, by adding in big features, radically altering its underlying architecture to enable new paths of growth or even just flat out experiment with new technologies and ideas. If an experiment does not pan out, through a string of unfixable broken builds, just roll back and and you’re good.

Continuous integration is able to form the foundations of an innovation engine, however it is just a start. The team must be willing and able to try, fail and try again.

Purpose Driven Companies Are More Successful

A couple of days ago, I had sat through our company’s quarterly all-hands. One point that struck me was the statement that purpose driven companies are more successful in the marketplace. So that does mean that every company should start being purposeful? Any student of Econ 101 are already thought that firms seek to maximize profit. According to behavioral economics, it may not be profit but rather market share, market valuation or personal perks. But bottom line is that every firm has a purpose, not not every firm is equally successful!

Where success comes from is when the purpose is aligned to those of the market, in the case of a retailer – that would be their customers. Econ 101 teaches us that the market would ‘clear’ at equilibrium, that is when the supply and demand curves meet. What it doesn’t explicitly tell us is that firms must provide something that the market wants, is willing and able to buy.

Take the example of the iPhone and Windows Mobile. Windows Mobile has been around for more than a decade yet it had not captured the imagination of the market in the ways of the iPhone. From my very first Windows Mobile phone, it was very clear the natural inclination was to touch the screen with the fingertip! Microsoft did not listen to his customers and had stuck to the stylus. Apple has listed and gave the market what it had expected.

In the end, its a no brainer. For firms to be successful, listen to your customers and give them what they want in a way that is easy to get it.