Practical Approaches to Tech Debt

Background

What is tech debt?

What isn’t tech debt?

Analogy Time

There’s a Real Cost

  • Productivity — A system with tech debt is difficult to modify or upgrade. If it takes you 4x longer to build a feature because of its unnecessary complexity, you literally increased your costs by 4x. You wouldn’t be ok with paying an engineer 4x the market rate as a salary, right? And you made your customers wait 4x longer, which resulted in additional financial losses, and negative impacts to your brand. By the way, 4x is an understatement — I’ve seen projects where something that should have taken one hour took one month, because of tech debt.
  • Maintenance — software with lots of tech debt is fragile. One simple bug fix can accidentally introduce another 5 bugs. It is risky business to work with a fragile system. So on top of new features taking forever to build, your expensive engineers are spending most of their time fixing bugs instead of working on new functionality. Not exactly how you want to utilize the most expensive people on your payroll.
  • Security — the more fragile your system becomes, the more security risk you introduce (i.e. you are exposing yourself to hacks and data breaches). Depending on the industry you’re in, even one security incident can cost you your entire business.
  • Turnover — no, I’m not talking about pastries. I’m talking about people quitting your company because you suck. Great engineers don’t stick around to maintain software that’s more of a shit show than a Jerry Springer episode. Great engineers want to work on great software, and they will eventually leave you if they’re constantly patching up bad software. This goes for other team members too — product managers, sales people, designers, etc., won’t enjoy working on a product that is on fire most of the time.
  • Competition — if your competition is building features faster than you, and adapting to market changes faster than you, they will outpace you and you will lose. Tech debt is a guaranteed way to not be able to catch up to your competition.

Practical advice

  1. Tech debt mindset
  2. How to avoid tech debt
  3. How to address existing tech debt

Tech Debt Mindset

Don’t Judge!

How to Avoid Tech Debt

Say no!

Talk about it

Formalize your process

  • What are potential features / capabilities we’ll want to add in the near future? Does our current design enable those, or prevent those?
  • What is the time difference between Design Option A (tech debt) and Design Option B (proper design) in terms of time to market, resourcing, ROI, etc?
  • If we choose Option A (tech debt), what effort is required to undo it, and to build Option B (proper design)? Does the total time to implement Option A, undo option A, and build Option B exceed the time to just implement Option B in the first place? The key is to include the time to undo option A. Once you do, you’ll usually find that you’re not saving yourself any time, and it becomes a no-brainer to choose Option B.
  • How long can Option A last? (for example, if you know a poor design choice won’t scale to 10 million users, and you plan to reach that number in 6 months, you may be in trouble. If you plan to reach that number in 5 years, you may be fine).

Get sign-off

  • An understanding that eventually the work will need to get undone and redone, and the estimated time it’ll take to do so.
  • A commitment on when you’ll devote resources to addressing technical debt. Devoting time means that that’s what you’re doing that week, or that month. It does not mean you’ll try to squeeze it in on the side “when you’ll have time”. We all know that means it’ll never happen.
  • List the mileage you’ll get from the current design choice, so things don’t come as a surprise to anyone later (i.e. when you scale to 10 million users and your servers are crashing daily).
  • List the features that would not be able to get developed until this tech debt is addressed.

Put your most senior engineers on it

Build to the interface you want

Document it to death

How to Tackle Existing Tech Debt

Strangler Fig Pattern

Pitch the ROI

Pitch the “Negative ROI”™ (an Isaac Trademark)

Document it

Squeeze it in

Summary

  • Trade-offs — what will be the cost vs. benefits of taking on this debt
  • When and how will the debt be paid off
  • Before it’s fully paid off, how will it affect you? For example, will it limit your spending in other areas, like buying that new car?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store