More than a few years ago, bordering on the “many”, I was invited to take part in a graduate selection weekend for Ford in the UK. It was a battery of tests ranging from one-on-one interviews and team-working simulations to presentations and problem-solving “incidents” – all nicely wrapped up in dinners and coffees in a pleasant hotel in the countryside.

One of the tasks – maybe there were twelve of them, I didn’t count – was to decide what equipment should be offered as optional, standard or not at all for a sporty Ford Escort model (these were the pre-Focus days), to meet a budget. We then had to write a report explaining our choices, needing to meet a most important deadline (lunch).

Being a bit of a car enthusiast, I made what I thought was a decent selection (including ABS and airbags as standard equipment), whilst keeping some budget for a few luxuries as standard (a CD player, I think), to differentiate Ford from, say, BMW, whose cassette tape decks were one optional extra, speakers to hear music from seemingly another…

Being a well-drilled undergraduate engineer, I wrote the subsequent report in the only way I knew how - with an introduction, a summary, a body and conclusions.

When I was given the job offer a few weeks later (which I took - a decision point that remains with me to this day, and is definitely worthy of a post of its own), Ford gave me some feedback over the phone. My presentation had been borderline terrible, but the report I had written was excellent.

In fact, it turned out that I had been the only candidate to actually write a report. Everybody else had written prose.

So, in honour of that, and in recognition of the possible fact that report writing remains for me, over emails and presentations, the main recipient of work related keystrokes, here’s my report on report writing in engineering.

TITLE

An Investigation into the enduring and endearing constraints of report writing

Author

The Literal Engineer

SUMMARY

The act of reading a technical report involves a certain mental effort. This effort should be rewarded with increased knowledge. In order to minimise the effort and to maximise the potential for knowledge extraction, the report writer should generate the report in as standard a way as possible.

The act of writing a report invokes a particular and peculiar mode of language, which itself requires a mental switch and effort to maintain, the passive voice. Writing in the passive voice lends the report an appearance (but no guarantee) of objectivity. A potential pitfall of the passive voice is the risk of the writing becoming stilted and unreadable. Yet this pitfall is deemed to present a lower risk to knowledge transfer than chatty and poorly applied novelistic writing.

Deciding on the tense remains difficult. The report should be written with history and evidence in mind; a report is a snapshot of the status of whatever is being investigated at the time, in this case – report writing. Using the passive voice is, overall, a positive constraint.

EQUIPMENT

Mid 2012 MacBook Air

2006 Rain Recording PC workstation with Logitech keyboard and mouse

Microsoft Word 2013 and Online

Microsoft Office 365 / OneDrive

Typepad blogging platform

Evernote note taking platform

Firefox and Safari browsers

1. INTRODUCTION

A technical engineering report can be understood as a window to a complex and meaningful event (or series of events) that took place within an organisation. The intended goal of a report is that its findings be understood. For this goal of understanding to be even remotely achievable, the report writer must describe the event in sufficient detail with sufficient brevity and clarity to form a synthesis of the outcomes of that undertaking. A report should therefore be  logically structured and legible.

Ideally, the summary and conclusions from a report should add to the great body of human knowledge. It is recognised, however, that, more often than not, reports must be produced to describe small-scale and often painfully regular events.

Regardless of where a report lands on the scale of import (or lack thereof) to humanity, the form and language follow traditional structures. Report writing in the technical fields is designed to enforce (the impression of) objectivity. The passive voice depersonalises the investigation and can be construed as an attempt to prioritise facts over individual actions.

I did not post this report on 30^th Sep.2014

rather:

This report was posted on 30.09.2014.

The tradition of using the passive voice imposes a constraint on the writer, which forces upon him or her (the passive voice at the very least enables authors to avoid the awkward distinction of the sexes) a mental switch and effort to make and to sustain the passive voice. This is an appropriate cost of entry, as the reader needs only recognise one style, whatever the source of the report.

2. THE STRUCTURE OF A REPORT

Reports are constructed around a common set of elements that may vary in style, format or order from organisation to organisation, but nevertheless ensure swift navigation to the pertinent sections or level of detail for the experienced reader - from an overall summary (usually to be found near the beginning), to detailed descriptions of equipment and methods used, via a logically structured body of evidence and discussion. The report at hand loosely follows such a typical structure and does not purport to set any standards with its own form.

It is also based on very little evidence.

3. THE CONSTRAINTS IMPOSED ON LANGUAGE IN REPORT WRITING

Actions and analyses leading to conclusions and summaries – no matter how breathlessly exciting at the time of their experiencing – are, in translation into a report, passed through a mental filter that compresses them into the passive voice.

This imposes a constraint on the author, which, similarly to the imposition of a recognisable structure on a report, lightens the burden on the reader (see Section 3.1 for more considerations on the reader’s role).

As in so many cases, especially in the arts and in engineering, this constraint can be viewed as overall positive: few physicists or engineers have been recognised as possessing the gifts of novelistic writing (or even spelling); honing the craft of the passive voice relieves these authors of many grammatical pitfalls.

The key to the passive voice, and the difference to novelistic writing, is that there are no characters or personalities to deal with. Someone or something does not do something to some other thing or person. Rather, some action is done to some object.

The strut was loaded into a tensile testing machine and its stress-strain curve was determined.

The sample was subjected to 60 cycles of cyclic corrosion testing according to specification X

The tea bag was placed into the pre-warmed cup. The cup containing the tea bag was filled to just off brim-full with boiling water. The assembly was left to stew for 4 minutes.

Humans act in all technical investigations, but the passive voice strips them out as being extraneous information. Whilst this is not always to be considered positive in most human relationships, being able to divide out the common denominators is, just as in arithmetic and mathematics, key to understanding the basic signals of what is being investigated. Humans, then, are a form of noise – in technical reports, at least.

Writing in the passive voice is a skill that must be honed with practice. For as long as the passive voice does not come naturally to the author, each sentence needs to be reviewed to ensure that the reader is not forced to stumble upon a person or a character rather than a description.

The implication of objectivity is valid. It doesn’t matter who did the test (especially in the sense of Professor vs. technician, or he vs. she): it’s not a diary. That information can be captured in lab notes, engineers’ notebooks, or the famous case notes from AT&T Bell.

3.1 THE BENEFITS OF THE PASSIVE VOICE

The passive voice is intended to portray the investigation as being impartial. This:

• enforces a certain mental discipline
• requires a certain mental “Umstellung” that brings the author into a standardised frame of mind.
• Permits the reader to read reports from any source in a similar frame of mind.
• Avoids “War and Peace”-style questioning of who was doing what to what other thing – no need to buffer names
• Personalities and their status are largely avoided
  • The facts and conclusions come first

3.2 DISADVANTAGES OF THE PASSIVE VOICE

• It is easy to “hide” the contribution of laboratory personnel, lower level engineers, and so on, to attribute the report to one “star” player. This is more likely to be an issue in the world of university, where academics are forced to publish on a regular basis – a quality investigation on a returned part is less likely to be the cause of professional envy.
• Can be stilted, can become impenetrable,
• Enforces the use of some awkward words or constructions

4. SELECTING THE TENSE

A key decision that needs to be made early on in writing the report, one which generates some confusion, even within one report, is the tense. Some decision aids are suggested as follows:

• Tests are described in the past tense: they were performed (“the samples were tested using the tensile testing machine at yy mm / minute”)
• Results are described in the past tense: “the stress-strain curve Fig. x.y was generated”
• Findings may be either in the past or in the present tense:
  • If a test was performed on a particular sample, e.g. investigating a failure, then the findings may be presented in the past tense:
    • “brazing of the joint was found to be incomplete”
• If a result was fundamental, then the findings may be presented in the present tense:
  • “the maximum tensile strength of the xx joint is YY MPa”

5. CONCLUSIONS

The technical report remains its own art form. Its art is knowledge and its form shall minimise the resistance to knowledge transfer. I really think that the passive voice helps to – oh, damn!

BIBLIOGRAPHY

http://www.sussex.ac.uk/ei/internal/forstudents/engineeringdesign/studyguides/techreportwriting

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!

When trawling the net and various books online for background to my post wondering whether Software Engineering is Engineering, I came across a book on how to teach software engineering (its name, like this clause, would only interrupt the flow of this post). I was only afforded the preview on Google Play (OK, I didn't buy the book), but one phrase I came across intrigued me, since it gets to the core of my thoughts on this blog. The phrase is this:

"Software engineering - the "engineering" of software - is part process, part technology, part resource management, and, debatably, until recently, part luck .... Learning to be a software engineer - learning about software - learning about engineering (the former, a nebulous topic, the latter an equally nebulous attitude of professionalism) form the target that educators are aiming to hit..."

Or, paraphrased: "Engineering is a nebulous attitude of professionalism."

I think that's a fabulous non-description, but it raises some interesting considerations, as that word nebulous - cloudy, vague, formless - bears so much information and insinuation. The word implies that engineering can be observed and classified but only billows around a probing grasp. It implies that the macro and the micro definitions of engineering are completely different: in the same way that clouds are made up of a myriad of droplets and the nucleae of those droplets, engineering is made up of myriad interconnections and dependencies. It's what makes engineering so potentially fascinating and so potentially frustrating.

Instead of trying to capture all of those influences in words, I decided to resort to the prototypical engineering fallback tool - a sketch. It's more of a brainstorm than anything defined, though: it's nebulous, made up of lots of droplets and is liable to change at any moment. Here's what it looks like today:

I'll keep refining it, but you get the picture. The form of your own particular cloud depends entirely on your engineering environment and whichever way the winds of development and commerce blow. Is engineering unique in this respect? Undoubtedly not - there are many more nebulous attitudes of professionalism - but it's a good thought-raiser.

And there's one thing that the nebulous analogy misses entirely: clouds don't produce paperwork.

You may use the picture for your own devices under a kind of CC license: Common Courtesy. A simple link and acknowledgement would be appreciated!