A Matter of Do or Die: Dealing With Technical Debt


“When it’s a matter of do or die, always do.”

That was Matt Rissell’s stance when it came to keeping TSheets’ doors open–back when we were still struggling to take off and looking for any opportunity to extend the runway.

In this case, “do” meant “promise our customers new features and hope the development team could keep up.” Unfortunately, this tactic simply couldn’t (and didn’t) scale. Before long, the development team was buried under six months’ worth of work–and they had just a few weeks to get it done. The result was an overwhelming amount of technical debt, a term we became all too familiar with.

How did we dig ourselves out? Read the full story on Forbes.


How can you avoid making the same mistake? Read on.

Wait, what exactly is technical debt?

Technical debt, or tech debt, occurs when there is more work to be done than there is time to complete it. In our case, we were promising new features faster than our developers could actually create them.

But that’s just one side of the coin.

On the other side, tech debt is accrued when software is developed the “quick and dirty” way in an effort to meet a strict deadline. In our case, our developers were taking shortcuts and writing code that wasn’t quite up to TSheets standards–if only to appease the customer and get the feature out the door. Unfortunately, this type of tech debt adds up fast–and it ends up costing even more time and money in the long run. (Don’t worry, we learned our lesson.)

Sure, taking shortcuts might enable your team to hit a deadline, but the resulting “crappy code” could result in a loss of customers. It could (and probably will) suck up time and money later on down the line when your developers are forced to go back and fix it. And, if you incur too much tech debt, it could kill your company.

Eventually, your development team will spend most (if not all) of their time simply paying down tech debt–and less time developing new features or increasing the value of the software. That’s more time repairing, and less time creating a better product. In serious cases, it can be impossible to catch up–and impossible to move forward.

When this happens, “do” actually means “die.”

That sounds rough, how can I avoid technical debt?

The truth is … you can’t. Tech debt is entirely normal for every technical company–and it’s not always a bad thing. Sometimes you need a “lean” release in order to move a project forward. Other times, a quick release can seal a deal with a customer (just be sure you schedule time to clean it up later).

On top of that, as your developers grow and evolve, so does their coding. “Old” coding needs regular upkeep and maintenance if you want to keep it up to par–no matter who wrote it. In this way, tech debt accrues all the time! With that in mind, it’s a good idea to work in regular bouts of “cleanup” time each sprint. Developers can use that time to ensure that your product is up to code (get it?) and keep your tech debt levels low.

In short, tech debt only becomes a problem when you incur too much, so much so that you can’t move forward–it’s a problem when your developers are spending more time on cleanup than they are developing your product.

Avoid this by creating a culture of excellence within your company. Make sure your programmers and developers have high standards and a clear understanding of the true cost of technical debt. It should be crystal clear that “crappy code” (not to be confused with “lean” code–code that can be built out more robustly later on) will not be tolerated, and shortcuts (or “lazy code”) are not allowed.

But you have to do your part as well. You should have a clear understanding of what your development team is actually capable of–and how long each project will realistically take. When it doubt, always under-promise and over-deliver (rather than the other way around).

What if I already have technical debt?

Some tech debt is unavoidable; perhaps you inherited some tech debt from your company’s predecessors, or maybe an old developer created crappy code long ago and no one has taken the time to fix it.

In any case, quick and dirty coding only invites more quick and dirty coding. Developers may come to the conclusion that “this is just the way it’s done,” or “we can get away with shortcuts,” and it will be nearly impossible for you to uphold a culture of excellence. When that happens, there’s only one solution: Pay off your tech debt in one fell swoop.

This means breaking everything down (seriously, demolish that code) and rebuilding it the right way. Sure, it’ll take some time right now–but imagine the time you’ll save in the future! Time that could have been wasted repairing and patching old code rather than moving the company forward … time that could be spent building a robust product that not only meets but exceeds your culture of excellence.

Here’s the deal, you can either pay off your backlog of tech debt little by little for years and years to come, or you can take care of it right now … and ensure it doesn’t add up like that again in the future.

Technical debt almost killed TSheets–but we made it out alive. Find out how.

Follow Matt on Forbes (1)