Developers Log: Takeaway from IAFC

In a previous post, one of my fellow developers spoke of his thoughts after attending APCO. Well, last month was my turn to get to help man the booth at IAFC in Atlanta. ?I would say that I am a somewhat introverted developer which had me pretty nervous about the trip, but once I arrived and started meeting all of the amazing people I found myself really enjoying the whole experience. One of the biggest takeaways for me was just getting the opportunity to meet so many people who use Active911 and to hear their thoughts.

A lot of you who attended just stopped by to show us that you were using our apps and that you were very happy with how it has enabled you. And some of you came by and spoke for a while about different issues that you were having or new features that you would like to see. Some features that were brought up that I think could really make life easier are better ways to manage location markers in bulk and better integration with more CAD systems.

As the Windows developer, there was one thing that really made my day. A few firefighters came up to the booth and one of them wanted to know why Active911 didn’t work on his phone. I asked what kind of phone he had, and out of his pocket came a Windows powered HTC M8. I jumped on the opportunity to introduce him to our Windows Phone app and help him get it all set up.

In all, it was a great experience to see Atlanta, a conference room full of apparatus, and to meet so many friendly people.


Me (Robert Olson) at the Active911 booth in Atlanta, GA.

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!