Technical Debt

Software products tend to build up ‘technical debt’ over time. Every bad decision, kludge and shortcut made to ‘just get it working’ makes the product more brittle and harder to change in the long run. Technical debt is very hard to avoid unless you know exactly what direction your product will take in the future (unlikely) and you can guarantee that the platform and libraries you build it on won’t change (even less likely). Like real debt, the longer you leave it, the worse it gets. Every so often you need to repay the debt if you want to keep your product healthy. Otherwise it will gradually degenerate into a Big Ball Of Mud.

My seating plan software has been developed continually for over 10 years now. I have done regular refactoring over that time to keep technical debt to a manageable level. For example, early versions of PerfectTablePlan were a bit lax about how memory was managed in the genetic algorithm. This shortcut wasn’t a big deal when the genetic algorithm was solving seat assignments for a few hundred people. But it became a performance issue when it was solving seat assignments for thousands of people. So I had to do a significant rewrite of the genetic algorithm. For PerfectTablePlan v6 I am going to have to rewrite all the remaining code that uses Qt3 classes, so that I can switch the codebase fully to Qt5. Oh joy! Thank goodness for the strong typing in C++. If I can keep the technical debt in check, perhaps people will still be buying PerfectTablePlan in another 10 years.

Technical debt is an inevitable consequence of the fact that software products are a ‘work in progress’ (including the software you are building on top of). The fact that software is never really ‘done’ can be frustrating, but it has its upsides. I was recently in the French mediaeval city of Laon, looking at their beautiful cathedral. I noticed that there were four and a half windows at one end of the transept. Four and a half? On further inspection it was clear that the builders had changed their mind part way through the build and then tried to cover up their mistake. It is still visible some 700 years later. At least we get the opportunity to correct our mistakes and our customers usually never know…

technical debt

4 thoughts on “Technical Debt

      1. IT and software engineering jobs

        We measure lines of code by counting new lines in all *.h and *.cpp files, though some programmers count only non-blank and non-comment lines. (Well, in our case it’s *.php, *.sql, *.css, etc files lately).

        How many lines of code was it when you initially released it?

Comments are closed.