Lisa K Simone

"Phone on Fire" Technical Mystery Book

A few words from Jack Ganssle...

Foreword

The oldest known book about engineering is the 2000-year-old work De Architectura by Marcus Vitruvius Pollio. One historian said of Vitruvius and his book, "He writes in atrocious Latin, but he knows his business." Another commented, "He has all the marks of one unused to composition, to whom writing is a painful task."

Does that sound like the last ten technical books you've read?

Engineers are famous for being very bright but also for lacking basic writing skills. Yet writing is still our primary means of communication, so we buy heavy tomes created without the benefit of basic grammar and often bereft of a coherent structure. Storyline? Character development? Forget it.

Welcome to a very different kind of technical book. Lisa Simone's work isn't the usual dreary tome stuffed with arcane wisdom buried beneath paragraph-length sentences seemingly written by someone just learning English as a second language. This is certainly the first embedded book with characters. The first with action, and with interesting and cool stories.

Bad code that makes a phone burst into flames?

What fun!

This is a James Patterson-style fast-paced book with dialog as close to gripping as one can imagine for a computer book. Its uniquely embedded focus twists together elements of hardware and software just as we engineers do in our daily design activities. One can't be understood without the other. Code makes the hardware smoke. That's unheard of anywhere but in the embedded industry.

Lisa weaves stories around deep technical issues. She's teaching the way humans have learned for 10,000 years. Most of us fought off sleep with varying levels of success in high-school history classes. Who really wants to memorize the date of the First Defenestration of Prague or the name of Polk's vice president?

Yet now as adults we eagerly consume historical fiction (like James Michener) and real history assembled as a story (consider David McCullough). Cro-Magnon Grog taught his sons to avoid poisonous berries by telling them of uncles who died; the Old Testament was passed down orally as a collection of stories rather than a dreary recitation of facts. Not properly casting an unsigned char sounds pretty dull, but when captured as a story - the interaction of people puzzling out a problem in the real-life settings we can all identify with - we're engaged and we learn the important lessons better.

This book is more real world than the standard text. Lisa shows how people are part of the solution and part of the problem. The concept draws on an oft-neglected axiom of the agile methods: people over process.

Despite the stories and character development, this is a textbook of a sort. There's homework. When Lisa asks you to stop and answer a question, do so! Think. Reflect. Surely Grog asked his sons questions to make them consider the lessons he'd imparted. We learn best by such interaction. Readers of Watts Humphrey's brilliant yet ineffably dull A Discipline for Software Engineering either do the homework and see their skills skyrocket; or read the book, skip the homework, and get no benefit at all.

Buried under the lessons, Lisa derives an important zeitgeist, a design pattern if you will, that should guide us in our work. It's one of creating readable work products: use cases, comments, requirement documents, and more. Though we need not emulate her use of story development in writing a report, we should and must abandon our traditional use of tortured English. Write interesting documents. Be lively and engaging. After 2000 years, it's time to leave Pollio's legacy behind and realize that if our readers are confused, frustrated or bored by what we produce, we're history.