The One Year Old Bug Software EngineeringDecember 10, 2016
I’ve been revisiting my old repositories on GitHub recently to make sure they are still relevant and to clean up the code. One of the projects I looked into was margopher which I started back in August 2015. I only removed some unused code, and updated the README page after which I decided to follow the usage instructions just to make sure everything was okay. This was when I found out that when I created and used a margopher object one time, I could not use it any more. This because it kept a map of states of its input at the object/struct initialization phase but never reinitialized the map to reuse it. The solution was to move the initialization of the map into the generation phase. This will make a new map everytime the generation method is called.
Although how trivial the solution is, and how simple finding the bug seems, I ofen catch myself falling into the same trap, that is, I tend to overlook some very minute details or rather edge cases that affect the bigger context. This occurs specially in larger business projects where there usually are a lot of edge cases that must be taken care of. These edge-case bugs may or may not be found. An edge-case bug can go unseen for sometime until one of the QA team finds about it or, worst case, a client will.
One might think that writing a thorough test suite will, by default, detect edge cases and hidden bugs. Well, this is partially true. Writing a complete test suite that covers all your system needs fully documented features. Requirements should be gathered before starting the implementation phase. This might seem obvious, however, sometimes this isn’t the case. A client might come with unclear requirements and the picture can only get clearer after some prototyping or after the actual implementation. It’s true that with almost always changing requirements in the business world, it can be quite difficult to update and keep track of the requirements while actually implementing them in code.
Don’t assume it, prove it The pragmatic programmer
In essence, even if it is the job of the QA team to discover difficult-to-find bugs, our responsibility as developers is to be fully aware about the boundaries of the module we are working on.