When designing and implementing software, one can always imagine more complete abstractions, supported features, and the like. Technical debt is effectively when you take a slightly easier, cheaper, or faster route to get to a destination, which can lead to having to pay back that saving later, like a loan.

A personal example of technical debt is my Arkanoid/Block Breaker Clone. I saved time and effort by using the built-in .NET Serialization features, a savings that I am now paying back manyfold in order to support more agnostic file formats such as XML. Because I went with only the one method, I “tied in” a lot of classes and code with that design; meaning that, in pursuing the capability to save with XML, I need to effectively rewrite that system. But even in doing this, I am still incurring more debt, as now I’m writing something similar for saving to XML. Ideally such a system would be entirely interface driven in some fashion, allowing different implementations to save to different formats. However I’ve opted to take a “technical debt loan” and repay that if that was to come up; remember, of course, this is a hobby project that while having no guaranteed amount of hours put into it, also has no deadline, so that is part of the consideration for the choice; I want to see the greatest return in the shortest time because that motivates me to do more- even with the switch to XML I found myself boringly poring over the dozens of classes to implement something, without even knowing the first thing about whether it would actually work in the end, or if I made a terrible mistake somewhere along the line requiring me to rewrite loads of classes and methods that I had already written.

In a more professional setting, technical debt is intentional and part of the design process, simply because the only designs that would not incur technical debt are expensive, time consuming, and always far beyond the intent. The trick is in managing that technical debt.

At this point you are probably thinking I’ll be presenting ways to do that. I might- but I should point out that I am hardly an expert to turn to. Plenty of more experienced individuals have written articles and even books on the subject, something which I cannot hope to equal in my own writing, except to paraphrase that which has already been written. Which itself raised the question of just why I am writing about it in the first place.

The main reason I am writing about it is because I can write about whatever I want I suppose is because I think that some of the more complicated parts of software development is dealing with libraries and frameworks where technical debt was lessened as much as possible. The reason being that, in doing so, it has made that particular framework or library less straightforward to use- by fleshing out the library/framework further then needed, it avoids paying a technical debt loan, but at the same time it means the end user needs to pay the price in terms of investing hours learning it. This is not a bad thing either- But at certain scales it can become ridiculous. Web development, at this point, has become effectively just figuring out which of any dozen frameworks for particular tasks to staple together. If you want to add Debug Logging to your program, That’s another library. You want to add the ability to do X? You should use ScalerX.

I’m not opposed to that, of course- sometimes you want solutions fast and the fact that other people have already tackled it, whose output you can utilize, is an amazing way to provide the desired output without investing a lot of effort in finding the solution. But I think a lot of the fun of software development is in figuring that sort of thing out, not in deciding which of the people who have endeavoured to solve the problem you should use the code of.