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 » Phone on Fire Info

Tag-Archive for ◊ Phone on Fire Info ◊

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!

Cover Art: The Acid Flashback Big Reveal
Friday, January 16th, 2009 | Author: lisaksimone

Back when I was emailing Newletters to folks in the pre-production days, one of my anguishes was the book’s cover art. Now that I have recovered over the past year or so, I can talk about the whole trial less emotionally (… I lament in that totally weak wilty female whisper of delicateness while fanning flushed face quite rapidly).

** Rolls eyes **

Anyway, in Phone on Fire Newsletter #4, “Author Anguish,” I had relayed that the publisher forwarded three concepts for the cover, and that I had been underwelmed by all three. I also admitted,

One was downright awful. I think I used the phrase “acid flashback” in my feedback to the publisher on that one.

I refused to show anyone that concept. I think after all this time I will reveal the cover art that nearly scarred me with the idea that they were actually considering it.


“Phone on Fire” Foreword by Jack Ganssle
Sunday, December 14th, 2008 | Author: lisaksimone

Foreword by Jack Ganssle

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.


Should you read at your desk at work, or under the covers before bed?

This 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 is a window into technical team dynamics and provides a “Day In The Life” for folks curious about the field. Each mystery stands alone, although the Hudson team is the thread that weaves the stories together.

I invite you to grab a pencil and work through the examples to solve the mysteries before the team at Hudson Technologies does. Write in the margins. Think of other solutions. If you get stuck, work through the symptoms and the evidence side-by-side with Oscar’s team and verify what they conclude. Or, just glide along with the team as they tackle one technical mystery after another. (I’ll state upfront that none of the bugs are caused by minutiae like missing semicolons or misspelled variable names!)

While you get caught up in the mysteries, I hope some of the team’s tricks get lodged in your brain and come floating back out when you find a similar bug or symptom in your own technical travels. When that happens, check out the appendix - everything you’ve learned is nicely summarized with references back to each mystery.

It’s all about your approach to problem solving.

Make your next step a logical one instead of a random one.

This book also targets a very wide audience. Several types of folks will enjoy these mysteries. All kinds of engineers, students interested in science and technology as a career, technical and support staff who have to debug and understand embedded systems.

And maybe best of all - your FAMILY and FRIENDS! Never know what to buy for your favorite techies? How about a neat technical mystery book!


What’s in the “Phone on Fire” Mystery Book?
Sunday, October 26th, 2008 | Author: lisaksimone

What this book ISN’T

This book is not a hardcore textbook or a manufacturer-specific or toolset-specific “how to” book. It isn’t a book that becomes dated after a few years. It isn’t a book that guilt-trips you into reading it just because you bought it.

What this book IS

This book contains a series of technical mysteries for readers to solve. It’s fiction, and it’s nonfiction. “CSI for Embedded Systems” if you will. Machines crash, products catch fire - the engineers at Hudson Technologies race to fix the problems before it is too late!


Life breaks when you least expect it.

This blog shares all kinds of real life situations that need a good fixing beating. Typical stuff that goes wrong at all the wrong times. And how to have a little fun fixing them rather than running screaming into the night.

What was the impetus for these meanderings?  I wrote a collection of technical mysteries of products gone bad, and wanted to share them as humorous and interesting stories of how to solve these real life problems.

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

Through my years as an engineering technologist and product developer, I discovered we technical folks can always learn new ways to solve problems. “Phone on Fire” is a series of neat technical mysteries - like CSI-for-engineers - that reveals these skills in a fun-to-read format.

The book is both fiction and non-fiction, an interesting combination that challenges book stores to ponder which shelf it goes on. My publisher, Elsevier/Newnes, pondered the same concept. As a result, the book’s name grew somewhat unmanageably to allow Amazon and online search engines to find the book for interested folks seeking one or the other.

Authors are never completely in control of the name chosen for a book; unless, perhaps, if said author is Michael Creighton or Stephen King. So, stretch your mouth out to say the whole title, or as most of us do, refer to it fondly as Phone on Fire.

And what other interesting (and unexpected) publicity and marketing influences do authors find? I’d like to explore here as my journey continues in the Foreign Land of Book Marketing for Engineers.

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.

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.

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.