There are many techniques and processes that developers can follow in order to minimize the defects (bugs) that find their way into embedded software. No matter how carefully one develops their software, there is always going to be a few that sneak through and require us to troubleshoot (debug) the software. In this post, we are going to examine the modern troubleshooting techniques available to developers and develop a simple method that can be used to improve those skills.

Several years ago I got tired of spending 60% or more of my time troubleshooting software. During that time I intensely focused on learning techniques that could dramatically decrease the time I spent troubleshooting so that I could focus on more value added activities. In general, I found that there are eight troubleshooting technique categories that are available to developers. These include:

• Watches and expressions
• Break-points
• printf (terminal style text outputs)
• assertions
• Statistical profiling
• Data profiling
• Task and data tracing
• Instruction tracing

I’ve come to believe that the time spent troubleshooting is directly related to the mastery level that a developer has in troubleshooting techniques. I don’t have any hard data on this, but it’s an intuitive feeling that I get from speaking with hundreds of engineers across various industries every year. So how do we determine whether we have the skills necessary to be a fast, efficient bug squasher?

I recommend placing each of these skills onto a spider diagram similar to the one below but without the fancy graphics. Honestly look at each skill and evaluate on a scale from 0 – 10 your mastery of that skill. in this case ranking a 0 would be that you don’t use that technique. A ranking of 10 means that you have completely mastered and have nothing else to learn regarding the technique. I would suspect that many developers have close to 0 for instruction tracing and that most have a 9 or 10 for using watches and break-points.

Once you have gone through and ranked each skill, add them all up. Your skill level can be described based on the following ranges:

0 – 40 : Stumbling in the dark ages

40 – 60 : Crawling out of the abyss

60 – 80 : Fast, Efficient Bug Squasher

This number now gives you your overall skill level. The goal is to improve this score over the next several months. In order to do so, start at the top of the spider diagram and move clockwise until you find the first skill level that has a value less than 7. Focus on bringing that skill up to a 7 over the next several months. You may find that you need to do something like:

• Reading a book
• Finding white papers that cover the topics
• Take a course
• Practice debugging and implementing on a real system

There are many ways to improve your skills but the goal is to improve them. Get your skill level up and focus on decreasing the percentage of your time that is spent troubleshooting. In the end, you’ll find that you have far less stress, more time to focus on development and it will become easier to hit those deadlines that are always fast approaching.