Murphy's bookshelf

September 04, 2003

MurphysLaw-September 04, 2003

Take a break from slaving at your computer and read. Here are some books that just might reinspire your engineering mind.

This month, I want to tell you about some books that have influenced me over the years. The books I've chosen aren't about programming, but are about other topics that have influenced me as an engineer. If you're interested in the programming books that I like, you'll find reviews of them at www.panelsoft.com/books.htm.

The Code Book
The Code Book by Simon Singh chronicles the history of code making and code breaking.[1] Singh emphasizes points in history where the cracking of certain codes changed the course of military history. Mary Queen of Scots passed coded messages from imprisonment in the south of England, hatching a plot to overthrow Elizabeth I. When the messages were intercepted, not only was the code broken, but new messages in the same code were constructed to help lure Mary into revealing more information about the identity of her co-conspirators. As a result Mary and a number of co-conspirators were executed.

Mary Queen of Scots used an amateur cipher and paid a heavy price. More professional ciphers were in use at the outbreak of World War I, but that didn't prevent the cracking of a communication from Germany to Mexico, encouraging Mexico to wage war on the U.S. The discovery of this collusion was pivotal in coaxing the U.S. into the war.

There are also stories of the triumphs and downfalls of the codebreakers themselves. One of Alan Turing's greatest achievements was the cracking of the German Enigma machine during World War II. However, the secrecy surrounding his work meant that he received no support from the military establishment when he was persecuted as a homosexual, treatment which eventually led to his suicide.

In addition to the stories of war and intrigue, the book explains the methods of making and breaking codes in terms that make a complex topic accessible. Along the way the author challenges the reader to use the techniques he describes to crack a set of problems. He also bravely offered a £10,000 prize to anyone who could successfully decipher the final challenge. This prize was claimed over a year after publication by a group from Stockholm.

This book appealed to me partly because code breaking is an abstract practice, much like writing software. When I'm working on a function that sets the amount of oxygen delivered to a patient, it can be very difficult to really see the connection between my arbitrary collection of while loops, if statements, and look-up tables and the relief a patient must feel when the right amount of oxygen is delivered. Singh's descriptions of code breakers in Bletchley Park during World War II conjures up similar images of people working through intercepted transmissions, trying to establish a pattern in the encrypted message. While some of the codebreakers were England's finest scientists and mathematicians, others were recruited after winning a crossword competition in the Daily Telegraph. It must have been a surreal experience for the codebreakers, finding themselves holding such an important role, without having to face the frontline. I imagine it was hard for them to easily form a real understanding of how directly their work was altering the fate of lives on board warships and submarines as their transmitted movements were revealed. This is where Singh's style of switching from the subtleties of the cryptographic algorithm, to the lives of the codebreakers, to the political or military consequences of the broken code, and back again forms a holistic view of the world of code breaking that wasn't visible to any one player involved at the time.

I found similarities with writing software at another level. Cracking a code involves hunting through a sea of numbers for clues. This is like hunting for a bug. Both can involve long investigations in the wrong direction that can frustrate hunters for hours into the night, and, once solved, can make you feel humbled as you realize it should have been so obvious all along.

Angle of Attack
In previous columns, I've used Angle of Attack by Mike Gray as a reference for some incidents that happened during the Apollo program.[2] This book is a revealing account of the engineering and corporate struggles that went on within North American Rockwell Corp. as they built the Apollo spacecraft under a contract from NASA.

One tragic event in the Apollo program was the death of three astronauts at the launchpad during a trial countdown. The atmosphere in the cockpit was pure oxygen and many pieces of Velcro decorated the walls as a useful way of making items stationary in zero gravity. It's still uncertain what caused the spark, but the oxygen fed the fire and the fumes from the burning Velcro suffocated the astronauts.

The death of these men was a tragedy, but the book is also scattered with references to engineers who suffered heart attacks or divorce due to the enormous work pressure the space program exerted on them. Kennedy said the U.S. would put a man on the moon by the end of the decade, and it was taken seriously. The lives of many engineers were probably drawn short by their involvement in this project; but not for them a congressional inquiry or posthumous honors.

Gray makes many references to engineers getting the opportunity to build something that didn't have a military objective. Many of these engineers spent their careers designing jets for the U.S. military and, therefore, were much more motivated to build something with a more altruistic goal. How many of us stop to measure how much more we get out of our job when we feel the goal is noble? I've worked on intensive-care life-support equipment and on some dodgy get-rich-quick schemes during the dot-com boom (unfortunately I was never the one getting rich), and while the hours or money may not have varied much, how I felt at the end of the day certainly did.

Another interesting lesson in this book is about how rewards and punishments aren't always attributed to the most deserving engineers. The central character of the book is Harrison Storms, who oversaw the development of most of the Apollo spacecraft and then was fired after the launchpad tragedy that killed the three astronauts. NASA needed a sacrificial lamb, and Harrison was the woolliest looking fellow around. Although Harrison and his team had objected strongly to the use of pure oxygen in the cockpit, it wasn't enough to save him. As is often the case in engineering tragedies, the blame is distributed according to political priorities, with little regard for real root cause.

Stones of Aran
There's a small island to the west of Ireland, about 50 miles from where I live. It's a barren stony place where the locals farm and fish, and, more recently, make a few Euro from the tourist trade. It's one of the few places in Ireland where you still hear the Irish language spoken on a daily basis. Writer Tim Robinson chose to live there for a year in order to write about the history of the island.

Robinson's book, The Stones of Aran: Pilgrimage, takes the reader on a tour of the coast of the island in a counterclockwise direction, visiting each beach, cliff, and rocky outcrop.[3] He describes places where locals lost their lives stealing birds' eggs from cliff faces, where seaweed was gathered to be used as fertilizer, where one or more local fishing boats met a watery end when washed up by an Atlantic storm. Life was very hard on the island, and children grew up expecting to have to work hard to eke out a life on this rocky spot.

Each year the locals gathered a large amount of seaweed to be used as fertilizer, some of it on the island and some exported to the mainland. Once gathered, the seaweed was reduced to a mash—the form in which it was shipped and used. This transformation was not easy. The seaweed had to be boiled in order to reduce it, requiring a large fire that was kept burning for several days. Firewood was scarce on the island, so the fuel for the fire was peat cut from the ground. The peat had to be gathered in huge quantities to keep the fire burning.

There came a point where agricultural thinking about the best way to use seaweed as fertilizer changed. Instead of reducing it to a mash, it provided just as much nourishment to the soil if put out raw. The market value of exporting the mash collapsed—the demand was now for the raw product. The need for the enormously labor intensive job of reducing the seaweed had gone. However, it was years before the islanders changed their practices. Part of the reason was the sense of losing a tradition, but a greater factor was the islanders' reluctance to accept that something they had put so much effort into in previous years had, in fact, been a pointless exercise. Cognitive dissonance is the term for the way in which a person's judgement is affected by the investments of time and effort already made.

Is there a lesson for engineers here? I think so. We engineers should always question new methods, but be careful to not let our judgment be clouded by the psychological effects of our past efforts.

A programmer who has invested a large number of hours in learning every intricacy of a programming language will be more inclined to believe that this programming language is better than the language that only received a portion of his attention. An engineer who has honed his assembler skills so that he can optimize code well might be reluctant to accept that a C compiler may be able to do the job just as well, with a fraction of the effort.

Niall Murphy has been writing software for user interfaces and medical systems for ten years. He is the author of Front Panel: Designing Software for Embedded User Interfaces. Murphy's training and consulting business is based in Galway, Ireland. He welcomes feedback and can be reached at nmurphy@panelsoft.com. Reader feedback to this column can be found at www.panelsoft.com/murphyslaw.


  1. Singh, Simon. The Code Book: The Secret History of Codes and Code Breaking. London, England: Fourth Estate, 2000.
  2. Gray, Michael, Angle of Attack: Harrison Storms and the Race to the Moon. Penguin USA, 1994..
  3. Robinson, Tim, Stones of Aran: Pilgrimage. Harmondsworth, England: Penguin, 1990. .

Loading comments...

Parts Search Datasheets.com

Sponsored Blogs