On Technical Debt, Code Reuse, and our client APIs

There are several types of debt a business can incur. One is financial debt, which is pretty straightforward and well known – you take out a loan, then you owe money. A less well known form of debt is technical debt, which is essentially borrowing time from yourself in the future.

Accruing technical debt is much easier than accruing financial debt – all you have to do is sacrifice technical correctness for speed, cost, simplicity, etc. This is much easier to do in programming than in other forms of engineering. If you’re building a bridge, you design it, it gets built, and that’s pretty much it. The bridge needs maintenance, but you don’t continually add features to improve the bridge. This means you don’t really have to worry about future modifications when designing your bridge – you don’t have to design your suspension bridge with the possibility of it being converted to a drawbridge in mind. Furthermore, you can probably make some sacrifices as far as technical correctness goes, but if you make too many your bridge won’t pass inspection.

These things are not true for programming. In programming, once a feature is released it can and probably will be continually modified and improved, often to the point of complete overhaul (at least from the users perspective). Features can work just fine for years even if the code implementing them is poorly designed, with problems only arising when it needs to be modified. There’s (usually) no outside inspection of code to ensure it’s technically sound – it’s up to the individual or company to have a good review process (and even a solid review process doesn’t ensure correctness – just look at the 1950 Tacoma Narrows Bridge).

All this means technical debt is incredibly easy to accrue, but what does that actually look like? It really depends on the specifics of the project, but a common form of technical debt is code reuse. Code reuse is bad not only because it’s inelegant and time consuming, but because it makes a project much harder to maintain. If there’s a chunk of code that is repeated throughout your project, and you need to change it, you have a bunch of places to touch and it’s not always obvious where they are. Furthermore, it makes the code longer and harder to think about, and it can introduce bugs if you fail to correctly modify all the chunks. So generally it’s best to design things in such a way that you don’t have to repeat yourself often. If you find yourself repeating code often, it’s probably an indication that you need to change your design, or at least put that code in a place where it can be reused.

This brings me to our client APIs. Currently, we have an API for Android, two for iOS (one for Active911 versions 1.2 and older, which isn’t updated, and one for the newer versions), one for Windows phone, one for the Webclient, and our open API. This is not ideal, as large parts of those APIs are completely identical, and in theory they should all be exactly the same. This means there is a lot of code duplicated across multiple files. If we want to add a new feature (for example assignments), we have to write basically the same code about 4 times to add it to all the clients. Therefore, as part of a larger push to reduce our technical debt in the coming weeks, we will be consolidating all of the APIs into the open API. This won’t be immediately noticeable for users – some bugs might get cleared up, but the real benefit in doing this is we’ll be more stable and able to push features at a much faster rate than before.

Until next time, thanks for reading!

Leave a Reply

Your email address will not be published. Required fields are marked *