I’ve learned that technical debt is a killer of projects. The accumulated shortcuts, quick fixes, and compromises inevitably erode a team’s ability to just get things done.

Sometimes, it comes from a decade old repo that is filled with dead code and lots of edge cases that have piled up and never been rationalized or fixed. Sometimes, it comes when a company is trying to build a 2.0 version of their product but hasn’t allocated enough time for the execution so they take short cuts and push out half tested, or incomplete code. Wherever it originated, tech debt slows down coding process to a crawl.

Who dunnit?

Tech debt is often labeled as a “developer problem”. Why do these silly programmers just paint themselves into corners like that? The problem is that tech debt often is downwind of the pressure to move faster and code out more features that developers are put under.

It also comes from a fundamental lack of knowledge about what programmers are doing. We are in the business of writing down abstractions about some process or system that need to work in the real world, and the real world (along with its business processes) are messy and constantly changing. Given that things change all the time, programmers need some time to go rework the abstractions we wrote before. Things change and our code needs to change along with it (even if it isn’t delivering a new feature).

Shop work

A phrase that I am fond of is “shop work”. No idea where I picked it up but it means the work that you need to do to get the shop back in order before you can get back to the real work.

For instance if I go into my workshop to cut some wood or rewire something I usually have to move some kids toys out of the way, clean off my workbench and maybe sweep away some dust before I can get to the real work.

All those tasks are shop work. In programming we often call this “refactoring”. I am of the opinion that refactoring is not just a nice-to-have, it is a necessity for any project to become a long-lived project.

How Technical Debt Hurts

So the developers are sad that their job is hard? Most people aren’t concerned about that. Developers make too much more and have jobs that involve sitting in comfy chairs typing on computers. Hardly being put to work in the salt mines.

The problem is that developers are only the first ones to feel the pain. Talented developers don’t want to work in a tech debt heavy codebase and when they find they are stuck in one, they are the first to walk away.

But what started as engineering problem quickly becomes a team problem, then a company problem because technical debt leads to loss of productivity. New features that used to take hours now takes days and development velocity craters as developers spend more time untangling complex code than building new features. As I said before the world (and our business systems) change constantly and our code base needs to keep up. Without pushing out new features and tweaking old ones to fit the changing needs then the company has less to sell and what they are selling just doesn’t fit the market as well as it needs to.

In addition, when the code is just old layers upon layers that have never been shop worked (refactored) then is becomes easier to introduce more bugs and spend more time firefighting them. Instead of building something new, we’re constantly patching holes in our software.

What to do?

I favor refactoring as you go. It really feels best to solve a problem or clean up a mess when it is in your face. I don’t want to go clean up my garage because I might solder something next week. I want to clean off the tool bench right before I start wiring things together and turn on the extraction fan. Doing refactoring as you do your work also means that you have the most knowledge about the area as you are likely to have (since you are working in it then) which means your refactoring will best line up with the reality you need to abstract into code.

So, go! Refactor and shop work your code into a happier place!