Read This Book!

Do you remember that Jack Nicholson movie "As Good As It Gets" from the late 90s? Jack tells Helen Hunt "You make me want to be a better man." That is how I feel after reading this book, it makes me want to be a better software engineer. The information in this book encompasses things that I have done throughout my career but organizes them in a way that really pulls it all together.

Full disclosure, I work with John. However, I bought the book with my own money and I would not write this review if I did not mean it. The only way that working with John influenced me is that it allowed me to know about the book.

First, the title is great. You probably already realized that. If you are going to do good software engineering, it is about good patterns. John and Wayne are not the first to say this. The title reminds me of the classic software engineering book "Design Patterns" by Gamma, et al. BTW- It also reminds me of the Police album title "Ghost in the Machine". That was good album too, (Every Little Thing She Does is Magic and Spirits in the Material World).

Second, the style of the book is very engaging. I am sure we have all read software engineering books that are very dry. These sorts of books have good content but they do not keep us interested. This book reads like what it is. Two brothers who have worked in the embedded software field for many years and are sharing their collective wisdom with a bit of humor. To get a quick taste of this wisdom and humor, I recommend starting with Chapter 17, The Tao of Development (The Tao means "The Way" or "The Path"). For example, John's Rule #1: Never trust the software guys. So many projects in my career would have been better if the project leaders had taken this rule to heart. It's not that we don't want to have things go perfectly to plan but as John says; there are bugs, we are terrible at estimating effort, software developer priorities do not always align with the program manager. That leads us to John's Rule #2: Software is not soft, it's hard. Meaning, doing good software is hard to do. Wayne's rules are also spot on. I particularly felt #3; All software resists shipment and #5; A working prototype is everything and nothing.

The primary content of the book is very well organized and walks the reader through the steps of building embedded software. Here is a description from the introduction. "Patterns in the Machine is an amalgamation of design methodologies, best practices, software architectures and continuous integration principles which, when applied to the embedded development space, deliver projects faster and with higher quality." Bottom line, the book is practical. You can use the techniques in your work today. The methodologies in this book exceed the practices that I have typically seen in the following ways: 1) using the described Main pattern to build in a functional simulator with minimal effort as the actual code is being built, and 2) truly reusable code through the use decoupled interfaces within the software, from the hardware and from the compiler.

The core concepts of the book go chapter by chapter and lead up to a fully worked out example with source code available on GitHub.

• Design Theory for Embedded Programming

• Software Architecture

• Unit Testing

• Functional Simulator

• Continuous Integration

• Data Model Architecture

• Finite State Machines

• Documentation

One thing I particularly like about the book is the approach to design documentation. As we all know, in medical device software things need to be documented. However, I have seen documentation constructed for the sake of documentation after the software is nearly complete. This is a waste of time and adds no value. The approach in the book is that the design documentation is your flexible idea space that allows you to diagram and think about the software before the software is written. As the book says, Document First, Then Implement. Side note, this does not imply a waterfall model. The book is agnostic on the waterfall vs. agile debate. The book merely says that if you are going to do something like a feature or an interface, work it out in the documentation first and then implement it. A document is much more flexible than code. The book does not recommend that you write the code details in the documentation though. That is too cumbersome and prone to getting out of sync with the actual code. The book instead recommends that you treat your header files like data sheets. The code details can then be pulled out with a tool like Doxygen for the final documentation package.

There is so much more I could say about this book but you don't need me to say it because you are going to read the book as the title of this blog post suggests.