What is this all about? Are bugs not just simple programming errors?
Programmers know the hard way that debugging is the toughest part of programming. It is understood by users and clients that bugs are, when not critical, at least shamefully annoying, and that the programmers are the ones to blame, within reason.
Nevertheless, bugs seem to keep popping up, sometimes years after an application, a compiler, or even an operating system is written and left untouched.
The different nature of bugs as well as the scientific impossibility of ensuring their absence from an algorithm is a fascinating theme that transcends IT itself. But that will not be covered in the scope of this article, because no matter its theoretical and philosophical interest, it does not solve any practical purpose for neither programmers nor users.
Just for curiosity, here is the world’s first computer bug:
In fact, the first bug recorded was really a moth. Here is what happened: www.nationalgeographic.org/thisday/sep9/worlds-first-computer-bug/
What can a programmer do to quickly spot bugs, even during postproduction?
There are several well-known techniques to try to prevent bugs, but… the answer is that they cannot, not only by themselves.
The programmer needs their leaders and product owner to be aware of the inevitability of this phenomenon, to be allowed to use some of their working time spreading traps to reveal bugs as they manifest.
And once that is done, everybody will profit from the “hunting of evil bugs,” even with those that manage to hide all their way into production.
What is the secret weapon against bugs anyway?
There is no secret weapon! Bugs are unwanted behaviors of an application that, in most cases, are a manifestation of our ignorance about the almost unlimited range of possible interactions and situations, called state machines. If it can happen, it will happen. It is just a matter of time. Murphy’s law states: “Anything that can go wrong will go wrong.” NASA takes that law very seriously for obvious reasons: most of their “toys” are beyond reach.
Let us fight ignorance with information. Put this way, it almost sounds like Buddhism… Logs, logs, and logs. Lots and lots of logs. To be able to replicate a situation that triggers a bug is the first step to understand it and wipe it out of existence.
What does “lots of logs” mean specifically? How does it work inside the code?
There are many tools to ease that task (NLog is a powerful one in dotnet) but what matters is not the language, framework, or technology used, but what is done with it. Some useful guidelines are to log with date and time:
- Every entry in a function with its parameters exposed when feasible
- Any relevant middle results inside the function
- All try catch error messages and inner messages
- Every exit of a function or method with its return value, if any
- The detail of what happens inside a function should be customized according to its complexity.
Too complex functions are not recommended. It is better to split them into smaller and simpler ones.
Is this all just a fancy waste of time only to look cool in a meeting?
Well, allow me to share something that happened to me:
I was writing a dotnet core solution for quite a while involving several interconnected projects for a server, client machines, and web services. I had been instructed by my project director to implement loggings in the solution. I confess that by then, this was new to me. I did it, but did not take it too seriously…
One day I crashed over my keyboard and my director passed by and asked me why I was so down. I answered that I have been trying all day to find a “tricky, mean bug” that was killing me.
His answer was that the problem was not the bug, the problem was my logs. If I had spent all that time and could not at least get a clue about what was going on by looking at them, then they were serving no purpose at all. What would I do when the projects go live and the client calls complaining about something that was not supposed to happen?
By then there would be no debugger tools to use because it happened on someone else’s computer, and the only thing I could do is ask them to send me the logs. I would then have to find enough information to recreate the same scenario on my computer and then resolve the bug.
That made me think, rewrite the loggings, and afterward, I realized that bugs, even some that had been hiding, were getting pretty easy to deal with. It all comes down to following footprints. But in this case, to have footprints the ground must be prepared beforehand.
At last but not least, let us put this in perspective
So as to not overlook any kind of negligence or responsibility, let’s take a look at other people’s problems to be able to get a better perspective of our own, and hope that it helps us keep a level head. In this line of work, anxiety has only one direct outcome: the inhibition of cognitive capability. And that is something we do not have the luxury to afford.
It was mentioned earlier that NASA has a very severe policy concerning all problems that might happen, even the unlikely ones. Nevertheless, the Hubble Telescope is now up in the sky “happily gazing at the cosmos’ greatness, through a pair of glasses!” Because, not to disregard its purpose as an observer, image recorder, and emitter, it was built and launched being near-sighted. Here is the information right from the source:
www.nasa.gov/content/hubbles-mirror-flaw
This article’s title begins with: “IT´s Devil: Bugs!” Is the concept of a bug something that fits exclusively within IT, or is it some kind of devil, whatever that might mean? It is well-known that randomness, chance, or errors (bugs?) are in the core of our cognitive abilities (most human errors emerge from faulty memory access, take a look at this: ‘Copying’ error may have built up our brains: www.nbcnews.com/id/wbna47300424, The Psychology of Forgetting and Why Memory Fails: www.verywellmind.com/forgetting-about-psychology-2795034, Intentional Forgetting: An Emerging Field in AI and Beyond: https://link.springer.com/article/10.1007/s13218-018-00574-x), in the core of the natural evolution process, the origin of life itself, and in the core of “who knows what else” in this vast universe.
It is our role to find within ourselves the peace of mind to accept its existence and presence. That way we may use tools that better match the situation at hand.
Get everything out of our path that conspires against our work. With that spirit, we should always keep pushing ourselves to the limit trying to become better and more efficient at our job, delivering better and more reliable products.
By the end of the day, that is all that really matters as computer engineers, programmers, and IT consultants. And that is why and what we are here for after all. The rest is just smoke and mirrors.