How to Become a Bug Squashing Connoisseur

I’ve said it before and I’ll say it a million more times, I hate debugging. It’s not that I don’t enjoy a good problem-solving exercise. After all, I am an engineer. The problem that I have with debugging is that it’s the wrong problem to be solving! Instead of adding new features, differentiating the product, or doing other productive work, I’m stuck toiling away trying to discover what I overlooked. Debugging wouldn’t be so bad if it weren’t for the fact that on average, embedded software engineers spend 40% of their time debugging! On an average yearlong project, more than five months are spent debugging! So, what can developers do to become bug squashing connoisseurs?

There are certainly many things that can be done to prevent defects in the first place. But at the end of the day, engineers are only human, and they are going to have to troubleshoot their software. In order to effectively debug an embedded system, there are eight primary debugging techniques that engineers need to master. These include:

The degree to which developers have mastered these techniques will determine how efficiently they are able to debug their software. Developers need to evaluate themselves and determine where their skills may be lacking and put in place a plan of action to shore up their skills. A simple way to do this is to take the eight debugging techniques and put them on a spider plot similar to the one shown below:

A developer can then rank themselves on how well they have mastered each technique on a scale from 1 – 10. I often tell engineers that this is not the time or place to be humble. Ranking yourself a nine because there is always room for improvement can skew the results. If you’ve mastered break-points, which I hope everyone has, then a 10 would be assigned to that technique. If a developer has never used Task and Data Tracing or knows very little about it, they would give themselves a 1 or a 2. 

Once each skill has been evaluated and ranked, a developer can do several things. First, he or she can rank their overall debug skill level. This can be done by adding up all the values and arriving at a total between 0 and 80. If that score is between 0 and 40, the developer is stumbling around in the dark ages of debugging a real-time embedded system. Developers in this range are typically using traditional techniques, such as watches, break-points, printf, and assertions, but not using any modern debugging technique. 

Developers who find themselves with a score between 40 and 65 are crawling out of the abyss. These engineers have started to discover modern techniques that can dramatically decrease debugging time. But they have not yet mastered techniques like task and data tracing or data profiling, which can be a significantly important tool to master. Finally, if a developer has a score greater than 65, the engineer has become a bug squashing connoisseur. Those developers have mastered the modern debugging skills and should be able to use them to quickly track down issues with their software. 

Now, since most of us are spending at least 40% of the development cycle debugging software, we probably aren’t quite bug squashing connoisseurs just yet. The second thing that developers can do with their skill evaluations is to review and then identify the weakest two skills. Each developer should then create a simple plan of action that he or she will follow over the next several months to improve their skills in those techniques. For example, if my lowest ranked skill was task and data tracing at a score of 4, I may decide to improve that skill to a 7 over the next few months. I may decide to give up two lunch hours per week to devote to researching and experimenting with that technique until I can use it quickly and efficiently. No matter how a developer decides to proceed, it is important to set specific days and times in the calendar to work on improving that skill. 

READ MORE OF JACOB'S ARTICLES:

Embedded software developers have more techniques available to them today than they have ever had access to before. Mastering these techniques and employing them throughout the development cycle is critical to finding errors and defects immediately and minimizing the time that is spent troubleshooting software. I hope that you will take a moment to reflect on how well you know these debugging techniques. Set a goal to improve your knowledge and skills in your weakest areas so that in the coming months, you can decrease how much time you spend debugging your software. 

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost, and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees including a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.