What’s in a name? that which we call a rose
By any other name would smell as sweet
–Shakespeare
Names aren’t that important, but consistency is. I had a discussion with my colleague Onur Taviloglu about the terminology used in my post Debugging: a detailed look at failures. He pointed to me the terminology used by Algirdas Avižienis, which somewhat contradicted with the terminology of my post. So, I got in touch with my university professor Oguz Tosun, and dug through some resources:
The bug map provides a simple 2D visualization of the bug’s causality chain, thereby exposing the root cause. But this is only after having the bug map fully visible, and the fog cleared. As promised, I’d like to share the best practices I learned from books, articles and most importantly colleagues on how to clear the fog. Continue reading Clearing the fog
In a previous post, I laid some groundwork for debugging, and promised follow-up posts. This promise is long overdue, so let us continue with what I call a “bug map.” Continue reading Bug map
SW-intensive systems are quite complicated. When they are not working as expected, this complexity increases even further dramatically. This is where debugging comes in, and a solid methodology is essential in approaching systems of such complexity.
In a series of posts, I’ll try to summarize the debugging methodology I have picked up from trainings, books and of course colleagues. In this first post, I’d like to start with some theory as I couldn’t find a good summary on the web directly fitting to my purposes. Those who get bored with theory ;-) are welcome to jump to the end of this post for the definitions of symptom, root cause and excitation, and continue to the upcoming more practical posts. So, here goes…