Why You Should Pay Your Tech Debt

It’s generally agreed in the programming community that regular refactors are a good thing, and that a company’s codebase should live with the smallest amount of tech debt possible. However, it isn’t always clear how these projects impact the overall business, since they usually aren’t customer-facing.In this article, I’ll be going over the different kinds of tech debt that a codebase might accrue, and why fixing each one is actually very helpful to the bottom line. To get started, there are two different kinds of technical projects: critical and non-critical.

Critical Projects

A critical technical project is one with a hard deadline. For example, code might need to be made more secure before a government audit, or a router might have to be upgraded before high request volume brings the system down. These projects have a clear message: do them now, or your cash flow starts hurting.

Since critical projects are usually very straightforward, I won’t be spending much time on them here.

Non-Critical Projects

A non-critical technical project is one that, to the customer, doesn’t (or barely) affect functionality of your product. Instead, it affects how your company functions internally. Although these projects don’t change the outward facing product much, they do change things like new feature development time, ease of hiring, and time spent on bugs.

Usually, code refactors aim to improve one of four main categories:

 

Category Description
Brevity The amount of code needed to create a new feature.
Cohesion How easy it is to understand how system components fit together.
Code Clarity How easy it is to understand any given snippet of code.
Performance How fast the code runs.

 

These categories don’t seem to matter much to the business overall by themselves. However, they are the main driving factors behind two properties of the system that are very important for the business:

 

Property Description Affected by
Resilience The chance that new features won’t introduce any bugs. Brevity, Cohesion, Code Clarity
Maintainability The speed at which new issues can be found & solved. Cohesion, Code Clarity

 

With these features identified, we can start to look at what we actually want our product to have.

Feature Development Speed

Everybody likes it when things get done quickly. The faster coding is completed, the less money has to be spent on salaries, and the more time the feature spends in production making you money. But how do we make it happen?

  • Brevity. The less code that needs to be written, the less time will be spent coding.
  • Cohesion. When it’s clear what each system layer does, no time has to be spent deciding where the new code fits.

 

Bug Minimization

Nobody likes bugs. You can’t tell exactly what they’re going to be, nor how long they’re going to take to fix. Too many bugs can delay a feature, or even cause a whole product to be recalled. Clearly, minimizing bugs is the way to go, and here’s what we need:

  • Resiliance. New features should only introduce bugs very rarely.
  • Maintainability. In the event that a bug is found, it should be easy to identify and solve.

 

Remember, of course, that those two things are made with Brevity, Cohesion, and Code Clarity. A solid system prevents bugs.

Onboarding Speed

More people means more productivity. Every time a new developer comes in, you should theoretically increase the number of features and bugfixes you can do. However, it isn’t an automatic victory. New developers need training, and while training they’re being paid for next to no output. You can speed up this process by creating an easy-to-learn system, one that has

  • Brevity. The less code there is, the less needs to be understood.
  • Maintainability. If you can find issues quickly, you can also discover intended functionality.

 

User Experience

Finally, we’ve come full circle. Although technical projects don’t create new features, they do impact user experience very slightly. Things like bugs, sluggishness, and unavailability are 100% technical, but also 100% angering to users. To keep them happy, you need your system to have

  • Resiliance. Many bugs aren’t found immediately, and are exposed to users. The fewer, the better.
  • Performance. A faster product means more things done by users in the same amount of time.

 

Example: Choosing a JavaScript Framework

In late 2013, Zoosk switched over from the Google Closure UI Library to AngularJS. The effort was very large — it took several months to port everything over. During that time, new features were nearly at a standstill. Why did we do this? What did we gain?

  • Brevity. AngularJS code is around 3 times smaller than Closure UI code.
  • Cohesion. AngularJS is very opinionated, and doesn’t allow putting code in the wrong layers.
  • Code Clarity. As long as you understand Angular, it’s easy to understand what small snippets do.

This, in turn, increased our Resiliance and Maintainability. Thanks to that, our whole development process improved:

  • Feature development time was cut in half.
  • Bugs decreased by around 33 per month.
  • Onboarding became a test for Angular experience, instead of teaching a whole framework.
  • Users experienced far fewer bugs.

With all of the gains that can be made from technical projects, it would be silly not to add them to your company’s regular schedule. Even small projects like adding utility functions or creating developer tools can have large impacts. Make sure to clean out that tech debt backlog!