Magnitudes of technical debt

The term “technical debt” really covers a lot of areas of concern. It is not simply relegated to “messy programming”. That is part of it, but there is more to it.

Like with many unpleasant things, the impact of technical debt, can be measured in magnitudes. Some kinds of technical debt are easy to deal-with and some are monumental. When a developer says “let’s resolve the technical debt around here”, be careful about writing a blank check.

Like with all development efforts, it is a good idea to “contain your scope”. You will generally maximize ROI and build momentum when you start with the low-hanging fruit and avoid items of high impact.

Low impact tech-debt (quick ROI) examples:

  • Compiler build warnings – These are usually easy to resolve. Make a habit of resolving these as they appear, or work to eliminate a dozen of these a day/week.
  • Coding conventions violations – When your code is “conventional”, it is easier to maintain. Pick a coding convention and enforce it. Then there won’t be “my code” and “your code”. It will all look identical.
  • Configs – Hard coded settings in a project can be evil. You don’t want to modify your program every time you move it to a different server or file path. That is bananas, and very risky. Make sure you have those settings in config files. Make sure the configs are clean.

Med impact tech-debt examples:

  • Obsolescence, falling behind – Don’t let your program turn into “the next COBOL”. Even if it is actually written COBOL, you can still take periodic steps to keep it updated and modern.
  • Awkward programming styles – Ninja programmers can come up with some impressive stuff, but you don’t want your code written in a manner where only a genius can maintain it. If you haven’t generously applied “the kiss principal”, then you are carrying some tech debt with a heavy burden, and it will cost you.
  • Lack of error handling – If a user complains about your buggy program and you have to ask what they did when an error occurs, then you don’t have adequate error handling. Your error handlers are metal detectors to show you the needles in the haystacks. You don’t ever want to live without them. Be generous with error handlers and logging.
  • Inadequate tracing – See error handlers, and imagine that something went bad, but didn’t result in an error that could be caught. Without a trail of breadcrumbs, it will take a frustrating amount of time to recreate the conditions. Eventually, you will wish you had tracing to tell what was happening.
  • Things like: global variables (a needle that seems to move around in your haystack)
  • DLL hell, GAC hell, SP hell, all of the other hells that come from reuse/sharing of code. – Brochureware always sells the idea of code reuse, like it is so great and never turns your life into a nightmare. If you’ve been around the block, you know better. Caveat emptor.

High impact tech-debt examples:

  • Architecture – If your architecture paints you into a corner, you might be in the worst kind of checkmate. Starting-over, might be your only hope.
  • Bad designs – There are all kinds of ways to design a system, which makes them impossible to maintain or close-enough to it. Untying some knots, can turn into epic tales.
  • Security – Thanks to the internet, security is a big enough topic that it a career path for many people. Dabbling in security is like being your own lawyer. It is not a good place to learn from your mistakes.
  • Platform (OS, data, language) – I’ve always laughed at IT people who warned you about a technology like SQL Server or .NET because “you don’t want to be locked into a single platform”. It is a ridiculous claim and the people who fall for it eventually realize that people don’t switch platforms for any good reason. If you ever do switch platforms, you will never do it twice. Locking into a platform is a way to get stability. Y’know, like a foundation. You don’t just switch it periodically.

I’m not saying you can never tackle the topics on the High list. Sometimes you just need to do those. However, don’t do it on a whim. Rome wasn’t built in a day. Don’t start with Mt Everest.

Most important of all: The time to be the most careful with these things is BEFORE you start programming and not afterwards. Like a foundation, you want to start with a solid one, in a reliable place. Make sure the big items are done correctly by someone who knows their stuff (and not just some silver-tongued sales person or giddy fan-boy).

In the words of Bertrand Russell, “Fools and fanatics are always so certain of themselves, but wiser people so full of doubts.” Measure yourself by those words.


About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Architecture, Lessons Learned, Review and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s