Book Review: If I Only Changed the Software, why is the Phone on Fire?

This blog post is a review of the book “If I Only Changed the Software, why is the Phone on Fire“, (see more information on Amazon, for example), by Lisa Simone. The book was released in 2007, on the Elsevier Newnes imprint. It is a book about debugging embedded systems, written in a murder-mystery style with a back story about the dynamics of an embedded development team. It sounds strange, but it works well.

The style of presentation in the book took some getting used to. Each chapter covers a real-world incident in a short note before and after the chapter, and then the main text describes an artificial problem and how the people in the book go about solving it.

The book actually has a story, with a cast of characters. It is about how Li Mei, a new developer fresh out of university, joins a team at the fictional company Hudson Technologies. She joins Josie, Ravi, and their boss Oscar, and learns how to debug embedded systems from her more experienced colleagues (and teaches them a few things to, such as being systematic about how you go about debugging). This way of describing each case actually works well, as the author can introduce various typical other characters from the world of embedded systems, such as annoyed managers, anxious customers, and irritated users.

The bug issue in each chapter is presented step by step, and the reader is asked to try to figure out what it is before the book reveals it. It really has a murder mystery feel to it, where you get the pieces of the puzzle and need to figure out how it all fits together. When I read it, I tried to figure out the answer to each problem before it was revealed – and in all cases except the somewhat messy final problems involving interrupts it was quite easy. Guess I Must have learnt something from programming for thirty years.

At first, I was a bit put off by the use of artificial examples instead of real world bugs, but it actually works very well. In this way, it is possible to expound typical classes of bugs in a way that is clearer than using real-world examples and without the confidentiality issues associated with such cases. The amount of work that has gone into constructing the bugs is very impressive, and it seems that the author has gone to the effort of actually implementing them and making them (incorrectly) run on actual hardware. Impressive.

The book is clearly written as a course book for teaching undergrads how to debug. The author even built a course around it, even though it seems that this was abandoned in 2010. The course materials use a TI MSP 430 microcontroller along with an IAR Systems tool chain, which confirms my overall feeling from reading the book that it is targeting smaller embedded systems.h

Bugs involving 8-bit overflows in variables is rare in the systems I usually work with, and it does make the book feel a bit dated today. I think a modern compiler would have caught a couple of the bugs at compile time, but the principles are still sound. Another missing component is multicore truly-concurrent software, even though the use of interrupt service routines in several examples approximate the effect of multiple processing cores. However, the book is from 2006-2007, and at that time, this was much less of an issue.

Overall, this book was an enjoyable read, and maybe I can borrow a bug or two as debugger demos. But it is not a book for an experienced embedded developer who wants to learn more advanced debugging techniques – it is more about the nature of bugs than the nature of debug techniques.