Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 468

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 483

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 490

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-settings.php on line 526

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-includes/cache.php on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-includes/query.php on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /data/55/1/150/3/1639166/user/1767119/htdocs/phoneonfire/wp-includes/theme.php on line 618
Real Life Debugged » Book Publicity

Archive for the Category ◊ Book Publicity ◊

Jack Ganssle’s Review of My Book
Friday, February 27th, 2009 | Author: lisaksimone

JackGanssle presented a book review of my book, If I Only Changed the Software, Why is the Phone on Fire? in his latest Embedded Muse Newsletter #174.

An except from Jack’s review:

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!

And yes, at one point in my sordid technical past, I did have to debug a very hot phone.

After successfully (I hope!) hiding the problem from potential customers at an international trade show in Singapore. Thankfully, the phones were displayed on marble tables - very good for heat dissipation between hurried demonstrations!

Subtitle: “An Author’s Relationship with Amazon, Google and Search Engine Optimization (SEO)”

I admit, when the book first came out, I was so antsy to see it on Google. In the beginning I was secretly disappointed to keep finding it behind pages and pages of cell phone battery horrors … “Girl burned when cell phone catches fire” … “cell phone sparks fire that leaves California man severely burned.”

But after the the book came out and gained publicity, my attitude (and my mental status) buoyed happily seeing it at or near the top of search results. Then at international Amazon sites, and in lists in industry journals and college libraries. And the reviews - I printed out page after page to save for posterity!

But … my amusing and somewhat sarcastic writing style didn’t win me this international publicity. Nope.

It’s all about Google and Amazon. And SEO - search engine optimization.


Thanks to my publisher, Elsevier/Newnes, the first chapter of the Phone on Fire Technical Mysteries is available online! I am including a link to it here, and also to the Elsevier website.

Excerpt from Chapter 1:

It was an odd-looking line of code, awkward in its form and syntax, dovetailed between well-formatted lines that marched up his computer screen. The pleasant left-and-right rhythm of indentation was marred by this single line, positioned brazenly flush with the left margin.

Not appropriate at all.

It was the offending line’s placement that first caught his attention, as if it had been cut-and-pasted by mistake. Closer inspection added to his unease. The original author of this code was not the author of this line - a hack interloper had destroyed the beauty of this software. Oscar raked a hand through his hair as he pulled his focus away from the individual characters and syntax and let awareness of the code’s function flood his brain.

It was a command to store a block of data into memory.

He scanned the comment section of the function and found no reference to the change. He wasn’t surprised; someone writing sloppy code generally didn’t pause to add comments.

But could this line be the source of the emergency, the reason why he’d been summoned back to work at 10 p.m. last night? And then spent the day alternately hunched over a lab computer and being dragged into various managers’ offices to estimate when he could fix a bug that he hadn’t yet had time to understand?

Three days before the final hardware and software were to be finished and delivered to manufacturing, the display on the Friend-Finder Communicator device suddenly turned red.

For no apparent reason.


Find the entire chapter here - with my shameless permission to link to it as well!:

Chapter 1) The Case of the Irate Customer - Debugging Other People’s Code, Fast!

This is a shout out to Jason Andrews from Cadence who mentioned the value of embedded systems, debugging, visualization and verification as cornerstones in technology going forward. Everything seems to be tied to everything else, and we all need to get our heads out of the cubbyholes (aka cubicles) and take a look at better and more comprehensive ways to solve problems.

Jason also gave a nice plug to If I Only Changed the Software, Why is the Phone on Fire?, and for that I thank him. He mentioned that we share a common publisher, Elsevier/Newnes with his book Co-verification of Hardware and Software for ARM SoC Design. With hardware and software merging closer and closer together as time goes on, we need to be more cognizant of the challenges of verification. We can’t design, develop, debug, or test in a vacuum any longer. Check it out.

This new book manages the unthinkable - it conveys crucial technical information to engineers without boring them to tears! …

Unique format casts the reader as a technical detective by presenting a new mystery in every chapter. Not another dry technical book! It’s conversational tone and intriguing quandaries draw the reader into the action, while teaching crucial debugging skills.

Read the rest of the review here.

I received a very nice review from ECN Magazine - the reviewer couldn’t put the book down!

Lisa Simone has done a wonderful job explaining software debugging for embedded-system designers, and I highly recommend her book. Simone uses Hudson Technologies, a fictional company, and several main characters, Oscar, Josie, Li Mei, and Ravi to take readers through nine chapters of debugging dialog.

The dialog, which adds realism and some tension to the stories, shows what software developers go through in realistic situations, from debugging poorly written code to tracking down problems with interrupt service routines.”

Dialog is tough to create, but Simone writes well and quickly connects readers with the cast of characters at Hudson. The dialog makes the book easy to read. I decided to tackle a chapter before lunch and went through four chapters in one sitting. I haven’t had as much fun with a book about programming in a long time.

Read the rest of the review here.

Visit ECN Magazine.

William Wong from Electronic Design Magazine writes,

Great title and a good read too, especially if you like stories from the trenches. Simone does more than just revive old ghosts. She brings out the debugging techniques in context.

This storytelling-approach helps you remember the techniques. Even expert programmers with plenty of debugging background can read the book solely for its educational and entertainment value, possibly even picking up a few useful tips along the way.

Debugging is still an art, not a science. Simone attempts to bring some rules and reason to programming.

The narrative approach is used throughout, except for the appendix outline of debugging secrets. Many are common sense or ones usually picked up with experience but some may surprise you.

And yes, one of the chapters is entitled If I Only Changed The Software, Why Is the Phone on Fire?

The review can be found here.

Ever get stuck, not knowing how to fix a hand-held calculator or cell phone? Then check out a new book by Lisa Simone, PhD, of Bridgewater, an assistant professor, at New Jersey Institute of Technology (NJIT).

If I Only Changed the Software, Why Is the Phone on Fire? (Elsevier, 2007) offers step-by-step, easy-to-understand information about how to debug small and large electronic products ranging from pocket calculators to cell phones.

“Debugging is the process of removing bugs and problems from software and devices,” said Simone. “It is a valuable skill for anyone working in a technical field like engineering. Unfortunately, it is difficult to teach debugging, and most people have to learn through experience, which can be time consuming and frustrating.”

The book introduces readers to real-world technical mysteries of progressive complexity, guiding them toward successful solutions. Simone hopes the audience will be for the general public as well as engineers. “I’ve created a fictional company with a cast of engineers. The engineers tackle real-life software and hardware technical problems while upper management and customers hover nervously.

The book shows engineers faced with technical mysteries and products behaving badly. In one instance, a new software engineer uses a newly-developed monitor to measure her own heart-rate. To her surprise, her heart-rate has mysteriously doubled. She and a senior colleague brainstorm to find the bug. Eventually, by eliminating hardware and software parts, they fix the monitor. The book’s final chapter offers a summary of smart debugging techniques introduced throughout the text.

Simone’s idea for the book grew from realizing while working in industry that students, developers, computer scientists and engineers often don’t know how to solve problems.

At NJIT, Simone is developing a portable low-cost glove for functional hand measures that can be worn by victims of stroke or traumatic brain injury. The National Institutes of Health is funding the research. The device will help researchers, physicians and therapists assess the degree of injury and methods that might help patients regain mobility. Other current projects also focus on using wearable embedded systems and technology to help rehabilitate people with physical disabilities. Simone’s research has been published in six peer-reviewed journals and she has presented at 13 prominent conferences. She received her PhD in biomedical engineering from Rutgers University.

The Press Release can be found here.

For students, Lisa Simone is a dream professor.

She uses the latest technology to teach her classes and her students work in teams on hands-on projects. She arrived for a recent class, for instance, carrying bags of ice, lighters and heat guns, which she used to help her students design devices for temperature detection.

In another of her classes, students use LEGO Mindstorm kits to build robots that perform simulated surgeries. The class meets in a biomedical engineering studio where students work together on interactive projects.

Simone is young, friendly and adventurous. Her idea of fun is to frolic underwater with a school of sharks. She’s an avid scuba diver who has traveled the world photographing marine life. Sneaking up on napping sharks and snapping their photographs gives her great joy. Photographs of marine life adorn her office wall.

She is also a writer. She’s just written a new book — a high-tech thriller in which software engineers act like detectives, forever on the hunt for bugs: software bugs that can cause computer-based products to crash and burn.

The book — If I Only Changed the Software, Why Is the Phone on Fire?– teaches students and readers how to contend with software bugs.

Software engineering is a subject Simone knows well.

Before coming to NJIT in 2006, she worked as an embedded-systems engineer for Lucent Technologies and Motorola. She led teams of engineers who worked on innovative cell-phone technology. Her teaching is informed by real-world experience and she treats her students as if they were actual engineers developing cutting-edge technology.

In the below interview, Simone discusses her teaching, her book, her research projects as well as main passion in life: scuba diving.

Why did you write a mystery novel about problem solving, embedded systems and debugging?

I didn’t want to write a boring textbook about debugging. Instead, I wanted to make the learning fun, so I decided to use mysteries to teach problem-solving skills. Since most people learn debugging through experience and since people like mysteries and stories, I created a fictional engineering company with engineers who have to combat a series of 10 technical mysteries - kind of like CSI or Law and Order for engineers. The company has a cast of new and seasoned engineers, and the book is filled with machines that crash and a phone that catches fire.

My goal is to tease the reader with a series of symptoms, clues, and realistic bugs and provide logical steps to help the reader learn what could be wrong with the software and hardware. The book includes many common types of software bugs, and introduces both traditional and nontraditional debugging methods and testing. Students need to understand that problem solving is a logical process that isn’t that difficult to learn.

I based the mysteries on my actual experiences, and I hope the book will help students and people working in the field gain experience debugging code. I’ve started to use the book in my graduate class, Intro to Embedded Systems, and the students say they like it.

Tell us about the engineers in the book, and why readers might like to read about engineers solving technical mysteries?

I wrote the book to be fun. I’ve tried to make it as realistic as possible, from the way problems are found and reported to the engineers, to the way managers tend to react, which is “this must be fixed today.” The Hudson Technologies engineers — Oscar, Josie, Ravi, and Li Mei — are a fairly typical engineering team: they have flashes of inspiration and at other times bang their sleepless heads on the bench. They feel pressure to nail the bugs amid sometimes frustrating team dynamics, missing tools, some difficult customers and a stressful trade show demonstration. I want readers to identify with the characters so they understand what it’s like to work in industry.

Why is it important for students to know about debugging software and embedded systems?

Most people don’t know what an embedded system is, even though they own dozens of them! An embedded product is anything with smarts - with a computer or microprocessor embedded inside - like a cell phone, a remote control, an iPod, or even in once humble products like toasters. Since more and more of these devices have software in them, they often have bugs which can be challenging to figure out. Software errors are estimated to cost the U.S. economy $60 billion a year. Software bugs in medical devices have killed patients. Student engineers who will design, build, or test smart products will face debugging challenges. Effective problem- solving skills will make a student a valuable asset to any company.

How do you expect readers to use this book?

The book can be enjoyed in a number of ways; it was written for folks of all experience levels from students and new engineers to seasoned technologists. Each mystery provides a “Day in the Life” for folks curious about working in industry. Each mystery stands alone, although the Hudson team is the thread that weaves the stories together. In my preface to the book, I invite readers to write in the margins and work through the examples to solve the mysteries before the team at Hudson Technologies does. Or, just glide along with the team as they tackle one technical mystery after another.

I hope that readers get caught up in the mysteries and that the team’s tricks come floating back out when readers find a similar bug or symptom in their own technical travels. I also included an appendix with a nice summary of bugs and tricks in each mystery.

How long did it take you to write the book?

The book took about 18 months to write part-time, in two chunks. I started the project around 2002 but got busy with research, and a few years later picked it back up again when I joined NJIT. From the beginning, I had created a very detailed outline of each mystery. I am an extremely driven and organized individual, so when it came time to actually write the book I just filled in the blanks.

I loved writing the book! There were some stressful times, such as when I had to produce the three final chapters in about 6 weeks before classes started last fall, but also some wonderful times writing at my kitchen table with a cat on my lap, a few writing marathons in Florida, and a productive stretch at a sidewalk café in Chicago that had free wireless access, a supportive manager, and great beer.

What was your biggest challenge in writing this book?

The biggest challenge was to make the technical mysteries realistic and fun for readers of all experience levels. Real-life engineering problems and believable people. Thanks to my father I am a good technical writer, but this was my first big foray into fiction. I am an avid reader and I found that plot and dialog came pretty easily, but my biggest challenge was perspective or point-of-view. Normally a book is written from one person’s point of view - you’re in their head - you hear what they think and see what they see. But I wanted to get into the heads of all of my fictional engineers so my readers could identify with each. I ended up taking a chance and changing point of view multiple times in each mystery, so each of the team members is a main character at different times. Hopefully now my readers can identify with at least one of the characters to make the mysteries more realistic.

How do you like teaching biomedical engineering at NJIT?

I love it. I run the Capstone Design Program for seniors who are biomedical engineering majors. I’ve been able to redesign that program and make it much more rigorous, project driven and applicable to the real world. I’ve worked in industry for years, and I treat the seniors as if they are engineers in my big engineering design firm. I teach them how to design for the real world, including all the real-life experiences working with difficult customers, writing documentation, submitting invention disclosures and performance reviews. Stuff they don’t expect to learn in college.

You teach several engineering classes and do research at the same time: isn’t this challenging?

Research is challenging but also rewarding, especially in medicine and rehabilitation, so I will always try to balance research and teaching. The people who participate in my studies have suffered brain injuries, but they are excited to help my team develop new methods and therapies, even if those discoveries don’t help them directly. Their enthusiasm is inspirational and one of my subjects emphatically told me he would do anything to help my research efforts: “You can paint me pink and stick me to the ceiling,” he said, “if it helps someone else who has a stroke.”

Tell us about your research projects at NJIT?

I have some neat research projects, and I have five master’s students who are assisting me and I love working with them. In my lab, we design low-cost systems to treat patients with movement disorders that happen after a brain injury, such as a stroke or traumatic brain injury. With funding from the National Institutes of Health, I’m developing a wearable sensor device for the hand called the Shadow Monitor; it helps understand how people use their hands after an injury. Why is this useful? Doctors and researchers know patients with the above injuries often struggle with daily tasks like dressing and eating, but we don’t have good tools to measure and find out which therapies help them the most. With our device, we can observe hand use over 24 hours, and evaluate how well rehabilitation is helping patients regain their hand functions.

We’ve also combined Second Life, the online 3D interactive world, with the Wii Remote game controller, to create a low-cost virtual reality game that patients can use to regain control of their arms.

You are a scuba diving instructor who travels the world photographing underwater shipwrecks and marine life, including some potentially menacing ones, like sharks?

I love scuba diving because when you are underwater there is not enough room in your brain for the stress of daily life. Your senses are overwhelmed with the sea and its bountiful life. We’re the outsiders underwater, but brave sea creatures will check us out if we respect them. Once while diving, I happened upon a baby octopus. I stuck out my finger. He wrapped a tentacle around it and tugged. I suspect he was assessing how big of a threat I presented. After a few tugs, he must have suddenly realized I was larger than he thought and instantly zipped away. I have danced under water with sea lions, twirling around as they tugged on my camera and fins. After nearly 30 exhausting minutes of tumbling play - we humans are much less graceful underwater than they are — I was rewarded with a sea lion kiss. Brave and curious sea turtles have stared me down for a moment, and swam off. Swimming through huge schools of barracuda, salemas and jacks — thousands of fish swimming in a tight ball — makes you feel insignificant.

One of my favorite dive sites is Truk Lagoon near Guam, the site of many WWII shipwrecks. The wrecks are full of supplies, ammo, tanks, torpedoes and small airplanes. (Our dive master told us, “be careful not to bang your dive gear on the torpedoes - they are still live.”) On the Fujikawa Maru, I swam down through the engine room, out of the hull and right through a torpedo hole - the one that had sunk the ship. The shipwrecks are wonderful to explore, but you can’t help feeling sad for the soldiers who died.

And yes, I like sharks. Sharks are pretty cool - I sneak up on white tips and nurse sharks to snap pictures as they sleep - the best shots are right after they wake up! Shark feedings in Fiji and Tahiti can get frenzied, and we’ve collected sharks teeth afterwards. While diving in the Galapagos Islands, I have swum beside massive 40-foot whale sharks and their 15-foot long babies. One of my shark adventures I still can’t tell my mother about. It started with a few silky sharks (they’re like the trouble-making teenagers hanging out on the corner), but evolved into a circle of 35 sharks - with me and another diver in the middle. That’s the only time I’ve ever wondered if they can smell fear through a wetsuit…

(By Robert Flordia, University Web Services)
Read the rest of the interview here.

Book Premiere

Author with Dave, an interested reader at the Embedded Systems Conference

I’m here at the Embedded Systems Conference in San Jose and the official premiere of Phone on Fire! If you are in the field and have never been to an Embedded conference - you need to go. What a great collection of vendors, classes, and seminars!

The Phone on Fire book signing was a great success - it was the top-selling book in the Elsevier booth. I met several great people who were surprised and intrigued by the idea of using a mystery format to teach debugging skills. I was also surprised to learn that Phone on Fire is Elsevier’s first book of fiction! Lisa and an interested reader, Dave, and the Elsevier Booth. more…

Category: Book Publicity |  Tags: | Leave a Comment