Why read this post? To find out why you should buy this fabulous "biography" of Bell Labs, and to consider how a monopoly set itself up for extreme innovation.

Jon Gertner’s The Idea Factory: Bell Labs and the Great Age of American Innovation is tech reverie, business book, political thriller and a superbly researched history into how some of mankind's most profound technical innovations (semiconductors and the transistor, solar panels, lasers, communications satellites, cellular mobile and Unix...) developed from fundamental ideas into production and into normality.

It is an exhilarating and – to this engineer, at least – humbling read with an appealingly comfortable feel to it of the book almost having written itself.

A history of people, biography of a formula

The narrative follows the giants of Bell Labs from their induction into AT&T to their passing: insightful Claude Shannon and incisive William Shockley, the genial instigator John Pierce, the politically adept scientist Bill Baker and a cast of thousands working within the innovative innovation structure constructed by the angular visionary Mervin Kelly.

Kelly’s formula is the leitmotif running alongside those histories. Both culturally and architecturally, it was about ensuring happenstance. Scientists were meant to be unable to avoid engineers, chemists were meant to bump into physicists and the men who “wrote the book” to interact with those who “read it.” It was a theory of ivory corridors and canteens rather than towers.

Hearteningly for small-fry like me, those who shared lunch, labs and projects with the Giants are also called out by Gertner for their contributions as lab technicians, metallurgists, engineers, project managers, chemists or physicists. There is always that sense of perspective that the products initiated by the Shockleys and Shannons of the Bell Labs world really needed input from each and every member to take them to production.

He didn't mention the cooks, though.

The invisible enthusiast

Jon Gertner is a journalist who has written for the New York Times and – less promisingly, perhaps – is editor-at-large at Fast Company*. This is his first book, up to now his largest undertaking by far. He spent five years building up this story - and it doesn’t show.

Not once did I feel the weight of his research, nor the burden of history, whilst reading The Idea Factory: the research and painstaking editing behind it is transparent. Gertner writes precisely yet lively, reflecting perhaps both the industrial-academic environment he describes and the local aspect of his endeavour: he grew up near the slightly mysterious, legendary Bell Labs headquarters at Murray Hill and his need to write this story comes across as being personal. Thankfully he found the energy and made the time to write it.

A monolith of innovation

AT&T enjoyed and, in pushing the boundaries of legislation, abused its monopoly position to maintain its role as “The System”. Those researchers and developers thrived within a massively integrated firm with the manufacturing might of Western Electric (which lovingly crushed or bought up many competitors in the past), the financial momentum of the phone operator (equally crushing), and the laboratories that drove the organisation to higher margins as well as higher callings (in not just the telephone sense…)

The calling to innovation as a justification of monopoly is the fascinating twist on our perception of this otherwise shimmering paragon of development. Teams that innovate need to get grubby, they need to ensure they have the best people and should “Never underestimate the importance of money.”

Without mass production, sales and distribution, no product may be considered to be innovative – so all of those tedious tasks surround, and can occasionally swamp, a product as it moves onwards to the market.

Notational Philosophy

The story behind the invention and development of the transistor would be worth the price of entry all by itself. But Gertner embellishes it with such lovely, pertinent little details that the reader can find thoughts spinning off in unexpected directions. One gem is the rigorously maintained notebooks used at Bell Labs. Each team member was required to write down thoughts and events relating to a particular case (or project, as we would call them now). Walter Brattain's notebook, number 18194, relating to his work on semiconductors (case 38139) continued on page 40, after 4 years of interruption through the Second World War, with: "The war is over."

There are other notational quotes in the book: from Morry Tanenbaum, as he closed in on discovering how best to manufacture layers of p-type and n-type silicone for the transistor: “will try direct approach…” (he melted an aluminium wire through the top layer) “This looks like the transistor we’ve been waiting for.”

These notebooks are - handwriting permitting - legible now, and are exceedingly well archived and organised. Will we be able to say the same of our loosely-managed files and cloudy projects in another sixty years? On the other hand – how searchable are those notebooks? Who can extract the knowledge that they contain, as well as the narrative, without knowing them intimately?

John Pierce – my new role model?

Although less well known (to me, at least) than the “transistor guys”, I felt an immediate affinity to one character that was totally new to me, John Pierce, of Telstar Satellite fame. “An instigator is different from a genius, but just as uncommon,” writes Gertner. “It was probably accurate to say that Pierce had too many ideas to actually pursue on his own, and too many interests… to focus on any single pursuit.”

Ah, I know this feeling only too well.

“’I tried to get other people to do things, I’m lazy,’ Pierce once told an interviewer.

‘Do you think this has helped your career?’ the interviewer asked.

‘Well, it was my career,’ Pierce replied.”

Pierce was a catalyst within Kelly’s formula of deliberate entanglement – wandering into offices with a bit of an idea and “just” starting things. It’s something that really should be encouraged, and perhaps remodelled in the virtual world, given how few offices are actually connected back in the real, normal world.

Moving on (looking wistfully back)

The book ends naturally with the passing of the golden generation and the fading into normality that is more poignant than any dramatic burn-out and crash. Gertner offers his thoughts on the meaning and lessons to be extracted for today’s Googles and Microsofts, for the myriad of startups gunning for their lunch – and for mere mortals like me.

Firstly, he considers whether swapping a factory of ideas (Bell Labs) for a geography of ideas (e.g. Silicon Valley) can match the muscle provided by monopoly. It’s close, perhaps, but, for all the advances that Silicon Valley has given us, in comparison with Bell Lab’s output, it has been largely incremental.

Secondly, he wonders if there is a way of escaping monopoly and government involvement in basic research at all. Here, he points out that “77 of the 88 U. S. entities that produced significant innovations were beneficiaries of federal funding.”

The concept of government involvement in anything brings with it the perception of incompetence, but Gertner summarises research into research with this:

“Creative environments that foster a rich exchange of ideas are far more important in eliciting important new insights than are the forces of competition."

White shirts and ties - the key to innovation?

Amidst all the deeply scientific and creative thinking going on at Bell labs during the “wonder years”, one constant appears to have underscored the whole process – everybody wore white shirts, and ties. Some eccentrics were known to go sockless in their shoes, but the fundamental aspect of Bell labs appears to have been the shirts.

My wardrobe consists of perhaps three white shirts, one of which is my wing-collar concert shirt for orchestra: it hardly brimming with scientific rigour.

So, when knocking on other peoples’ doors we should clearly be wearing crisp white shirts.

Hmm… a hint of sartorial determinism there? Perhaps Kelly has a better take on innovation:

“It’s the interaction between fundamental science and applied science, and the interface between many disciplines, that creates new ideas…”

This book is simply worth reading, and is worth reading again. So once you’ve got it, read it and lent it out, make sure you get it back…! 

*(5 amazing lists on the habits of 8 of the most productive ’10 of’ list writers in business today, to click you cleverer” would be a headline, even if that's only four lists)

I never wanted to be a doctor, nor could I ever be a surgeon. It's one of those inexplicable things - you can tell me over and over again that the components that make up the human body each have their (vastly more basic) equivalents in engineering: structures, pumps, tubing, fluid mechanics, control systems - but I can't get past the whole "blood" thing. I'm squeamish.

(Others, fortunately, aren't) 

Equally, I find it uncomfortable sometimes to think about our environment, and our impact on this world we inhabit. And if you read too much about it all in the press, it's easy to sink into worry, to feel helpless, powerless.

Squeamishness and worry have no place in medicine, nor in studies into the state of our environment. The only way to work effectively in those fields is through immersion: in the data, in the testing and analysis, in the nuts and bolts of it all. The only way to demonstrate your care and mastery is by results, not by emotion.

The authors of Sustainable Engineering, Dr's. David T. Allen and David R. Shonnard, have very successfully eliminated emotion from this work.

That is a compliment, of course, and I am sure they would see it that way, too. The book is not a cheery, superficial case of "engineers to the rescue!" Instead, Allen and Shonnard are the sober and cool-headed experts, completely immersed in and at ease with their field, able to bandy about and work with numbers like humankind's 450 quadrillion BTU energy consumption in 2006, or use of over 120 million tons of iron per year, without apparent effort, or drama. In this way, they call to mind astronomers contemplating the size of Antares - and with this book, they are setting the framework for us to join in that conversation.

The language used in the book is unsurprisingly far from conversational. For that, we would need to turn to equivalents such as David MacKay's Sustainable Energy without the Hot Air. Sometimes it borders on the heroically dry: ("a methodology was used that first defined a system to evaluate, estimated environmental releases, determined exposure to sensitive human and environmental receptors,and calculated damage to human health or impacts to the environment.") Overall, though. the authors manage to remain comfortably in the background - which is an admirable achievement on such a potentially flammable topic - in order to present the data and methodologies of engineering for sustainability.

The structure of the book is logical, but somehow overly so. Having the basics at the beginning and the case studies at the end makes sense, with the build-up in between, but I felt that some re-jigging of the chapters would have helped better to engage their readers, engineers like me, thinking impatiently: "great, very interesting - but where's the engineering?" Whilst it's true that this is principally a text book rather than a reader, the structure is perhaps even a little old-fashioned, stoic, even.

By their very nature, the trawl through the "meat" chapters in this sustainable sandwich of a book - Risk and life-cycle frameworks, and Environmental Law and Regulation - is particularly hard-going. The information and methods to be found in there can be extremely thought-provoking, such as a medical risk assessment of cancer through benzene exposure versus being a married or unmarried male, or charts showing the explosion in number of environmental regulations, but it's a dreary trudge nevertheless. It would have been better to dissipate the effect, I feel, by interspersing these chapters with the engineering ones. Also, perhaps as an aside, and considering that the overwhelming majority of readers is likely to be students, the life-cycle analysis of disposable versus cloth nappies (diapers), whilst undoubtedly a classic example, is perhaps not the most relevant Allen and Shonnard could have chosen. Perhaps the subtext of "life goes on" was intended?

Chapter 4, with the slightly awkward title of "Green, sustainable materials" (does the word "green" belong in this context? It strikes me as more of a journalistic term, rather than an engineering one - but perhaps today's student would feel otherwise), is really an extended life-cycle analysis dealing with the extraction and disposal of materials. Again, it contains some fascinating thought-starters that reward the careful reader: gasoline, for example, is easy absorbed by soil (which sounds bad). Ethanol and MTBE, both additions in terms of trying to improve air quality - MTBE reduces CO output - on the other hand, are less easily absorbed and so are more likely to seep through the soil to reach water sources, and so can pose a greater direct environmental risk in that scenario.

Only in Chapter 5 (of six), "Design for Sustainability…," do we encounter the engineering process, along with the best summary of what the authors want the reader to understand: "The goal of sustainable engineering design is to create products that meet the needs of today in an equitable fashion while maintaining healthy ecosystems and without compromising the ability of future generations to meet their resource needs." The chapter deals with the design and costing of systems and components according to the principles of Sustainable Engineering (there are nine of them, according to Sandestin, or twelve if you're a disciple of Anastas and Zimmerman). These 12+9 principles are listed and described at length, causing a certain glazing of the eyes and reinforcing the idea that this book is to be treated as a reference rather than a recipe.

The key phrase, perhaps of the whole book, is also to be found in this chapter: "…anything that can be measured can be improved." In essence, life-cycle or risk analysis is a simple matter of multiplying and adding huge or tiny numbers. Emphatically non-trivial is finding what those numbers are. Here, Allen and Shonnard provide an excellent portal into the arcane world of environmental, medical and chemical factors.

The biggest resistance to engineers really starting to work according to the 12+9 principles will be the finding, testing and approving all of the relevant environmental parameters before they can begin to measure the current state of environmental affairs for their product, or even hope to measure the effectiveness of changes made. Convincing management to invest resource and money in these will be difficult - the hope is that it won't only happen via the negative pressures of ever-increasing regulation and fines.

In the end, this is an important book that deserves its place in the engineering body of knowledge. As the authors themselves state, the methods of design and engineering for sustainability are not yet mature, not crystallised into procedures and workflows; it is not by a long stretch the "normal course of business."

From my own experience, environmental considerations are largely ad-hoc and regulations-driven. How we as an engineering community implement design for sustainability as the normal course of business rests largely with our colleagues in academia for now. Once the methods and evidence of gains seep through society into industry, the upcoming generation of engineers should simply not have to think about it. They will have become immersed.

Now, the final question has to be: is it more environmentally sound to buy Sustainable Engineering as an ebook or on paper…?

The book for reviewing was provided by Pearson North America with no strings attached save that I produce this post. That I gladly did, although it took far longer than I had intended. Still, we got there in the end!

Have you not noticed a book recently? Forgotten that you were reading whilst you were reading? That’s the author’s ideal: their books should melt away whilst you are reading them, so that the content transcends the medium and becomes the event.

Can this happen with a technical book? Honestly, I don’t believe it can; technical books are so full of references, tables and figures, footnotes and diagrams that you can not escape their structure, their architecture for long. I could briefly get lost in an alloy phase diagram in “Engineering Materials”, but I couldn’t read the book page for page, for hours on end like I could a Julian Barnes or an Iain M. Banks.

An engineer’s job does (or at least should) include reading up on things, whether that be a new book or browsing the web for information. This being an engineering blog, I thought the occasional review of interesting resources that I have encountered might end up being something that I could write about. This is the first in this unforeseeably long or short series or reviews.

The book that kickstarted this whole thought process was one I came across as background reading for my post on whether Software Engineering is Engineering: it was the ebook How Google Tests Software

How Google Tests Software (HGTS) was written (developed and compiled, perhaps?) by three gurus in the art of software testing: James Whittaker, Jason Arbon and Jeff Carollo. In style, it is what could be expected of Google from an outsider’s viewpoint - quite chatty, breezy, somewhat at odds with the incredibly technical and mathematical work that they do. It is also replete with excellent word selection, suggesting that whilst coding is at the heart of their work, this trio is also at home communicating with people. Indeed, being bright and capable of communication is a key aspect of their respective rises to the upper echelons of Google (and, in Whittaker’s case, Microsoft) management. James Whittaker certainly has literary form, having written “How to break software” and “Exploratory Software Testing” prior to HGTS.

In truth, and from my perspective thankfully, HGTS is only semi-technical. There is not much in the way of code snippets or significant jargon; it’s more a case of using dialect (“dog-fooding” for internal pre-Alpha software testing, for example). The book reminded me a little of the classic aerospace book “Flight without formulae” {Link} in that there is a minimum of code and a maximum of description. This suited me down to the ground. Someone in the software development world may be disappointed at not having chunks of test code to try to understand or to try out, but this book describes in a lively way the key principles of how to manage testing, how to manage testers and how testing has to become integrated both into the product and into the company itself. This makes the book worthwhile reading for software developers, I’m sure - but also for us.

The essential message of the book is entirely relevant even at my mechanical end of the engineering spectrum: it is that {software} testing and quality must go hand in hand with development.

In the book, we learn how Google went so far as to kill off the group called “Testing Services” and to resurrect it as “Engineering Productivity.” More than merely a rebranding, the switch ensured that the software developers were testing their new code all the way through the development process: the Productivity Team gave them the tools to do so.

Software testing consists of several levels, from quality checks on portions of code, through to logic and functionality tests on components and upwards to full interdependent systems and finally user testing.

Equally, there are several levels of test engineer involved: there is the SWE (Software Engineer), who principally develops code, but also tests the same code for “low-level” bugs. There is the SET, the Software Engineer in Test, who aids the SWEs in writing test code and the frameworks for such testing, and finally there is the TE, the Test Engineer, who is involved in the user-side testing of an app or a site.

The test team is kept small by design, making it a limited resource that thereby keeps a large enough balance of responsibility on the side of the SWEs to keep things as bug-free and as smooth as possible. The idea is that if Testing were to become a huge department, like in the bad old days, software quality would become worse, not better, since SWEs would once more feel released from the constraint of having to consider testing and quality as being an integral part of what they create. Google (as would any other company) would slow down to become a bureaucratic monster, no longer nimble, no longer smart.

The sheer complexity of what the testers do is incredible and totally beyond my ken. Tests that range from small to enormous, automated bots that trawl websites for bugs, whole tracking systems for bugs: these are all impossible creatures for me.

Intellectually, though, they become analogies and hints for improving our own ways of working. Let’s take the structure: We have technical, production and quality departments: why not eliminate the quality department as we know it and create a Productivity Improvement Team? Indeed, why is quality treated separately? If we focus on productivity, we automatically have to eliminate quality issues. Google tracks bugs with Buganizer? Well, we could move on from quality catalogues (aka rogues’ galleries) to active tracking and destroying of our own quality stumbles - for everybody. Google trawls websites for usability issues? We could do much more collecting of warranty and benchmark data for our parts and those of our competitors. Google raises bug alerts on competitors’ sites? Hmm, well, perhaps that’s an analogy too far, but the notion of making our industry a better place is a noble one.

Google uses what they term the “ACC” Analysis methodology, where teams think through Attributes, Components and Capabilities to determine an initial test plan for that product for each instance where a component is broken or a capability not met. That is, they think through what would happen and how a user would be affected if a particular component were suboptimal or broken, and assess how frequent that type of failure would be. It all sounds very similar to the FMEA methodology in our world.

Tellingly, though, Google doesn’t seem to let itself get bogged down in documentation or specifications. “…I suppose there is some fairytale world where every line of code is preceded by a test, which is preceded by a specification. Maybe that world exists. I don’t know. But in the innovative and fast-paced world that I live in, you get what you get. Spec? Great! Thank you very much, I will put it to good use. But… demanding a spec won’t get you one… Nothing a spec writer … can do will help us find a problem that a real user will encounter.” 

I would be interested to know if Google needs to pass audits in the same way we do.

Google can be very clear on how it should manage clever people: “…I am a big believer in keeping things focused. Whenever I see a team trying to do too much, say working on five things and doing only 80% of all five, I have them step back and prioritise. Drop the number of things that you are doing to two or three and nail those 100%.”

So - the way Google has set up its development teams with quality at their heart, then set up productivity teams that provide the tools for quality to succeed sounds like a benchmark for us to meet.

These and many more are the lessons to be drawn from How Google Tests Software. I would certainly recommend you delving into the book for even more on how to recruit clever people, how to work with barefoot managers, and how to ensure that jobs and roles are not entities in themselves, but part of a community in their own right.

Could Google learn something from us? Well, if Google really wanted to know how to bog itself down in administration, they could always learn from us and introduce PPAPs to the software world. That would help, I’m sure.

And: did you not notice your browser there for a few minutes? If so, then it’s a sign that this post was in some way or other interesting; if not, then you probably disappeared down a few tangents via those links - the very nature of blogs and the internet (or your browser crashed…)