The Best Way to Prevent Bugs Is...

Funny but true! It is to write less code!

Original Twitter post by @iammemeloper:

https://twitter.com/iammemeloper/status/1722255246196633796

When I look at our First Connectivity Challenge, and I look at the submissions, some of the users will create large socket frameworks just to do the basics. Although that looks cleaner, it creates more surface area where the probability of software bugs is higher.

Minimal and complete is not just a nice-to-have guru guideline. It is something you have to ask yourself frequently, recursively, all the time, before, during and after writing any piece of software! It is that important.

I remember a case that happened to me when I was rehired by JP Morgan. In 2011 I wrote ULLTRA, JP’s first ultra low latency trading and research analytics solution. I maintained it until 2014 when I left to pursue my American dream at Vitorian LLC.

Fast forward to 2017, my previous manager asked me to go back since the people who inherited the software started doing unnecessary refactoring of the code and that was causing (sic) “too much noise” with the businesses we supported.

Just a couple of weeks into me getting at my new office, the system locks down with substantial monetary and reputational loss to the firm. I have to make a note that ULLTRA had been running for years without a glitch so I was really skeptical of all the claims coming from the SRE team.

Well ends up, one of the components was refactored and a new “messaging framework” created in order to “adopt Modern C++ features.” The component in question had a loop on an unsigned integer whose type was templated and based on the message field’s type. It just so happens that the specific field on that particular message being funneled was a uint8_t so a size of 256 would overflow it. However because the type was unsigned, there was technically no overflow to catch on debug so the thread entered an infinite loop that lead to a flooding of our internal network, locking up a few important switches in the process.

It needs to be noted that the loop type was buried by the abstraction provided by the guy’s framework, which ironically was created to make the code more safe and secure!

Would this have happened if the loop was explicitly written and not hidden under a pile of “feels good” templated framework? Most likely, still yes but there is a chance that that logical mistake would not have been written in the first place or perhaps caught in a subsequent code review.

Another advantage of writing less code is that less code will tend to lead to less instructions most of the time. Less instructions means less execution time.

Keep it simple, folks!