If you like BUGS, your place is in the IT. Imagine spending your time searching for bugs and analyzing them, admiring their complexity and amazing talent to disguise and to transform. If bugs are not the reason why you chose IT, you might find the answer here Why did you choose IT?
Perfection is just an illusion, it simply does not exist and IT is no exception. Same as everything else, a software is also not meant for the eternity and will certainly not fulfill all expectations to the full extent during it’s complete lifecycle. Same as a child, software needs to grow and evolve until it reaches the maturity level. Continuos improvement is the key to survival.
From what I have seen so far (and I have seen IT from outside and inside), I can definitely say, that there is NO software without bugs! Just think about software programs and applications you have installed on you’re PC, laptop, smartphone or whatever small and fancy device you own to make your life more complicated. Once installed, you can hardly escape from the new releases and recommended updates promising you a better, more stable version which brings cool new features with it. They never say that with every new feature, with every new version you will become also the proud owner of new bugs, free of charge.
No program is absolutely flawless. Programs and bugs are perfect symbioses, they are like humans and bacterias, like bees and orchids. Programs are the natural habitats of software bugs, whereas bugs are often the impulse for improvements, enhancements and innovation.
There are two types of „bugs“ in the IT, the true ones and the fake ones. Like in the nature, the true bug is rather rare and the rest are just so called, wanna be bugs.
„The Hemiptera or true bug are an order of insects…They range in size from 1 mm (0.04 in) to around 15 cm (6 in), and share a common arrangement of sucking mouthparts. The name “true bugs” is sometimes limited to the suborder Heteroptera. Many insects commonly known as “bugs” belong to other orders; for example, the lovebug is a fly, while the May bug is a beetle.“ Wikipedia
A true bug of the IT world is a problem indeed, causing wrong, unexpected results, sucking the memory or hardware resources, in worse case even causing a system outage. It is actually a flaw in the program, generally a human mistake, a tiny issue which was overseen or forgotten during the creation phase. A tiny issue with huge impact. Producing bugs and learning from mistakes is a part of the natural learning process in the life of a programmer. A good programmer needs to have hands on experience with infinite loops, unhandled exceptions, improper validation of input data and many more.
Several methods and techniques like agile software development, code analysis and review, automated unit testing and all in all discipline can prevent such bugs from being introduced in a software program. The problem is that most people do not realize the importance of such actions and tend to neglect them, using common excuses like: „there is no time for this now, but it is high on our To-Do list! Once the product is launched we will catch up.“ We all know what happens with always increasing To-Do lists.
But what about the rest of the bugs? If the true bugs are limited edition, what are actually the so-called fake bugs? A famous IT sentence comes to my mind: „It’s not a bug, it’s a feature“. There is a drop of reality in it, although it is often misused as an excuse to cover human mistakes. These bugs are not easy to handle as they are not clearly errors but a result of misinterpretation, miscommunication or other unfortunate circumstances.
If I ask you to bring me something to drink and you bring me coffee, whereas I was actually thinking of tea but never said it loud, would you consider it your mistake or my fault? Would you go to a restaurant and ask the waiter to bring some food, something digestible, without saying what exactly you wish for?
The more specific we are, the more the result comes closer to our expectations. If we choose not to, than we need to be flexible and be prepared for surprises. In a perfect world, the perfect IT project would have well defined requirements not leaving any room for interpretation, a clear design thought throw without any gaps and unanswered questions. This would be of course realized by highly motivated professional people with clear understanding, working together as a team. I must mention that in this case the written form is mandatory. Memory fades in time and people tend to misuse the power of the spoken word.
Whether they are true bugs or fake bug, they cannot be ignored, they need to be addressed, understood and corrected. Call it fixing, maintaining, patching, changing or adapting the software, one thing is for sure. Bugs are social creatures, they never come alone. Once you find one, you might encounter another one, or by fixing one, you might create two more. It can be a never-ending story and can drive one crazy. The key is to know when to stop, at least for a while to get a clear mind.
My personal tip to you is: take a break and do something completely different, immediately after fixing a software bug and solving one problem. Don’t doubt yourself and triple check. If you let your brain rest for a while, you might see things much more clearly. If you keep looking at the same problem and the solution you just provided, I can guarantee that you will find the next bug in the system ending up in a vicious circle. Once it’s fixed, it’s fixed. Of course, I highly suggest to follow the four-eye principle and have the fix reviewed by another colleague. If the fix is actually a long-lasting stable solution or just a quick fix, a so called workaround which you plan to replace soon with a better solution, it’s a completely different story.
Noticing the problem and the symptoms is the easy part, finding the root cause is the real challenge. Some bugs are very tricky and hard to find. Sometimes it feels like being a doctor operating on a live system. We all have our tactics and strategies to find the cause of a problem, but there is one which seems to work if all other have failed. I am talking about the elimination principle, a common practice in the IT. I am sure you heard of it, if not, then I bet you apply this in your every day life, maybe not consciously but by following your instinct. People are not born with this skill but they seem to acquire it in the early years of childhood.
I will tell you a short story that, in one way or another, might sound familiar to you. Imagine a child, let’s call him Dave, on a playground, surrounded by his friends and playing with many colorful, interesting, beautiful toys. Like any child, little Dave prefers to play with his favorite toy, a red dotted silver shining mini drum he just received from his father. Being distracted for a second by the sound of a barking dog, he turns away and just when he reaches for the drum again, he notices that it disappeared. Looking at all the children running around and playing, he has only one thought in his mind: he wants to get his toy back.
Dave is a clever boy and decides not to cry but to solve the riddle by himself, without the help of his mommy and daddy. He sits down and starts to play a game. In stead of trying to figure our who took his toy, he decides to take a good look at his friends and think about who could possibly NOT take it. His idea is to eliminate the subjects one by one until only one is left. The sweet Mary is surely innocent, she is a very nice girl and he likes her very much. Without realizing that he could be fooled by his emotions, he shifts his attention to Raemon, a self confident, very social boy. Dave has his doubts and decides to face him with a direct question, hoping that the surprise effect will force Raemon to tell the truth. This strategy doesn’t lead to success, as the boy loudly expresses his anger being accused by his own buddy of something he did not commit.
Little Dave does not give up, he hopes that with patience and perseverance, excluding several options and alternatives, applying different tactics he will achieve his goal. Although the game is often based on assumptions, he needs to trust his instinct and believe in himself.
However the story ends, if clever Dave gets his toy back or not, it will be a learning for a lifetime, one to help him solve problems later on. He might become a brilliant programmer capable of finding and fixing complex bugs.
Future IT people out there, prepare for an exciting debugging and bug fixing experience!