9 Indispensable Rules for Debugging Software and Hardware (Book review) -

Attention embedded engineers! We’d like to invite you to sign up to EmbeddedHub.io, an exciting new space just for embedded engineers. Sign up early to be a part of the journey🚀

This article will give a quick overview of the book titled: “The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems” by David J. Agans.

Disclaimer: This page contains affiliate links which provides Inspirezone with a small commission if you make a purchase through us. This is at no additional cost to you and helps to keep inspirezone sustainable. See our full disclaimer here.

See the book here on Amazon (affiliate).

How this will help you as a software or hardware engineer

Debugging is a natural part of developing software and hardware. In some cases one may even spend more time debugging than the development part! To become more effective there are some rules for debugging software and hardware that can greatly assist in anyone’s efficiency in how they tackle any debugging task.

The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems goes through key concepts that can be adopted by any software or hardware engineer to form a systematic way of debugging.

Applying these rules in practice should improve how you approach debugging tasks and give you more confidence in tackling the more challenging ones.

We’ll go through the book in brief and cover some key takings. We recommend you read the book to get the full details behind each debugging rule. The book also covers some really fascinating (and humorous) real world debugging problems and details how the solution was reached. These stories help drive the point across on the importance of each of the 9 rules for debugging software and hardware problems.

The 9 rules for debugging software and hardware

1. Understand the System 📕

This rule is all about drilling in the importance of truly understanding the system you’re debugging. Do you have a basic understanding of what the software or hardware you’re looking at does?

Manuals, troubleshooting guides, datasheets, reference documents are all there for a reason. They are documents that will provide the information you need to know what the system should do and how it’s designed.

It makes sense that understanding the system is the first rule on the list.

2. Make it fail ❌

One of the first steps you should take in the debugging process is to witness the problem, i.e. make the system fail. It’s essential you can see the problem so you can analyse the system in it’s failing state. And more importantly, if you know how to make it fail, you can actually know you’ve fixed the problem if it stops failing with the fix included!

The whole point is, seeing the problem for yourself is crucial, so you’re not just working blindly at a problem. Also, don’t assume what can or can’t happen with the system, anything is possible!

3. Quit thinking and look 🔎

Never guess or assume you know what the problem is before you’ve done your analysis! You need to stop guessing and actually look at the problem before coming to a conclusion. That’s why you should quit thinking and look.

The importance of debugging tools is also explained in this debugging rule. During the development process, keep debugging in mind and ensure your system contains enough debug logs, LED indicators or anything else that will indicate the status of the system while running.

Also don’t be afraid to dive in with your instrumentation. Code debuggers, status messages oscilloscopes, logic analyzers… use whatever you need to analyse the problem.

4. Divide and conquer ⚔️

This rule describes a very useful technique for pinpointing the exact problem under investigation. By dividing and conquering you can split the system into parts and with each analysis pinpoint which sections of the system the bad behaviour is coming from.

By continuing to split the area of the system under analysis you will eventually narrow down to the problematic part. What you care about is the bad part of the system so start with the broken part and it will eventually lead to the cause of the problem.

5. Change one thing at a time 📑

You don’t want to make so many changes to the system when debugging that it essentially becomes a different system. We care about the problem that existed in the original system so change as little as possible during the analysis stage. And if possible, don’t change anything at all!

It also helps to compare a working system to the one that’s failing. This may help reveal the cause of the behaviour behind the problematic one.

6. Keep an audit trail 📝

This rule emphasises the importance of keeping track of all changes you make to the system as you’re debugging. Did you add in logs? Write that down. Did you add in a test? Write that down. A trace of your changes and any resulting change in behaviour will provide clues on how changes affect the system and may lead to discovery of the problem under investigation.

Also write up bug reports with as much detail as you possibly can give. “It stopped working at 9pm for 10 seconds” is better than “it stopped working”. Every detail counts, so create a trial to help with the investigation.

7. Check the plug 🔌

“Is it switched ON”? Said the support agent at the end of the phone. This cliché of a support agent asking such an “obvious” question is cliché for a reason.

Have you checked and checked again that the bare requirements of the system are met?

That’s what this debugging rule is trying to come across. Sometimes just checking the “obvious” is where you need to look.

Is the machine ON? Have you confirmed all components of the software are running? Are the light indicators ON to show it’s working? Has your car broken down or just out of fuel? Check, double check and triple check!

8. Get a fresh view 👀

If you’ve heard of the phrase rubber duck debugging then you pretty much know where this is going. Sometimes, just talking about your problems can help you solve them. Whether it’s to another human or a rubber duck…

This comes from the idea that by simply getting the opinion of someone else by running the problem through them, you can trigger ideas in your head that will lead you to releasing a new perspective on the issue. You may have experienced this yourself when explaining an issue to someone else you get an “aha” moment.

Of course, the person you’re explaining it to may also have some useful insight into the problem you’re facing, especially if they are an expert of the system under analysis. So don’t be afraid to ask others for help.

9. If you didn’t fix it, it ain't fixed 🛠️

Even though it’s tempting, don’t assume a problem has been fixed if you don’t know what fixed it. At some point we’ve probably been guilty of desperately changing code till it worked, and when it did work we don’t fully understand why it did.

Well this can be a dangerous game to play. What if the change simply hid the problem temporarily and it’s only a matter of time before it came up again?

Ideally, when you believe you’ve fixed something you should take out the fix, check it fails again without it. Then add the fix back in and confirm it’s fixed again. This will prove your fix really does fix the problem.

Conclusion

The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, is a book worth reading for anyone who deals with any sort of technical engineering challenges, whether software or hardware based. The 9 rules for debugging software and hardware detailed in this book are a solid set of rules to get used to following during debugging tasks.

If there was one criticism of the book I had, it’s that some debugging stories told contain some technical detail that may not be understood by people with a non-technical background. However, you can still follow along with the key takings of each story which outline the mistakes and learnings from debugging challenges that are told in a way that will stick in your mind.

Overall, if you’re looking for a book on debugging, this should be on your list. It’s easy to digest and the many stories provide great examples of how the rules for debugging software and hardware can be applied in practice. Knowing these rules and understanding the concept behind them will make you into a more efficient and effective debugger.

Consider buying the whole book to gain a lot more in-depth insight on each of these 9 rules for debugging software and hardware.