Why Is the Phone on Fire?

Posted on by Alex O'Donnell

I recently picked up a copy of “If I Only Changed the Software, Why Is the Phone on Fire?” by Lisa Simone. What a fun title! I was looking for books on debugging methodologies for us embedded engineers. I know, 30 years into my career and I finally get a book on how to do this, seems crazy, but I finally did. It’s not that I want to learn how to debug, I’m pretty good at that now. I’ve spent a few years mentoring younger engineers and realized how much I’ve learnt, taught (repeatedly) and forgotten. I was thinking I’d just find the top 3 books and make a recommendations list. Amazon managed to find a short list, and this one sounded the most engaging.

The book took a few weeks to get here, apparently it shipped from Australia. I’ll never understand Amazon. I took a couple more weeks before I had some time to sit and read a few chapters. The foreword by Jack Ganssle was a very positive endorsement, Jack’s articles in Embedded Systems magazine were where I gained great insights in my younger days. The first nuts and bolts chapter of content was engaging and entertaining. I’m not sure I learnt anything, but was reminded of a few things.

The format of the book is a series of short mysteries, laid out like a whodunit, but focused on a team of engineers. The first one has a senior engineer tasked with taking over someone else’s project in the weeks before MP. The ramp up is going well until the PVT units hit the customers desk. Many good engineering practices are covered, including value of coding standards for readability and maintainability, code review, white-boarding, brainstorming, advanced debugger features. The mystery looks at cross functional groups, containing the problem between firmware, QA and CM. The problem manifests itself as a first time power-on issue with hints at configuration corruption. I won’t say more, but in 20 enjoyable pages, with chances for us to solve alongside our heroes, reviewing code, memory dumps and grilling QA on why they let this pass, we have a good refresher on debugging 201. I am sure the same content could have been covered in a dry, terse 8 pages, but I would have started skimming and maybe missed points, and assumed I knew better.

I think I’ll be reading a few more chapters from this, which is unusual for me because I normally just dip into text books, and seldom read them cover to cover. I would recommend this to anyone looking for a book on embedded debugging, especially those who are newer to the industry.

Leave a comment