Hacks create technical debt by ignoring principles of good software development in favor of quick, easy fixes
This is the obvious one because it is the one technical teams complain most about. “I didn’t want to do it that way, but my manager said I could only choose from options that took less than a day to implement,” or some variant of this statement, is the most common answer to the question “Why does X suck so bad?”
So how do developers typically fight back against hacks? With reuse anticipation. Now the bad news.
Reuse anticipation creates technical debt by expanding the supported code base without creating a correspondingly timely value proposition
It’s easy to imagine that the service, component, module, whatever, that you’re building might be used by multiple applications in multiple ways. It only takes an extra YY hours to make it universal, you tell the project manager. And then we’ll never have to write this code again. Sometimes, when you already have “universal” demand for a component, this is a good idea. It’s also a good idea when it is a very specific, low-level technical capability, like dumping a message in a queue or searching a string for a value or something like that. Sometimes it’s a really bad idea – over-generalizing a capability can make it so difficult to “reuse” that no one will reuse it. Either way, it increases your technical debt, because whether anyone reuses it or not, the code you have to support is more complex than it would otherwise be.
Time creates technical debt
There’s a great riddle in The Hobbit, by JRR Tolkien:
This thing all things devours:
Birds, beasts, trees, flowers;
Gnaws iron, bites steel;
Grinds hard stones to meal;
Slays king, ruins town,
And beats high mountains down.
Tolkien might have included code in this list had he been a software developer.
Time has a way of dimming our memories of the code we’ve written, what it does, and why it does it. It is for this reason that development teams often turn to comprehensive documentation to save them.
Now for more bad news.
Comprehensive documentation creates technical debt
Every document you write that has more purpose than helping you figure out how to deliver code NOW becomes another artifact you have to maintain. It adds to your code base in that regard. Now, instead of paying people to maintain the code, the business has to pay someone to maintain the code and the documentation. You just fell further behind.
Documentation typically only has ROI in the short term. It is a very rare document that provides value over the long term. Usually it very quickly becomes a cost with little return of any kind.
Innovation creates technical debt
Einstein said we can’t solve our problems with the same thinking we used when we created them. Sadly, when we continuously apply the same thinking to our code base that we used when we created it, the technology world doesn’t do the same. It moves on, finding better ways to do the same thing. Small changes add up and become big changes, and suddenly there are much more attractive technologies that we can’t use because we’ve fallen so far behind.
When we see the world moving on to bigger and better ways of solving our problems, it’s tempting to say something like this:
“There’s no point putting effort into X, we’re just going to move to Y soon anyway.”
Sometimes this is a good idea, if moving to Y is funded, approved, and making progress. But if Y isn’t approved, giving up on X will only increase the amount you owe, and you’ll feel doubly bitter about it when Y never materializes.
When I see this problem, I think of a line from an old song: “If you can’t be with the one you love, well then, love the one you’re with.”
Technical debt creates more technical debt
With credit cards it is sometimes possible to make the minimum payment without reducing your principal a penny. In fact, you can pay your bill and end up with a higher balance because of this.
It’s the same way with your code base. If you don’t invest in it faster than you are accruing technical debt, your technical debt will grow. Why? Because you don’t have time to make it better, so what are you doing? You’re hacking – cutting corners and doing the wrong things just to get done in time with the resources you have.
Technical debt sucks as bad as credit card debt. I suspect that paying off technical debt is very similar to paying off credit card debt. It’s hard, it requires frugality, and it means shedding everything that isn’t really important. More about that some other time.
Have a nice week.