Managing bugs

Since starting my new post-Doc on project VADR (never gets old!) I’ve not really talked about my other side-projects from my time in self-employment. As I mention in the ‘About Me’ bit to the right of this post, in addition to my post-Doc position I am still working on those projects, and I’ve been spending many evenings beavering away under the banner of my contract research company Errant Labs (yeah I’m not kidding, I really did call it that).

My current project at Errant Labs is to develop a piece of software that I’ve been working on for about 6 months. Without explaining it in too much detail, the software (Trough CTRL) is designed to breath new life into some old lab kit which, while mechanically in good shape, is in desperate need of some modernised software.

Just before starting my new post-Doc, I released the beta version of the software to a few select users and my distributor for some testing. I was hoping that after a couple of weeks we’d find the bugs, squash them and then get it out to everyone else.

3 months later…

So I did two things wrong. Firstly, I may have underestimated the work required to fix the bugs while also answering requests from users to add yet more features. Secondly, oh dear god, the bugs.. when will they end…

I am a research scientist not a software engineer. My software development experience is not nothing but it’s also not equivalent to years of training and courses on proper software design. I am, to a great extent, making this up as I go.

Now in the main this works well, I’ve made a lot of programs over the last few years and learnt at lot about structure and UI design from my various catastrophic mistakes. But nothing has prepared me for the sort of bug management I now need.

What is the bug

Previously the software I wrote was either for me or students in the lab. When it broke or went *SPRONG* when it should go *TIZZLE* I could just look at the software live and see the problem they were having.

Now I have to deal with bugs that are only described by users via e-mails. I spend a good chunk of bug fixing times desperately trying to understand what exactly they did to break my software. Phrases like “when I press it too quick” are a bit tricky to recreate.

And that’s not even including the more impossible problems that I had just never anticipated like “I have installed literally all the malware on the internet onto my computer and your software seems to be conflicting with some of it”. I have no idea how to approach this kind of issue without resorting to sarcasm or just the e-mail equivalent of shouting.

Thankfully this beta period is giving me time to adapt and to learn a whole new language of customer feedback… I go though a lot of stress balls.

Hunting the bug

Stage two of the bug fixing process is to then work out what is causing the perceived problem. With a large program this can be tricky as many parts and sub-programs rely and alter the various features and readouts.

At this point I generally get out some paper and step the program through every calculation and logic and check the math by hand to try and see where I went wrong. This can take 30 seconds or it can take hours, especially where you’ve got large amounts of data going though bits of code and it only breaks on the 1,043rd value.

So just to recap at this point I would equate bug fixing to being like trying to find a fly in a massive box of raisins, after a customer said they thought they heard something growl.

If that’s incomprehensible then you are pretty much at the same place as me.

Fixing the bug

To say that this step is highly variable is kind of an understatement. What I had hoped is that bug fixing would be small simple things that I could do in a few hours 2-3 evenings a week.

A bug can be as simple as a single sign in the wrong place or it can be as complicated as realising that an entire process is broken. Last week I noticed my whole way of thinking about managing data was wrong so I had to throw it out and start again, all because the graphs weren’t changing colour properly.

To return to my very succinct raisins-fly analogy – having found the fly in the large box of raisins, you then swat it and quickly realise that it was was standing on a giant sabre-toothed tiger. The fly is dead but now you’ve got an angry raisin-covered tiger to deal with and the rolled up pizza menu in your hand is starting to look like the wrong solution.

MOAR bugs

But fixing the reported bug is only the start. Fixing a bug (with or without tiger) obviously involves writing more code. This then gives you ample more opportunity to write in exciting new undocumented bugs that won’t crop up until you send out the next version.

What’s worse is that, say when I wrote the original code I created 1 bug for every 100 lines of code (HA! I wish I was that good) well that was when I was carefully planning through things. Now I’m bug fixing I’m trying to get something that works as quickly as possible for a customer that urgently needs it and my error rate is probably 10x what it was originally.

To continue my already-stretched tiger-fly analogy which I feel has been working great so far, this problem of creating more bugs is the equivalent of trying to swat a raisin-covered pissed off tiger with a fly on its head with a box filled with more tigers.

And if you don’t understand the problems of bug fixing in software after that simple explanation then I’m afraid I can’t help you.