Any developer who has been in the industry for a few years has experienced technical debt. Maybe you had to make the decision to take in technical debt in order to make a deadline. Many teams are able to wrangle their beastly monoliths into a maintainable form. Some become frustrated and seek to rewrite the software. This post is not about following either of those paths, but more so the effect technical debt can have on you mentally, and on your career.

You reap what you code

The most obvious effect of technical debt is the sluggish, snail-like speed that fixes/features can be implemented into the indebted system. The most harmful effect of being content with this is that you learn how to work around anti-patterns, rather then implementing a better pattern to begin with. You become the expert on how to work with a specific system. So are you really becoming a better software engineer? Maybe you are just becoming a legacy maintainer.

Avoid becoming the stagnating domain specialist

In addition to “mastering” software anti-patterns, developers often become an expert on “how the product truly works” whenever in an environment full of rotting code. Some of your value morphs from being able to write good code to understanding how six different features abuse the same system in different ways. Like your expertise in anti-patterns, this knowledge is unlikely to be helpful anywhere outside your company.

Neglecting technical debt is equal to neglecting yourself.

If your employer (or yourself!) chooses to not to prioritize paying the debt, they are effectively placing the burden upon you. As the developer, you are taking the brunt of the penalty. All other proponents of a software development team will be effected, but none as much as you.

Technical Debt is not like Financial Debt.

Another concept I strongly agree with is the notion that technical debt is NOT like financial debt. A blog by Ron Jefferies (one of the three founders of Extreme Programming) explains these thoroughly. Strong points from the blog include:

  • We often defer the decision to people who don’t even understand code;
  • Most of us cannot make a judicious determination of when to do it, even if we do understand code;
  • Once we have “borrowed”, we can almost never pay it back.

For these reasons, as the term is used, I think the analogy to monetary debt is quite weak.

Retaining Empathy

One strong point I want to make is that you shouldn’t necessarily take your companies decision to let technical debt remain personally. It’s hard enough to assess and communicate technical debt as it is, and whether or not a business surives is not 100% technogical. If you feel your learning has peaked and you are valued more so for your tenure/tribal knowledge rather than programming ability, then it’s time to move. Otherwise, learn what you can and continue!