Effective Technical Improvement

One of my favourite ways to tackle tech debt is to fix it as I work through product requirements. There are some great advantages to it:

I'd hazard to say this is probably considered a best-practice, so people making technical improvements this way are in good company. I call this "the organic method" because improvements are happening naturally, or "organically" as other changes occur.

There are some downsides though (especially with large codebases with many affected developers):

Usually the biggest downside is that it’s slower.

In practice, I always find that it’s much much slower than you’d think. Here's a graph of a Javascript to Typescript conversion effort that I've been tracking for the past 11 months:

organic tech debt burn down

There are 2 small steep declines here that show the efforts of single individuals for short periods of time, but otherwise this graph (spanning almost a year) is a 64-file improvement out of 223 files in 11 months. At that rate, the effort will take 3.5 years.

I've tracked a number of similar efforts over the last year and the results are similar. My previous experience with organic improvement in large codebases feels pretty similar too: Without specific mechanisms to keep the conversion going, it naturally slows (or worse, stops).

Why does it matter if it’s slower?

Maintaining the incomplete state of the conversion is sneakily expensive:

Most importantly though, if there’s really value in paying for that technical improvement, why not pay it sooner rather than later? Ironically, most of the least productive (and least fun) codebases I’ve seen are because of people making numerous actual improvements but then leaving them only partially applied. Good intentions without successful follow-through can easily make the code worse.

For larger technical improvements (ones that affect too many files to pull off in a week or less) you want to make sure that:

Once you've got those 4 factors in place, you're probably better off in the long run if you capitalize on the improvement as quickly as possible. You probably don't want to cease all product development for a huge amount of time to do it, or send one developer hero off to fix it all, but you'll probably want to come up with something better than organic improvement too, if you really care about that improvement.

Tags: technical debt, refactoring

← Back home