In this episode we will discuss why bug-hunters are scarce resources. And how to improve your skills to become a more successful bug-hunter, in the Embedded World.
I will give you my 7 main bullets to improve your bug-hunting skills to a new level.
Why do we need bug-hunters?
A successful hunter of hardware- and software-bugs is no profession or even education. Most of all educations are either ignoring the fact of bugs or they are simply assuming that you or others do not make errors.
The only thing you might receive or you are forced to experience is the training on the job. The knowledge about bug-hunting is mainly empirical. That means you need a lot of intention and also experience to become better. Many of us have undergo this painful and stony way.
This episode is about presenting you my experiences which I have collected over the years. I will tell you some guts to become a solid bug-hunter much more faster and more reliably. Moreover following these tracks might even let you think more consciously about preventing bugs at all.
What’s missing for bug-hunters?
Guidelines and the distribution of knowledge. There is no regular exchange of experiences and occurrences of failures. Most engineers only learn their from their own mistakes. However there are ten thousands of others who might share their experiences, too.
Even the more experienced engineers will take the chance to improve their own bug-hunting approaches. If they would need others! But there is no distribution. There is no sharing in a bigger audience.
I was confronted with a lot of bugs and problems within my professional life. Perhaps you’ve experienced the same. Let’s use this episode to share our experiences and participate from each other to become more effective and more efficient engineers.
Let’s take this opportunity and collect some bug-hunting approaches and learn from each other.
How to improve your bug-hunting skills
Use my list of seven bullet points to become a successful bug-hunter. These details are the result of more than two decades of bug-hunting and bug-prevention.
Two different general approaches to look out for bugs
- The destructive approach by instrumenting your code or drilling down the functions
- The Non destructive approach by comparing or jumping back in revision history and getting the big picture about the constraints and real requirements of the system
The detective’s mindset – feel the excitement of hunting
These are my six main factors of becoming a real detective:
- Collect facts
- Collect suspects
- Do not trust witnesses
- Create your own track
- If nothing runs, switch to Sherlock Holmes mode
- Play the devil’s advocate or Good Cop – Bad Cop game
Change your mindset and assume the system behaves correctly
- What’s wrong in your thinking if the system is correct?
- How do the code-path looks like if the observed situation is assumed as correct?
- Where is the thinking loop which prevents you from achieving the desired outcome?
Use internal resources and do not fight alone.
- Use your internal skill matrix.
- Expand your personal who’s who.
Do not underestimate the time for failure maintenance
Avoid time constraints and customer pressure. Bug-fixing costs time; very often a lot of time – which blocks you from other activities
Narrate your bugs and findings
Let others participate. Very often bugs are tried to be hidden. Especially then they are assumed as embarrassing or rookie-bugs. But do not be shy. Make the first step and announce your findings officially having the bigger success of the whole company in mind. See the Japanese approach of Best Practice Sharing, the Yokoten-kai (alternatively here).
There is no multitasking in human brains
Very often overseen, very often thwarted. Newest research have unveiled that every context switch needs at best 30 minutes to come back to the original position in your thinking. This is a call to all leading persons. Do not burn up your engineers’ brain-power by pushing them from one topic to another. Let them concentrate. On one issue. At one time. For at least 4-8 hours.
Now I’d love to hear from you what’s your experience in hunting bugs in software and hardware?
- How do you do bug-hunting?
- What are your preferred approaches for bug-hunting?
- What kind of challenges do you observe in being a bug-hunter?
Do you have a habit or usage that I didn’t list here? Or do you wanna agree or disagree with me about these approaches? I’d love to hear from you. Please comment on the show-notes at the embeddedsuccess.com/episode02. And let me know your experience, your thinking and what you’re using and how you’re using it.