Reviews for If I Only Changed the Software, Why is the Phone on Fire?: Embedded Debugging Methods Revealed: Technical Mysteries for Engineers

1. If only I read this years ago, tales from the lab bench

   Rated 5 out of 5 stars, November 12th, 2009

   This is debugging software as a story, NOT boring academic thesis.
   
   All can learn from it hobbyist to grizzled old timers (like me).
   
   
   Whilst quite a few of the scenarios I had seen myself over the years, this is well written and has the feel of what it is like in the 'real world' debugging software, that may have been written by someone else.
   
   Interesting tales on how to diagnose problems. Some I could see where it was going, but the story line keeps you wanting to go further.
   
   Background is we are ALL still learning, and from each other. None of us know it all.

2. The basic tool for any embedded programmer

   Rated 5 out of 5 stars, May 12st, 2009

   This was really great reading, and I really wanted the book to be much larger. The resulting list of things to do and not do in embedded programming and design, should be in every program designers toolbox.
   This book should be on the desk of every fresh from school program designer, and I'm sure the it could teach the old dogs some new tricks too.
   
   The examples used in the book was well defined and explained. A nice twist was the reference to parallel problems in the real world of firmware.

3. Nine great stories to improve your problem solving, debugging and testing...

   Rated 5 out of 5 stars, April 12th, 2009

   This readable, enjoyable and engaging book is a collection of short stories about a team of engineers learning to solve problems. The problems they encounter are technical, managerial and interpersonal, and all contribute to the hardware and software defects they must resolve under pressure, while managers and customers breathe down their necks and complain about time and budget. As one of the characters remarks: "Simple bugs can cause big, expensive problems".
   
   Each of the nine stories gives the team a new technical problem to resolve, but they will also have management and customer problems, and their ability to work together is affected by the personal relations within the team. Oscar has been made development team leader, and has to work out how to lead rather than just doing the technical work, whilst enduring "endless time-sucking meetings". How can he develop the skills of his team? Oscar's team - Josie, Ravi and Li Mei - and Eduardo the system tester must learn to work together within and across their teams, and to respect each other's strengths.
   
   Through the course of the book, the team find ways to improve their problem solving and debugging skills, and you - the reader - work along with them, examining symptoms, looking at code, drawing flowcharts, and suggesting solutions to the specific problem. You'll even get a hex-dump to explore. The team learns how to approach problem solving; the newest programmer in the team, Li Mei, builds up a problem solving checklist as each problem is resolved.
   
   Each chapter in the book starts with a real life example of a failure. The chapter then sets a scenario with a problem for the team to solve. The symptoms are related and the team try different approaches to investigating and resolving the problem, including an immediate work around and identifying the root cause, before implementing a solution. Verifying the solutions is always included as an important step - both a code review and testing by the developers before a system test, as well as learning how to improve so the same defect does not happen again. The chapter ends with a summary of what has been learned: Symptoms; Targeted search; The Smoking Gun; Debugging method used; Fix; Verifying the fix; Lesson learned; Code review; What caused the real life problem?; and References. An appendix provides a summary of Li Mei's problem solving checklist "Li Mei's List of Debugging Secrets". There is a full index.
   
   Who do I recommend this book for?
   Any tester, developer, team leader or manager in IT would find this book useful. Although the specific domain is embedded systems, that should not deter any one working in other domains from enjoying and profiting from this book.
   
   The examples and the debugging checklist are useful start points to anyone involved in investigating production or test incidents.
   
   The descriptions of the causes and symptoms of the different bugs provide interesting ideas for test designs to uncover those types of bugs.
   
   There is also useful information for improving our reporting of incidents - for example, there is a good explanation of the different symptoms and causes of failures that are hard to reproduce, differentiating between repeatable, one-time repeatable, periodic and sporadic events, each of which will have different symptoms and potential causes.
   
   The human interactions described provide general lessons for managers, team leaders and team members in different disciplines - in particular for testers seeing the system test team from the developer's viewpoint is useful.
   
   I recommend this book thoroughly, get it, work through it, and then make your own problem solving checklist. If you are a tester, use it to improve your testing. If you are a developer, use to improve you development and debugging. If you are leading a team, use it to improve your interaction with your team, and to improve their skills.
   

4. Systems Engineering Mysteries - solved.

   Rated 5 out of 5 stars, February 12st, 2009

   This an excellent book and the story-style is a breath of fresh air in such technical matters. As an old hand at developing embedded systems I was ahead of the solutions by the time I got to the exercise part. Despite that I enjoyed reading on in the chapters anyway and will keep this book to hand on my reference shelf. Lei Mei's list is very similar to my own list that I have used for nearly 30 years. I would reccommend it to all those who are in systems development (embedded or not; as the lessons could apply across the board). I was also gratified that the "Standards Matter" message was very strong in the text from the first chapter.
   

5. Not just for embedded programmers

   Rated 5 out of 5 stars, September 12th, 2008

   
   The title made me read this book but the way it's written meant I couldn't put it down. The strategies in this book could apply to any type of programming so if you're not an embedded coder don't be put off. The code was not familiar to me but were simple enough to follow with my development background. Investigation and problem solving techniques don't come naturally to all and I'm sure that this book could assist and inspire many programmers.