Why I'm writing this

Extracting something interesting to say out of what feels like a good - but perhaps vague - initial notion can be tricky and frustrating, especially for someone like this engineer trying to be philosophical about the engineering life. That's what happened when I was working on a now postponed post: I found myself getting stuck in the descriptions, on the surface, without finding a way to get satisfyingly deep into what I was trying to say: more drifting than drafting.

Then I remembered another (unfinished) draft from an (unfinished) series on engineering tools and I thought it time to put that tool - the Ishikawa diagram - to use.

The Ishikawa diagram

Also known as the fishbone diagram because of the way several themes jut out from a central theme's spine, this isn't as uniquely an engineering tool as the FMEA, but it is much used in industrial settings, mostly in the context of quality investigations. Looking back, I found a wry post of mine about it from back in 2012, where, whilst being more fixated on the overly literal depiction of the fishbone diagram, I listed out the typical topics for a quality investigation (the several 'M' words like "Machine", "Manpower", "Metrology", etc, as titles).

Fundamentally, it's about seeding ideas to be condensed around common themes to ensure that nothing obvious is overlooked when searching for a root cause. It's important to note here that it can also be an efficient tool, in that clearly irrelevant or non-contributing aspects can quickly be disregarded, allowing focus on the trickier stuff.

The Phishikawa diagram...

... or "Phishbone" diagram, is the philosophical version of the original. Its bones consist of key philosophical themes to aid in the search for the roots of the topics we want to consider. In this case, it won't initially be very efficient, as I'll need to spend time with each topic, these being:

• Ontology (attempting to describe how a topic is)
• Epistemology (understanding what we can know about the topic)
• Acting and working (understanding what modes of action and knowledge are involved - based on Aristotle's concepts of poiesis (making) & praxis (politics))
• Hermeneutics (how we interpret texts and artefacts resulting from this topic)
• Phenomenology (how we experience this topic personally)

This is what it looks like, in its first iteration:

(I used the fishbone diagram template in Xmind to create this version) I have also created a separate page for the Phishikawa diagram on this site, here

My hope is that using this as a form of mental scaffolding, I can construct a more detailed analysis of whichever topic I want to consider. But don't worry, I'll try to keep the text chatty and legible nevertheless!

The philosophical playoratory

I am, for reasons beyond my control, at present - yet hopefully “only” - between jobs: being out of my last job is a fact, and finding a next one isn’t (I’m working on it, and have a couple of potential leads), so uncertainty abounds.

I posted about how I feel about this situation on my personal blog over at Diversions Manifold. The philosophical aspect that I want to reflect on here is, now that I’m not working at an engineering company, whether I am also (again hopefully, only temporarily) out of engineering, and, because of that (temporarily) not an engineer.

Staying engineer

Without right now wanting to go down the rabbit-hole of trying to define what, exactly, an engineer is, we can at least posit that the two (engineering and being an engineer) are different states (being and doing): so I am and remain an engineer, but I’m not practicing it.

Briefly to the personal, I’ve been out of my job for nearly two months now, and it’s been tougher than I had expected. All that searching for appropriate new jobs, updating CVs and cover letters, preparing for interviews, accepting rejections, and the frequent switching between hope and - well, not despair, exactly - but certainly concern for the future, have taken a higher than expected toll on me.

But all that work on the CV, tuning each cover letter for each application and now having had a couple of positive-feeling interviews, has made me aware of the wealth of experience I can count on. This experience isn’t just “past”: it now constitutes part of me and my neural networks, enabling me to act in my own unique yet “engineeringy” way. Each item on the CV recalls the nous and the feel I have for the combination of techne and praxis, for the technical and the playful in my profession. Significantly, they all still feel “live”, accessible and deployable for whomever and wherever I end up working with and for. Each item hides, or signifies, a story. Not just “work experience”, but real struggles, achievements, lessons learned or buried for possible future connection to another event: bruises and scratches (usually suffered by mouse and text) that have formed me. Those learned paths haven’t, I feel, become impassable and atrophied in those two months out of practice.

Those same experiences are also devilishly difficult to describe to someone in an hour’s online first interview…

Hearteningly, I find myself looking forward to making use of those skills again, and haven’t entertained thoughts of trying out something else entirely.

So, to me, I’m still an engineer, and potential employers seem to concur. The other question was: am I out of engineering?

Not quite engineering

The one tech-adjacent hobby that I’ve been working on during my gardening leave that could be considered to be “engineering” is resin 3D printing of mouthpieces for brass instruments. Actually playing those instruments (in my case, the trombone), is clearly a different category of activity altogether - and combining the two is a fascinating pursuit.

At present, I’d say my 3D printing is at more of a craft stage than anything engineered. This is not to denigrate crafts at all: they most certainly require ingenuity and a feel for both the materials and what is to be achieved through them; they rely on internal impressions and learned pathways for the craftsman to interpret and “feel”, then to act - or react - at each stage of the process. In all honesty, that also describes rather a lot of engineering: the spectrum of crafts does overlap with that of the technical as well as of the purely artistic. In my case, I’m only now beginning to settle on a half-way reliable print setup that allows me to make design changes and print them without the permanent fear that they’ll fail; concentrating finally on the part itself without worrying about the printing process that goes into producing it.

So, although my equipment and materials have all been engineered to a high degree, my own use of them is not at an engineered level. My craft has not yet been elevated to engineering (I say this whilst bearing in mind that many crafts would be smothered by engineering).

My engineering self does have an idea as to what’s required to make the whole setup more engineered: having a good, reliable technical setup, selecting the best materials for the job, developing reliable tests and parameters to measure and compare each iteration, and gaining confidence in the information available to me.

Just that first point is complex enough, involving optimising factors like print orientation, support structures, UV exposure times, resin bed tilt rates and (quite key) temperature control. My current settings - and challenges - have all stemmed from not-quite-understanding what affects the quality or success of a print.

In philosophical terms, then: epistemologically I’ve been floundering to find the knowledge that will lead to success, still unable to transition between types of knowledge, from having a “gut feel” to a theory and procedure that will - all other things being equal - guarantee a successful print and product.

This is a very common engineering dilemma. We have nous - an idea that something works - which we can even specify in terms of parameters that should lead to a quality product, but we don’t usually delve back down “to the atoms” to understand precisely what’s going on in either theory or practice… until it goes wrong, our assumptions are challenged, and we have to learn new details.

Ontologically, it’s fascinating to recognise that I have converted concepts and ideas into 3D CAD files into sliced printer files into print jobs into actual parts (and surprising amounts of waste), then, on the basis of trials, updated the CAD files to continue the cycle until - still a goal - I have a satisfactory product… for me. After that, I’d have to be able to translate those parameters for other players, and players of other instruments.

Phenomenologically, I have interacted with computer and machine user interfaces, (hermeneutically) interpreted 2D renderings of non-real 3D objects into mental “understandings”, and then, finally, felt, tried and (unfortunately, in many cases) smelt the final product as they emerged from the whole production process, leading to a search for less pungent, officially biocompatible materials to work with, as well as for the “perfect” design.

Sounding it out

Leading on from the phenomenological experience of the part, the “true”, or “real” end of each 3D print is a satisfactory quality of the mouthpiece that’s been produced. Here, at the time of writing, I’m leaning heavily on my “ear” and on the personal feeling of playing a new, plastic mouthpiece, all the while comparing it (is it “better”, or “worse”) to my standard brass mouthpiece, to previous prototypes? That’s not an “engineer’s” way of understanding quality, and it’s far from being scientific. So I’ll also be searching for ways to standardise tests (involving microphones and sound analysis software, for example) which will still, no doubt, depend on me playing the instrument with the new mouthpiece in it. Can I define a standard embouchure and air pressure to play even a standardised sequence of notes in exactly the same way for each variant, like a golfer honing their swing?

Probably not, but I’ll try.

That’s the engineer in me knowing what’s required - but not yet engineering.

Admin it!

One aspect of engineering that I’m very far from with this hobby is the whole admin, bureaucracy and documentation aspect of engineering. Ultimately, engineered products are to be used by customers, so must meet norms and regulations, be economically viable, environmentally acceptable. So, even if I did end up with a technologically proven mouthpiece design, I have the feeling that, without a company behind it, it’s still a craft. Is engineering ultimately also an economic activity? It’s something to consider!

Working it out

Practically speaking, and to summarise: I’m out of engineering, but I still know what it looks and feels like, and feel able to rejoin the ranks of the engineers. Just wish me luck on that front: I don’t want to have to be too philosophical about being out of work…

So - these success stories we're talking about. They are where, exactly?

Click 'Go' to start

Where does FMEA belong?

Related articles

Please read this procedure

Fresh perspectives and fresh air in Detroit

Bridging the tumult and the oasis

Statistical data on global software development industry / market size

Sustaining and disruptive innovations

It is fair – and not in the slightest bit unusual – to say that we have been struggling to apply our resources properly of late.  My office is nominally dedicated to product development - but, with our well-appointed laboratories on site and our general level of expertise and "seen it all" experience, we've ended up having a whole pile of test and validation work to plough through, which, as I've pointed out in the past, I personally don't view as one of this engineering life's great driving forces.

{An aside: ensuring that your development team is focussing on its job is a perennial battle: a recent article in the Economist on the future of work points out a study done by Pfizer in 2008 which showed that its most highly skilled employees were spending around 20 - 40% of their time on routine work. Now, if I could even get up to 20% development work, I'd be happy...}

Roll up! Roll up! Become a validation engineer!

So - I want to be less involved in validation. This means I need somebody else to do it for me. I'm not a marketing type by any means, so enthusing about something that I despise doesn't come naturally - but I still need to think through how to "sell" validation to someone else. I need to think things through, which is the general point of a blog, unless I'm very much mistaken - so here goes:

• There are plenty of people who like little more than running around organising things - defining who needs to send what to whom and by when, then chasing up on all those leads.
• There are others who have the ability to create, track, update and check off tasks in lists.
• There are still others who enjoy the mechanical challenge of getting parts to fit into unnatural environments (we don't necessarily design parts to fit into test chambers)
• There are plenty of people who feel important when they get to put a "pass" or "fail" stamp on things.
• There are engineers who can lose themselves in reading and understanding specifications,
• And there are those who are happiest with the prospect of endless work without much in the line of variation.

A validation engineer needs to combine all of those attributes.

That's me in the mirror

So which of these attributes don't I have? Well - to point out the obvious first: I can work on validation (successfully, too, it would appear, as I keep on getting more of it to do!) - I've done it for year upon grinding year. I fail dismally at routine and at repetition (validation often requires testing the same set of combinations over and over, from different production locations or tooling sets, for example) and I really have to force myself into ordering precise numbers of components, counterparts, etc, force myself into counting the parts that arrived, and figuring out how to fit them into test equipment.

But it's largely a condition that borders on the philosophical - validation is at the wrong end of the engineering spectrum for me: it should be the crowning “dumb” step at the end of all the concept, specification, definition, understanding and testing work that constitute the development of a product into something produceable in series. It is validation as in rubber-stamping: this is a valid product; it does what it was expected to do, namely – meet specifications.

Meeting specification is the go gate for product in the "physical" world – not release into the market. We can't iterate as quickly as app writers can, but also smartphone apps don't generally have the potential to kill people if they go awry. So the biggest task for an engineer in the traditional industries is to write a cogent, coherent, consistent – and legible – specification that can act as a realistic hurdle and as a decider between good and not good product.

Then, other engineers need to read those specifications. Alas, the percentage of humans who have actually read through, understood and organised test work according to specifications is as vanishingly small as the number of people who actually wrote those specifications still being in that role.

Let's validate - something - quickly!

As soon as someone, somehow (often based on arcane and mysterious procedures – or company lore – or on a whim) decides that validation testing is required other than as the natural end of a development programme, chaos ensues.

Emails are sent expressing urgency, whilst tacitly acknowledging cluelessness regarding how actually to proceed; priorities are dumped on the already overloaded yet ever-helpful testing team – and above all, the sense of the emails is one of desperate hope. Hope that responsibility can be abdicated, that no further questions will be asked, that no sample parts need to be organised, that timing will be according to promises already made.

Of course validation is urgent, and of course it’s important – in our world you’re simply not permitted to deliver (or be paid for) parts that have not satisfactorily completed validation. It’s just that, for a development engineer, validation (as opposed to development testing) is dull, dull, dull.

There, I said it.

Finally, though, we managed to get some outside help, and we hired a student – more about which in the next post...

Related articles

Please read this procedure

Fresh perspectives and fresh air in Detroit

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

Perhaps I'll take him up on that idea - it's not a bad one at all. Welcome to a new hashtag: #validationzen

An engineer who knows the difference between literally and figuratively? Very suspicious indeed! Yet here I am, proudly rebranding myself as an engineer who also deals in words (and sounds, but that's another project). I've always needed to write, just as I've needed to nourish the technical aspect of my brain. When I'm at work, I'm, like literally engineering. At home and here in this blog I can be literally minded - thinking, reflecting and, from time to time, writing about engineering.

It's a big topic covering an unimaginable range of products, from things that we touch and use every day - to the arcane, that we rarely, if ever, see. And yet it's a small, parochial topic, too. Specifications, drawings, tolerances, materials - all of these need nurturing by us, the oft-unsung engineers, wherever and on whatever we work. And to do that, we need, like it or not, literally to use words.

So, here's my fresh start, with a fresh suit - which will need some nipping and tucking as time and wear go on. Let’s see where the journey takes us...

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)

Toyota helped to kick off the 2014 CES show by pronouncing themselves happy with the rate of development and cost reduction on Fuel Cell Vehicles: “Fuel cell electric vehicles will be in our future sooner than many people believe, and in much greater numbers than anyone expected.” Indeed, they intend to have a “vehicle” (by which I understand a car of some sorts) on sale by 2015

 Now, even with my occasionally shaky grip of arithmetic, especially in German that's NEXT YEAR. Whilst it’s usually better to look forward rather than backwards, the history of fuel cell vehicles is long and far from glorious, so it’s worth taking such pronouncements – even from Toyota – with a pinch of salt.

 Having said that, I've always been fascinated by fuel cell technology - as a naive young engineer, I somewhat irrationally invested in what in hindsight was a rather dodgy looking British-Belgian-Russian company called Zevco. This firm at least managed to get a fuel cell into a river boat, a taxi (a recurring theme in fuel cells, as a small fleet of taxis  created for the 2010 London Olympics shows) and an airport tug - before it folded, with the best of intentions to rise again. Admittedly, I wasn't the only dreamer out there, as Zevco managed to sign several alliances and intents of work before going under, with companies much richer than I – but there has never been a convincing commercial case for fuel cells. 

More recently, I was naturally keen to be involved in a project to develop the high pressure lines and connectors between the hydrogen fuel tank and the fuel cell. This was, alas, but from a business perspective sensibly, cancelled by our management as – well, quite simply, there wasn’t a convincing commercial case for it.

 
Money aside, key technical challenges remain:

• H₂ infrastructure (and figuring out where the energy to extract hydrogen should come from)
• Tank and system pressures of up to 900 bar
• Operating fluid temperature -40 to + 85 °C
• When the fuel cell is running at max power, it’s drawing the maximum amount of hydrogen from the tank, thereby reducing the pressure and cooling the feed system to sub zero temperatures
• System permeation & losses
• Sealing all the lines and connections in such a way that they’re quick to assemble and acceptably cheap
• Ensuring that you can leave a car in an airport car park for a week without it emptying of its own accord.
• Refuelling safety and losses

Even before sending cars out onto the roads, developing and validating the system is non-trivial as there are only a handful of test centres capable of handling the full suite of tests required. And they’re not particularly cheap.

The fuel cell endeavour seems to go in waves, with resources built up and then, like GM-Opel's team in Mainz, Germany, discarded. I personally hope that it works out. Perhaps the competitive and commercial might of Toyota, Hyundai, Daimler as well as a range of dedicated system suppliers like Intelligent Energy and Ballard, can result in a compelling case for the technology. But I  fear that, for want of a serious infrastructure, and the insurmountability of storage issues, it won't.

Still, give me a project working on carbon fibre fuel cell cars, and I’ll be one happy engineer…!

Lose Yourself to Engineering?

It’s fairly safe to say that 2013 was Daft Punk’s year. They brought out, to great hype, fanfare, and reviews their latest album, Random Access Memories, which made it into third place in The Guardian’s “Albums of 2013” list, behind John Grant’s Pale Green Ghosts in second and - in their opinion - Kanye West’s Yeezus in first (for the record)°.

I listened to Random Access Memories intently over the weeks following its release - and hated it. Then I loved it, finally settling for an awed respect. Nobody could put it better than Sasha Frere-Jones at the NYT: “The duo has become so good at making records that I replay parts of ‘Random Access Memories’ repeatedly while simultaneously thinking it is some of the worst music I’ve ever heard… Does good music need to be good?”

The opener, Give Life Back to Music comes across as an all-too respectful homage to 70’s funk, without adding anything to new to music at all. Yet, filter away the actual tune, inspect the nuts and bolts of the whole album and you’ll find so much to admire in the way it’s been assembled. It’s a damn fine engineering job.

Music is my main hobby, so with access to all the power that Cubase provides, I could conceivably compose and then produce something along those lines (though I emphatically don’t work in that direction).

Despite those bold words, though, I’m still fairly terrible at production, which is music’s engineering. A music producer (or audio engineer, as they are also called) has to work on ensuring that:

• voices (human or instrumental) have their own place in the mix,
• are clean and tidy, or dirty and scruffy, as desired;
• no frequency is overloaded, or uncomfortable to the listener

As I say, I’m not very good at it. Whilst I can appreciate a good mix, I tend to desensitise my own ears by overlistening to my own mixes, always wanting more (when less is by far the better way) andthereby muddying the sound to a point where it sounds acceptable to me on my own headphones, but is a disaster on loudspeakers, for example.

Music production consists as much of a workflow as product engineering does and goes something like:

• Audio mixdowns (exporting each track, whether synth, samples, humans or tubas into an audio file)
• Post processing:
• Panning
• Levelling
• Equalising
• Loudness
• Compression
• Distortion
• Reverb
• (and much more)
• Testing
• Ensuring that none of those frequencies are overblown
• Making sure no voices are lost
• Validation
• pre-mixes
• album-wide sound levelling
• Final mix
• mastering and publishing
• (gulp!)

For each step, the producers have a vast array of tools at their disposal for each step, but final quality control can’t be quantified away - it’s still in and between the ears.

Daft Punk had three things going for them in this intrepid exercise: lots of experience, a huge budget and a big team. Now, whilst the duo weren’t short of a penny or two given their back catalogue, it was still a massive investment on their part to go down the rout of maximising the human aspect of this album. It ended up being a massive, globally managed project, with all of the collaboration, communication and data transfer challenges that such an enterprise generates.

And all of that for, musically, a rather dull record.

It takes me back, perhaps controversially, to my days working as a packaging engineer at Ford. It was part of my graduate induction programme at the company and, if I’m honest about it, I felt that it was somewhat beneath me. Putting parts into boxes? What’s “engineering” about that, then?

All of it. It was, in reality, a complex puzzle that needed to be completed against time whilst ensuring the safe arrival of pretty much each and every single possible component in a car after transportataion across half the world, with all conceivable qualities of route. More than that, the product and methodologies were endlessly optimisable.

So, working as part of a large global team, with a big budget, complex problems to solve, worse problems lurking behind any cut corner and bad, vending-machine coffee on offer, I came up with… a cardboard box.

If you’re in that situation, too, remember Daft Punk and Random Access Memories - your product may, superficially, be dull to much of the population, but, if you end up Doin’ It Right, it will sound great.

Happy 2014!

°(alright, and perhaps for a small boost in search engine findability, too… :-))

As opposed to engineering with hectic grumpiness

Ah, finally - it's the Christmas holidays. At last, I've a chance to divert the kids into the path of their doting and understanding grandparents, then to sneak upstairs for a spot of stolen quiet-time. Time for switching off, for thinking and, in not too big a dose, writing.

Time for calm, quiet reflection is an astoundingly rare commodity. It has to be cherished and nurtured wherever possible, especially in that most unlikely of environments, work, where we happen to spend a goodly chunk of our lives. Reflecting on the the year that is petering out as I write, the biggest theme for me has been focus, or how difficult it has been to apply it with any regularity, and asking why I've not been successful at blanking off the world to exclude everything and everyone save the task to hand.

In the hustle and bustle of this engineering world that we inhabit, it's easy to get caught in the undertow of "actionism" (from that great German word Aktionismus) - doing stuff, doing more stuff, doing the same stuff again, doing more of the same stuff slightly differently; all of it urgent, most of it dull, mostly simultaneous, all of it with consequences for colleagues, suppliers and customers that mean, under the circumstances, we're unable to say "sod it." We're lynchpins without the luxury of deciding our priorities. Well, that's how I've been of late.

So, making use of this Christmas calm, I've tried to slow down, to reappraise how I - how we - work as engineers. The goal, I have decided, after a few sips of tea and a little staring out of the window, is that we must be able to work with grace, patience and precision.

This may sound like a whimsical, romantic view of master watchmakers or coffee roasters at their most reflective - but there's no way around it: it's the best way to approach any task. So let's have a think about what each of those concepts mean, and see if they make sense.

Grace and patience

Grace and patience are the rhino hide protecting the core of precision, which is the aim of any engineering activity. When they are too thinly applied, actions and deadlines chip away at the "precision" aspect of what we do. If we lack precision, then it's easy to become rattled or ratty when our decisions are questioned.

Grace is the ability to take on board what a task or a product requires, as communicated by people or by circumstance - or, as is more often the case, as not quite communicated by people or by circumstance. Grace means:

• Not being caught up in the emotion of the action
• Not being ruffled by the urgency of the action
• Retaining the ability to think clearly
• Retaining the ability to call in help and assistance from others without transferring the "panic"

... all the while, if possible, without becoming aloof, or putting on the "insufferable smile."

Patience is very much linked to grace, but means having the inner robustness to delve into a task, to keep at it, to maintain the ability to ask the right questions, to wait for the right answers as they develop. It is and requires:

• the ability to focus on a project
• the ability to "plod" through the logic of a project

Precision

Precision is the mark of getting things as right as they can be. It doesn't mean perfection (of which there is very little to go round), but rather getting the small things right, even if it's a version change to 1.1.2, so that the big steps can also be taken later. There are hundreds of examples that I could list, but in our world, understanding tolerances, GD&T callouts, specification callouts. etc spring to mind. They need to be defined them correctly in the context of your product.

Note that I don't mean setting tolerances arbitrarily small - precision is a result of the discussions with production, with suppliers, with customers, in the spirit of grace and patience. Getting things right, properly, defensibly.

Discovering the environment of grace and patience

A corollary of all of the above is that we as engineers need the environment in which to work with grace and patience. I would love to be able to say that we should be developing everything in splendid isolation from business needs. Like an AT&T Bell Labs from the glory days of transistors and lasers, or a 1960s IBM, we should be capable of working on the future. To be honest, though, I can't even imagine working in such a world. It could be wonderful, it could be terminally dull (though I dream it would be the former).

We need to face reality. I work in the automotive industry, which tends to be rather full of rowdy reality, so I know what it means to suffer business pressures alongside engineering and development pressures, in open-plan offices, without air conditioning.

Attaining the "state" of grace and patience in such an environment has to stem from a conscious decision to find and to nurture them first. As far as I can see, the breakthrough needs to be mental.

Without coming over too Zen, I think (but can't say from experience) it should be possible to filter out background noise and to focus on the task at hand. We can help ourselves by taking small physical steps like turning off email alert pop-ups, silencing phones and perhaps setting up "do not disturb" signals for our colleagues; big headphones, for example. Occasionally escaping to a lonely meeting room can work, though it does mean leaving a whole desk's worth of tools behind.

What I'm saying is that we (I, at least) need to be clearer of what our mental capabilities are, what we need to learn and how we should develop ourselves, our processes and our communications with colleagues (commercial, quality, purchasing, suppliers - that whole bubble world that we interact with) so that we end up being able to focus on work, permit the minimum of distractions and can take time to research, collaborate and to iterate our way to the future, all in the spirit of grace, patience and precision.

Easy job. Let's have at it in 2014...!

Why do we have quality departments? Even posing the question feels like a minor rebellion on my part, since "Quality" is such an integral concept in the business of producing things. For "integral" we can also read "taken for granted." Sometimes it can be good to tug at the tent poles of the status quo and see whether it collapses in a heap around us, or if we can move it somewhere more interesting.

This post isn't just coming from a theoretical standpoint, of course. I've had so many run-ins with colleagues from quality that I simply have to question that whole role. Too often have they acted as alarmist messengers and chasers of other peoples' actions whilst understanding neither the problem nor the product nor the processes that they are supposed to be monitoring - that is, seemingly doing nothing about it themselves. They don't add value, nor do they seem to save value - they transmit urgency. Unfortunately, transmitting urgency to the wrong sort of person (for example, me) is precisely the least good way of getting things resolved quickly and effectively.

So, whilst we all inherently understand the idea of producing things in ways acceptable both to customers and to our finances, do we really need quality departments, quality managers, quality engineers? I think we could be cannier about the whole thing - and ditch them totally.

The best way to do that would be to design an engineering company from scratch - alas, not something that I've ever done. But for me, the basic idea would be that the tasks that quality departments undertake can be distributed amongst other departments where those tasks make more sense.

The flip-flop question is this: is it better to decentralise those tasks amongst experts, or to collect them all under one roof and standardise? It may well be that the size of a company - tipping around a certain critical morass - is probably a key factor in this decision. But the prospect of ISO / TS audits should not be!

I work for a largish automotive supplier, and we have quality departments coming out of our ears: it's the world I live in. Deleting them (distributing them) would mean for me personally that I would need to get my designs, from material selection through to defining tolerances, just right; my colleagues in production would have to design their processes to produce within the parameters of the drawings and specs I give them and that all needs to be validated and monitored.

In other words, nothing: eliminating the quality department would have no effect on my key role, nor on the role of my friends in process engineering.

However, I'm forever getting involved in quality concerns, analysing returned or quarantined parts, performing root-cause analyses. This can help me understand our product better, but rarely have I had to change a design as a result of these investigations. Enfolding one or two of our colleagues from quality into our test and development organisation would mean that those defects could ben analysed as thoroughly as they are now, and lessons learned could be centralised, whilst freeing me to work on the next generation of products, which is what, I believe, I'm supposed to be doing.

Manufacturing will still need people and systems to check and to confirm that product meets requirements, both at any given instant and over time - that's for sure; such roles will never go away, but these days we can trust our production team's integrity to manage that by themselves rather than abdicating that responsibility to a separate department.

The role of a quality department as independent arbiter, a kind of internal auditor, remains an interesting point: can we be sure that Manufacturing, for example, will always be open and honest enough about things like tool release decisions and scrap rates when deliveries or performance indicators are on the line? Well, if we can't be sure then it would surely be beneficial to work on the culture of the company rather than to add layers of oversight. Again, it's a question of opportunity cost - would it be more effective for a company to pay people to police their own people, or to research and to produce things more effectively?

If we think (or click) back to my post on how Google tests software, we see that the key philosophy there is: the design of the product should include its testing and confirmation methods. So it should be the  product and process design engineers designing this together, which makes sense to me.

And where would the resources come from to ensure that product and process design could cope with that additional work? From the now redundant quality department, of course.

That leaves the audit side of things. Of course, nobody wants to be involved in audits at any stage. But since audits are a fact of life in many industries, the product and process design teams need to be involved in designing the business systems that they use on a daily basis to use, store, distribute and to archive work. And they should be responsible for proving that these ways work both in theory and are used in practice.

So, eliminating quality departments, partially reassigning them to design and development, is the obvious answer to all of this - yet quality departments seem to grow and grow where I am. Am I missing something obvious that would really justify the existence of quality departments? Or can we continue to "Think Canny" in this funny old business of engineering?

Blogging about considering new jobs (and doing something about it) seems like a risky idea. Posts are by their nature open to the world, so conceivably my boss could read this.

(Well, it's inconceivable, really, but let's go with it for now)

What will he think?

In my case, there's nothing that he can't have been inferred from previous discussions, so there's nothing that could surprise my boss unduly were he to read this. For you, dear reader, there are hopefully some worthwhile thoughts in here - so read on, whilst I write on.

It’s safe to say that I had a frustrating time at work in 2012, mostly for non-engineering reasons (resources, too many inputs and outputs, etc). I decided that a change of scenery would be a good way of clearing the decks and starting afresh, so I applied for a couple of new jobs.

A seemingly attractive way of making the switch to a new company or even to a new industry was, I thought, to glide along the plane of least resistance, taking a training- and background-agnostic route. In my thinking, this route would take me towards Project Management.

It's not perhaps strictly true to say background-agnostic. Project Managers are often handed the role from within another, and that's what happened to me at various stages in my career - so I can show a Project Management history: nominally, I am in any case a project manager right now. It forms part of my job title (the other words being "Development Engineer and-"). Whilst I officially combine the roles I also tend to fulfil both roles simultaneously (Project Manager, manage thyself!), which has added to the frustrations I have felt of late.

We were also given project management training a while back. It was in itself quite inspirational and I came top of the class in the tests at the end of it. So, in essence, Project Management is something I can do, more or less without really thinking about it - in fact, what else do I do other than manage projects? Every single task I have, be it "engineering" or "not", is part of a project, big or small. I do have to force myself to do things like pick up the phone (I'm much more of an emailer or short messenger than a caller), but overall I can work with others and others seem to be able to accept working with (sometimes for) me.

I got invited to some interviews.

Both were within the automotive sector, so I wasn’t going to be changing industry, but I would be changing technologies - glass and engine products were the general themes.

And therein lay the rub with me wanting to switch via the PM route: I thought the technologies would be cool, not the job. You see, what happened in both interviews was something like this:

Interviewer, after some preamble: “Imagine the scenario that a task within one of your projects is delayed. What do you do?”

Me (brain whirring, thinking…): Um, what can I say to this that could possibly be interesting? I’d have to talk to the guy whose task it is, see if I can chivvy him up a bit. Talk to his manager, talk to the customer, see if we can delay - oh, this is all so dull!

Me (aloud): Well, we could, umm, talk to the person responsible for the task (etc)

Me (body language): help! I’m floundering here and both I and my interviewer have lost interest in what I’m saying. He's staring out of the window, I'm staring at him for some kind of positive reaction...

And so on. Yet within the same interview I had to field some engineering-type questions:

Interviewer: What do you think could be the potential technical difficulties involved in developing this kind of product?

Me (internally): Yes! Easy score here

Me (aloud): Well, there’s the material selection, the coatings, how to apply them within undoubtedly very tight tolerances, how to withstand heat without distortion that would…

Me (body language): Hands waving, leaning forward, engaging the interviewer - more, please!

In the end, I have to realise that I am by nature an engineer, with everything that that entails: all the coolest development work, all the dullest admin stuff and everything in between. Anything else (commercial, purchasing, quality) would mean going against my own grain.

The only question remaining, then, is: can I become an engineering manager? From the aspect of organisation and team working, data access and transfer, deciding on what's right for the product and for the company - yes. From the aspect of dealing with stroppy employees, an ever-increasing email and travel load, and becoming ever more involved in company politics (whichever company that may be) - who knows. But that discovery is for another day.

Have you transitioned away from pure engineering? Have you made the step up to management - either successfully or stressfully? Let us know in your comments!

an attribute which this post could not be accused of posessing

Cycling back home from the industrial estate where I work in an otherwise romantic Heidelberg, I cross a bridge that soars over a main road with its gemütlich evening rush hour jams, and, in the same leap, over an idyllische railway line to Mannheim. The bridge, though acting here only as the scenery for the introduction to this post, would be worthy of a blog post itself in the hands of one more knowledgable and appreciative of its design. It is certainly more complex than normal, with a second cycle path spiralling up between road and rail to meet mine.

The thing is, when I'm cycling back from work, this tributary deposits riders cycling up it directly onto my side of the road. This isn't of itself a problem - I can move over to leave them room. But when I do this, we both end up cycling on the wrong side of the road, also known in England as the correct side of the road.

Over the years I have imagined myself commenting to the other riders: "Oh, you're English too?" Only I've never dared. Not only because I'm quite so brazen, but because the grammar of saying it in German is so tricky to get pithily right that we'll have crossed before I've had a chance to parse it, especially if the person on the other bike is a lady.

Yes, it is with a weary sigh that I note that German, like Latin and some others I could probably research for you, is a language that feels the need for three genders. Echoing our stereotypes of German structuredness, the language can be viewed as a series of matrices, with lattices of cases and word endings that can either be viewed as ladders to a higher plane of language, or linguistic snakes that will land you in grammatical trouble wherever you misstep.

Mark Twain certainly had great fun pointing out the bizarre logic of this supposedly highly logical language in his essay "The Awful German Language"

What this baroque structure does offer is an unusual form of efficiency. Word endings become signifiers to what action is being done by whom to what, if at all. So, in the name of efficiency, I could refer to an English lady as an "Engländerin" - two distinct words implicated by the ending of just one.

The flip side of that efficiency, however, is a certain fragility: if, after drafting a phrase, I want to change the subject noun to a word of a different gender (or, in the more likely scenario, I find that the gender I had assumed was wrong), I have to wade back through the whole sentence, changing and correcting word endings scattered throughout it to something different. If I was fed up with Eine kleine Nachtmusik  I could go for a small nightcap instead - Ein kleiner Schlummertrunk, meaning I have changed all three words in that sentence (and that's without the accusative case of me actively wanting one...)

So German and its relatives are efficient when things go right, but each error results in a cascade of compound grammatical catastrophes. I find English to be more robust to errors: a glitch in one portion of a sentence doesn't have to mean a complete rewrite. "The" is "the" whatever grammatical chaos is going on around it.

So this post is really all about efficiency and where it should be applied.

There seem to me to be three distinct strategies available:

1. Being highly efficient in one way
2. Being efficient enough in multiple ways
3. Enabling functionality in as many ways as possible

Mechanical components are generally efficient in one way, but if they go wrong, they are broken and need to be replaced. Highly-strung systems will also break with the loss of a first component, and may even result in losing a chain of components, as in a German sentence.

Systems can add robustness through redundancy. This is generally at the cost of efficiency, but usually can be said to be efficient enough.

Enabling functionality in multiple ways is reflective of the organic, of the free-form, of the gnarly - yes, of language, too. It's not often possible to attain this in mechanical engineering - I'm struggling to think of an example here, but perhaps sacrificial anti-corrosion coatings is one, where a scratch leads to corrosion of one material that results in the protection of another.

But when we're designing our product, irrespective of its apparent simplicity, we can always consider the efficiencies going on around it. We need to design for safety, for cost-efficiency, for energy efficiency - for a product's whole lifecycle. And if we can step away from the fragile and towards the organic in considering the world our product inhabits, we can perhaps go a long way towards attaining the maximal efficiency over the long term. Nature managed it, anyway!   Escaping from the semi-philosophical and going back to my bike problem; because of this ability in German to feminise words, either I could ask "sind Sie auch Engländerin?", which would be efficient, but would, through that word auch meaning also imply that I was also female, or I could ask "sind Sie such Engländer?" implying that she was male.   Mixing things up to avoid the problem ("kommen Sie such aus England?" - do you also come from England?) would be an option, but none of the alternatives is as concise as the original thought.

So I have never dared ask... And I expect that's fine by the good ladies of Heidelberg.

Engineers, like lawyers - hold on, I didn't just write that, did I? Well, it's a valid thought, so I'll press on. Engineers, like lawyers and other animals, can be classified into distinct genera and species, depending on the path we take within our chosen vocation.

As soon as I had, whilst at school, settled on engineering as the subject I wanted to study and practice, it was clear to me that I was much more of a "boffin" type than a "hacker". I was always uneasy about mending things, more confident about designing and working things out - so I opted for aerospace engineering. After graduation I went to Ford (emphatically not an aerospace company, despite its history and current CEO). There, I spent some time working in Manufacturing Engineering. I enjoyed the challenge, at times, but I wanted out, back to component and design engineering.

Who cares how it's made?

Now, my job is (should be) to develop and upgrade product so that it does what it is supposed to, when it is supposed to do it under all conceivable conditions. Whilst it sounds almost blasphemous to say it in these enlightened days of openness and collaboration, I don't necessarily care how it arrives at that point, as long as the how of its making doesn't affect the if of its functionality, or its cost too much.

Of course, this means that I do have to care about the process, as it more often than not does affect the product in clear or in subtle ways. So I talk to our process and manufacturing engineers.

Who are, of course, also design engineers.

I suppose we have all settled into a kind of shorthand for engineering titles, as the word "design" is redundant. There are those who design and develop product, those who design and develop the process, and those who design and develop the equipment to be used in the process to make the product designed at the outset (process product design, or something like that!).

By and large, from my experience, process and manufacturing engineers are cut from a different cloth to product engineers. They can work together, but rarely does one stay in the other's shoes for long. At the extremes, you could envisage the gnarly manufacturing engineer and the soft white-handed product engineer - of course, these types meld and merge, but the tendency is there, I feel.

And we talk.

Silos or troughs

Whether I "get to" talk to these colleagues, or "have to" depends on personalities - which, fortunately, engineers don't have - but where I work, we are distinct groups that need to be brought together on a project by project basis; we need to jump those famous silos to work together, rather than always being together, feeding from the same trough - perhaps "collaborating freely" would be a better turn of phrase.

Our means of communication is still principally email, alas. Our offices are close enough to walk to, but all too often, simply waltzing into each others' enclosures means a disruption of some sort. We're all busy people, who need to try and focus on some one thing at a time. Disturbances from outside, whilst of course important, mean a reshifting of focus from some other, hopefully equally important, activity. So to minimise the growling, we email or invite each other to short meetings, which is really the best method to have disparate minds alight on the one subject for a few quality minutes.

So, we have feasibility reviews, we cooperate on FMEAs (still too infrequently), we sketch, we negotiate (more often than not on tolerances), and we make, measure, test, update and approve our product.

We work together, in short.

Ideally, I should embed myself in their world so that my designs flow and interact as smoothly as possible with theirs, and their reflect the functions that the product needs to have. In small, dedicated teams, that could work, but currently it's all about snatching time to work on one thing rather than another: even were I to share a desk with them, all we'd be doing is shouting over each others' telephone calls.

So I'll stick to my "ivory tower" (as of course they call it), for the time being.

In praise of process

But from that tower, from behind this screen, I want to place on record my respect for my engineering cousins in process design. These are colleagues who get to play with robots, with sorting and sequencing machines, with presses and with tool designs; these are people who have a very rich and very different mind to my own.

I haven't the faintest clue how to design and specify a press or a hopper bowl that will position and place fitting after fitting into an assembly rig so that they are all applied - firstly at all, and secondly in the correct orientation.

In some many cases, it is the process people who give one company a slender advantage over another - either through holding dimensions and quality better than anybody else, or by bringing costs down to an attractive level for everybody concerned. In the automotive world that I know, most contracts involve a year-on-year price reduction clause. This assumes that as a product achieves maturity, scrap levels are reduced, efficiency in increased and waste is minimised. These are valid assumptions to make, but the work towards achieving those goals in an economic way is principally down to the process and manufacturing engineers.

So really this post is about acknowledging the diversity within our own world of Engineering and letting it be known that I have the utmost respect for the guys and gals who, much more than Getting Things Done, Get Things Made.

Photo: Corrosion Doctors / Metallurical Technologies

A little snippet of what I learned at university, residing deprecated in my skull, all of a sudden, during one the most boring of tests that we could think of for a component, became relevant and real. A part cracked during corrosion testing. Then another did, and another - and we had an issue, as they say in the modern parlance.

It was one of those things that, as soon as they occur, make you think "of course! Why didn't we think of that before we started testing?" To which the answer is of course: because we didn't know that we needed to think of it.

It was a lovely, clear case of stress corrosion cracking.

We were looking at making the switch from steel to aluminium for some joint components. We knew about some of the ways that Al differs from steel (no definable infinite fatigue life, galvanic potential in corrosive environments, for example) already. The test plan that we came up with was a fairly standard one that would more or less tick boxes so that we could introduce the product with a customer.

And then the stress corrosion cracking appeared. Fortunately, we had for various reasons chosen to test two different Al alloys - and sure enough, only one of them was affected by SCC. A quick Google search confirmed our findings: Al 7075 T6 is highly susceptible to SCC, whilst the 6xxx alloy that we also tried is not. You can read some of the literature we found here and here.

It turns out that the alloying elements (Zn, Mg and Cu) that make up 7075 T6 and its kin precipitate out to the grain boundaries during the T6 grade heat treatment. This inter-metallic phase forms an anode to the grains’ cathode, promoting corrosion along the grain boundaries (from a good discussion on Engineering Tips, here ).

They also create inherent weaknesses in the overall structure. With a component under permanent stress (in our example we're looking at around 10 kN clamping force), corrosion running between the grains uncovers a path for a crack to propagate.

Funnily enough, the crack wasn't catastrophic, at least not in our nice, stable laboratory conditions: the joint was still tight. However, adding typical vehicle loads and system pressures to the joint would almost certainly lead to a reduced component life.

So - it's clear: don't use Al 7075 T6 in applications that can be exposed to corrosive environments whilst under load. The biggest question now is how to ensure that future Canny Engineers don't fall into the same trap that this one did and end up with them feeling less canny than ever.

One part of the answer lies in the most obvious place of all, the drawing. But only part of the answer… We will of course remove Al 7075 T6 from the drawing and keep our Al 6xxx material on there. As this is a real product change, we will have to update the revision level on the print and obtain approval for that change. This means that we will enter our change request procedure, filling out the associated form. There, we will write a few lines about SCC, make reference to the test report - and that's that. The change request document will be referenced on the drawing (remember to obtain the CR number before changing the drawing, then!), so the link is made. Anyone interested in the history of this part can, with a little digging, find the reason why we eliminated Al 7075 T6 from our prints.

Great - but that's hardly a robust way of ensuring that future engineers will know to avoid it. They would have to chance upon the one print that was involved in our original "discovery" of SCC, when all other variants of this component would no longer have any reference to this change, because they would of course have been designed correctly from the outset… Until our future canny engineer says "hold on, why not use 7075 T6? It's stronger, so we can use less of it… etc)" How do we as ghost of his past tell him that he's in danger of no longer being canny?

This is where company Wikis, bodies of knowledge, collections of basic data, whatever you call it, need to be working well. Just relying on Google doesn't work: I just put in "Al 7075 T6" into the search box and came up with 935000 results, and in the first several pages it all looks great - the perfect material for our application; which, of course, it was for us, until it wasn't.

What I have started to do is to set up a technical Wiki for precisely such matters. It's sparsely populated, and there are currently no other users - and the management don't seem to have understood it - but it's worth persevering with into 2013 so that my colleagues in 2031 don't have to go through the stress of corrosion cracking.

Assuming that the system that runs my wiki is still extant...

This post was first published over at Engineers Looking For Stuff, to which I contribute every now and again. I enjoyed writing this one so much, and it's so pertinent to the way that I think about engineering, that I asked and received permission to republish it here. They are my words, after all!

Engineers have an often uneasy relationship with words. The common assumption is that if left to our own devices we'll mangle grammar, butcher words and generally leave a trail of linguistic destruction in our wake. This is largely unfair, as stereotypes tend to be, but we are rightly better known for our smithing of iron than of prose. If we think about language at all, it's usually in the sense of grudgingly having to cope with it, or even wishing it away: "we shouldn't bother too much about writing - it's the product that counts."

It's true that product reaching customers is the goal of all our efforts, but words play such a large part in helping us get there that it would be a shame to scurry away from them, as if they were rain and we had no umbrella.

Instead, we should embrace words, using this rain like farmers rather than bankers - because we use them a lot. In our concept proposals, our offers, our specifications, our emails, our reports and even on our drawings, words carry meaning and intent to others. And, usually, these documents have our names on them, thus tagging us as author for eternity. How often does our product do that? (The makers among you rightly have permission to feel smug at this instance - but that still doesn't exempt you from having to use words!).

So pride in a job well done, in the knowledge that good communication leads to good product, should drive a conscious decision to get our writing up to as good a standard as we can - which, of course, means work.

Whether I'm drafting a blog post or a test report, I often feel my mind racing a few words ahead of me, sifting through multiple cascades of options and meaning, every so often stamping on the brakes as I get stuck with a word that hovers on the tip of my (mental) tongue. Even after that flurry of activity, what I "splash" onto the page needs refining, to ensure that it makes sense and - in deference to the reader - gets to the point relatively quickly and painlessly.

This is what I mean by effort, and the onus of that effort should be on the writer. We have to communicate, and, no matter how good we are at sketching and drafting, we can't escape having to deliver words to others. These words carry meaning and other more subtle levels of meaning: the tone.

All of us write differently depending on the scenario. So, whereas I use the word shall all the time in specifications, you'll hardly ever see it in my emails.

Whilst specs and drawing call-outs should be dry and almost legalese, riding as they do on the precise definitions of the words we select, emails can be chattier, depending on your audience. It's always worth considering your emails to be formal documents, however; they have a history and you'll be amazed how often emails from six years ago crop up when you or others are searching for information on a project or product. That's the positive spin on this: there is the negative aspect, that you no doubt can also imagine. So always review before sending (think of that "send" button as "Publish Now" and see what an effect that has on your haste).

The spoken word sets the collaborative tone even more starkly. Face to face there are the immediate signals that everybody sends with voice, body language and participation (or lack thereof) in the discussion, which go beyond the scope of this post, but there are subtle, weasel words that can affect the way people think about their jobs. Indeed, these were the catalyst for this very post.

It was in a project meeting a while ago that I first really noticed them. The product required some pre-assembly of a threaded adaptor and the commercial manager piped up with the comment:

"Then you simply need to screw in the adaptor…"

There it was, that word, "simply." It suddenly struck me how belittling that word was. To him, that assembly was a value in cents. To us it meant: determining the right tightening torque and number of turns, specifying, trialling and commissioning the equipment, specifying control methods, setting up a PFMEA… You get the idea.

Since that meeting I've become very sensitive to "simply," "only," "just" and their ilk and always point them out to those to carelessly utter them.

We have to watch out for those words everywhere. Imagine what real meaning lies behind the innocent remark "we only changed the process parameters a little bit…"

We should eliminate "simply" from our vocabulary (and help others to do the same) not in the spirit of saying "everything is hard", but in the spirit of "we value your expertise, we want you to keep on mastering your work, improving it, and yourself. so that our product can rock even harder than it does now."

What's in a word? That much can be in a word.

Who reads procedures?

What, you don’t? Alright then, another question - who writes procedures? Ah, well, on that front, I have a confession to make: I do.

But hold on - if you’re not reading, why bother writing?

Let’s go back to the start, see what we’re dealing with. Procedures are company-internal documents that describe how things should be done. In that sense, the closest analogy I can offer is that, like the laws of the land (which I presume you, like me, haven’t read in their fullness), procedures form part of a distinct yet only subconsciously perceived scenery - barely noticed until you crash into them, or if a newcomer starts asking for directions.

That newcomer point is important: the bigger the company, the less likely it is that someone can naturally pick up and run with the workflows and networks of people and systems that combine to get things done. A start-up’s first instinct is not to write its procedures. Only when the company is established and has grown do such things begin to matter and procedures - instruction sets for beginners, for those lost in a maelstrom of work, or for those about to be audited - are written. (Rands in Repose has written a lot about transitioning from start up to big company, including and very eloquently about procedures and process in the software world)

So, I’ve written procedures. I’m not a prolific proceduralist, thankfully, and the ones that I’ve been involved in are hardly internal best-sellers*, but at least I can say that whilst novels they certainly are not, I have at least experienced some satisfaction at having the procedures approved and published.

Or perhaps journalism would be a better analogy than novels - when I was writing them, there was a real sense of urgency surrounding them. There was a sense of deadline, of needing to fix something that was broken.

But with a procedure? Which nobody will read? Hmm, that doesn’t quite add up. Unless people do read them. Some few, key people who then tell others how things should work - and those others more or less understand the intent and get on with it.

Until teams drift apart, new people come in and things get broken again.

Procedures - the making of

The key to remember is that procedures are principally a work in the written language, which means they always need some knocking back and forth and into shape - editing - at best within a small, motivated and expert working group. They are official documents, so they’ll need to be given their ID numbers and released into whatever system your company uses.

Procedures are also visual documents, so a certain design aesthetic is also worth investing some time in. Even if the only graphic in there is the workflow, it’s always worth trying to make it look and feel right by considering format, colours and alignment. If it looks shitty now, it’ll look shitty in three years’ time, and it will still have your name on it!

Procedures are structured documents, too, like technical reports: Introduction, Scope, Definitions, Resources involved, the step by step guide and the workflow should all be in there.

Structure, word and graphic need to be sound in logic and clear enough to read without frustrating or confusing a reader by descending into ever diminishing circles of definition (or spiralling up its own arse in grandiose sweeps of meaningless bluster. Ah, speaking of which, I’d better be moving on here…)

What is a good procedure?

A procedure is like a process flow, but for people. Do this, then that, inform this person, file that data there, fill out this form, review with that team, finish and get on with your lives. Like a good process flow, a good procedure should capture the steps, decisions and loops that result in a final product. A process results in a part, a procedure results in information. Both should maximise output and minimise waste.

Do procedures define or describe?

Companies generally muddle by, if we’re honest about it. There are things that need to be done and, buoyed by our honest and human sense of duty usually overriding any sense of “oh, let’s just forget it and do something fun instead”, we talk and email and chivvy and stress and eventually get things to a sufficiently complete state that we can move on to the next disaster.

Procedures formalise and idealise those inner workings of a company. Going back to the process analogy above, a procedure should be designed to maximise efficiency - in once sense, it is an engineered document (hopefully with decent spelling), in the sense that defines how things work in their optimum way.

So the question above is misleading: procedures do describe, but really they should define.

Are procedures a cure or a symptom?

One key reason for writing procedures is to correct course on some workflow that is sailing onto the rocks. Often, the rocks weren’t formally recognised before, so the new (or updated) procedure is effectively charting dangerous waters.

One of the biggest balances that a company has to manage, however, is resources. Even if we were all able to live and work on one project only, and all of our team members could do the same, tensions and bottlenecks would arise. With teams being involved in the multiple carousels of projects, individuals start think-feeling for themselves, taking on tasks that aren’t strictly theirs “to keep things moving”, while others try to keep low and out of the firing line. These tensions generate ever greater emotional potential.

This is where procedures form the “laws” of the company. He should be doing this, she should be doing that, but only when given this signal or that information. They should serve to de-escalate things. If they can’t, then it’s a clear sign that the respective teams aren’t set up correctly for that combination of tasks.

Ghost protocols

Eventually, all of these new definitions and workflows become the new day-to-day and procedures are no longer referred to. Or or those new spangly ways of working fade into disuse, yet their respective procedures remain, sitting in (often a bewildering array of) libraries somewhere, gathering digital dust, crumbling as entropy attacks their bits and bytes.

The dust is kicked up by everybody’s favourite bugbears, audits. As audits suddenly loom (which they tend to do), links are checked and if they still work, are distributed, some conscientious colleagues bookmark them and may even scroll through the procedures themselves. They generally won’t read them, though.

Occasionally, an auditor will prudently validate his job description and note a discrepancy between a job done and a procedure. Hands will be wrung, failure to comply noted and efforts made to be better in the future.

By that stage, though, procedures are usually dead. They lie in state - Lenin’s waxy visage springs to mind, though without his enduring popularity. Perhaps three people in my company know where to find them. Everybody else who needs to know anything about how things should run simply ask me directly - or kind of muddle by.

Anything, of course, being preferable to reading and understanding procedures. Although: at least procedures don’t get irritable if you consult them.

*I would normally put a number to this, but we’re just upgrading our SharePoint database, and stats have been switched off. I don’t know if they’ll be reset when they’re available again. I’ll update as and when I know.

Validation testing is a significant part of my life as an engineer these days. Also, I have much more interesting things I could - and should - be getting on with.

Validation is important, but it's largely stupid - like much of work, I suppose. Perhaps stupid is too strong a word. Dumb is probably a better choice, the opposite of smart. Validation is dumb, and there's no escaping it.

What to do?

Well, we can talk about it first (even if this is not doing anything about it). Validation is the antimatter of development - put the two together and you destroy engineering life itself (overdramatising somewhat). What I mean is this: development is subtle, replete with success and failure, nuance, puzzlement and, hopefully, finally, understanding. Validation is a box-ticking exercise that brings nothing of interest to anybody, except the approval to sell product, which is a key aspect of business, I have been led to understand... so validation is important.

Testing is an integral part of development, one that I certainly don't want to discard. When we develop components, we have to pass testing and other approval gateways; based on the resulting performance, either we confirm that parts need to be redesigned because they don't meet a particular specification, we confirm that our parts do meet a particular specification, or we can write our own spec if one doesn't exist already. At the end of a development project, validation confirms that the first parts off the real production process are as good as all those expensive prototype parts that were tested previously: validation can be the joyous culmination of all that development effort, champagne all round. So really, my gripe isn't with concept or process validation testing - these are valid steps in getting a product to market.

Get over it

My gripe is with approval testing; testing that is set as a hurdle to delivery to a given customer.

Hurdles are good in many ways. If everything we did were trivial, anybody could do it. Fortunately, what we do is not trivial, and there is a limited number of companies involved in our market, each with their own strengths and... opportunities. Validation testing from the customer side is a way of filtering out duff suppliers.

But the work that is sucking out the oxygen of development for me right now is not linked to any new development or any new product. It has the Kafkaesque whiff of bureaucracy generating a lot of effort for no tangible benefit at all.

Validation is time-consuming, expensive and is (supposed to be) a key component in my other important-stupid bugbear, PPAPs

So, as I asked before, what to do with it?

The phrase "creative destruction" comes to mind - destroy validation and PPAPs and all of that dumb junk to free ourselves to think creatively. Let's explore that: can we ditch it all?

Ideally, yes: with all the data swilling around in our company, from development results to production and quality control systems, we should be able to show that production parameters haven't changed significantly since the product was first approved, and that the standard production checks will have filtered out any weaknesses.

This can work - but often the customer wants to use an existing part on a new platform, or a new part on a new platform, so wants a full set of confirmation test results, in their unique format. Also, it doesn't avoid the question of whim. A customer can demand results against a particular set of specifications whenever they want. So, you test and you validate.

But why me?

If there's one industry where whim and whimsy is at a minimum, it's motorsport. What do they do there? Well, even if they are producing a "series of one-offs", they test and they inspect and they destroy things, too. Yes, they validate. How they go about it is hinted at in this puff-piece by and from the Lotus F1 team.

The article doesn't tell us much, but the important point is that they have an inspection team. Just as software smithies have test teams, engineers should have inspection and validation teams. This is what I am missing where I am now. We have fallen in slow-motion into the trap of mixing development and validation in one pot. Alas, because the output of validation is a ticked box (or a boxed tick), and since those ticks in boxes are prerequisites to supply and therefore making money, validation more often than not takes priority, thereby hindering development.

Unite and advance, Divide and conquer

The answer, then, is twofold - and also expensive. First of all, the vexing question of validation testing needs to be tackled at the source - with the customer. To be able to come to a sensible agreement on what's relevant and what's useful to test, the onus is on the supplier to show his understanding of the product - how it performs, how stable the processes are, what could potentially go wrong. This is expensive in terms of effort - data-hunting and gathering, condensing it into digestible information and then taking it to the customer for (in all probability) a series of meetings and discussions to come to a sensible arrangement.

Then validation testing must be separated from development. The two should be unique teams with limited overlap, ideally with separate facilities. This, too, is expensive - but not focussing sufficiently on development is more expensive still in the long run.

But perhaps I'm biased.

After letting lady Shanghai go first, gentlemanly North America, along with cousin Mexico, took its turn at being trained by a bunch of know-it-all Europeans (and one Australian), who were airdropped into Detroit last week to bring a breath of fresh thinking to the way our product and processes are treated, and to help make this new air the one we all breathe globally.

(wow, perhaps I should become an industry marketing writer...!)

As one of the know-it-alls, I have to admit to having felt some trepidation at facing the North Americans. Our regions have been working more or less independently for the last several decades and my fear was that the Americans, with their equally vast but differently tuned automotive experience, would be open only in the expression of their hostility to our ideas.

Fortunately, that trepidation, whilst not completely baseless (I had my reasons for such thinking), did not crystallise into anything tangible, for the most part. I did notice participant numbers fluctuating during the two days of training, with some key individuals spending a remarkably small amount of time with us, even considering the typical day-to-day calls upon their time, but those who stayed throughout were attentive, asked good questions and kept us going through all the jet lag and windowless meeting room atmosphere with their overall positivity and willingness to learn.

We certainly brought new ways of thinking (though also some not so new but not fully implemented standards) to the forum, and they weren't dismissed out of hand, as could have been the case. Having the backing of our global management team undoubtedly had a helping hand in keeping the peace there, but I got the impression that what we were presenting made sense and was difficult to argue against. The discussions were mostly about context and capabilities rather than acceptance.

My own presentations, on the engineering behind our product, and on technical problem solving, were well received, even though my first presentation went well over its allotted time. This really was the breath of fresh air that the team were looking for. Again, discussion was constructive and showed that my American colleagues were learning something that they were keen to be able to implement in their own region.

Is there a life beyond the office?

Despite the windowless conference room, which sat as an enclosed island within the sea of cubicles, I have to admit to being quite impressed by our American headquarters. It felt like a rather different company to the one I work at in Germany, altogether more professional. It exuded a quiet professionalism (aided by some careful noise damping, which is fully missing in our offices, and even a soft white noise that is intended to be filtered out by the mind, along with similar frequencies, making the whole thing "feel" quieter).

There was an excellent canteen, with a sandwich-making bar, main courses, cookies and - the pièce de résistance, a soft-whip ice-cream machine. Coffee was always available from the Starbucks bean-to-cup machines, as were various colas and fizzy drinks (in huge 12 oz. cups), with ice of course also being on tap.

Alas, beyond the offices and hotel, I didn't see much at all. On first impressions, there wasn't much to entice anybody out of the hotel

Room with a view

, even though I really needed to escape - the windows were welded shut, so it was all aircon air and faintly Soviet-looking corridors. 

Accepting the company transfer from airport to hotel wasn't a mistake per se (it was lovely being chauffeured around in a Lincoln Town Car), but it did mean that I didn't have the flexibility of a hire car this time around - and not having a car there is pretty much fatal there…

Whilst it was all about the people this time (OK, the people, the burgers and the beers), and making contacts, not having seen downtown Detroit, Birmingham, Rochester or any surrounding scenery, was a bit disappointing. I'll have to do better next time.

Getting to and from Detroit was fine. I was pleasantly surprised by Delta airlines (I'd always heard pretty negative things about them), but the service was very good, bordering on the excessive when the purser came to shake everybody's hand and to thank us all for choosing Delta. On the other hand, I was disappointed by the support from KLM-Delta when my return flight from Detroit was delayed by connecting flights from Miami and Orlando. Alas, they didn't return the favour with us in Amsterdam Schiphol, meaning that I missed my final flight back to Frankfurt.

That resulted in a jet-lag-groggy four hours in yet another airless lounge and an electronics store, where I managed not to by a new tablet on a whim.

So - the next training will be on home turf in Europe. Will that be the biggest challenge of them all, trying to enthuse those colleagues in the midst of one of the biggest slumps in the automotive industry? It shouldn't be. The biggest challenge will be turning this initiative into a resource that will be available for all new and existing employees. That's going to be fun, for sure - more on that as and when.

At least in Europe I should be able to enjoy more fresh air than I have in the past two trainings...

Corridors of power

Yesterday, Thursday, being a bank holiday (at least in my state of Baden-Württemberg), today was a classic German "bridging day". One day's holiday resulting in a four-day weekend is simply too good a ratio to miss for most Germans, and I had also planned to take advantage of the bridge.

But with so much going on in so many frantic ways, with so much on my plate and buzzing in my head, I felt it was better to ensconce myself in a quiet, colleague-free office and get some work done.

I was disappointed to to see upon my arrival an office full of colleagues who had had similar thoughts, all chatting away about a colleague's house-build project, architects and unreliable builders. I skulked off and found an empty manager's office nearby, docked my laptop there with my own peripherals, left my cordless phone on its station and closed the doors. I spent the morning trudging through drudgery (hello, PPAPs) and then the afternoon working on DFMEAs and updating my presentations for the training I'll be giving in Detroit in a few weeks' time.

It was great. I didn't need to plug in my headphones, nor did I end up continuously distracting myself with the internet. I simply worked, ticking off my "Big Three" tasks for the day, plus a few "Notable Nuisances" as the hours ticked comfortably by.

It all comes back to environment. As I hinted in my post about Engineering Things Done, I cannot work effectively in an open plan office. There are always people on telephones, colleagues discussing work or debating which is the cheaper internet provider. Sometimes it's good to get involved in the community aspect of work, that's certain - they're decent people, and I'll need their support at times, too, so I daren't become a recluse - but I need peace and quiet to work properly.

I suspect that most engineers would be better with flexible environments. We're knowledge workers, so need time and space to think. Even when we're dragged into quality mud-fights and validation testing, our minds should be at peace so that we can maintain our "switchability" between big picture and detail.

So - individual offices for engineers? That would be impractical. But the ability, both physically and culturally, to switch environment and context is important and needs to be cultivated.

We're on the cusp of starting the migration of our CAD data into a full-fat PLM system (in our case Teamcenter from Siemens). It's now becoming clear what the task ahead of us entails - approximately one thousand 3D models and their associated prints need to be collated, tagged, parametrised, renamed, renumbered and transferred.

The tagging and parametrisation will take approximately 30 minutes per item, meaning (rumble, mumble, calculators, divide by the solar transit and carry the moon) around sixty working days, for somebody (most likely not me, thankfully) working at full tilt to the exclusion of everything else.

It'll be a big old resource hit, it'll cause lots of anguish, gnashing of teeth and grinding of coffee - but the results should be spectacular, even if we're "only" migrating the CAD data in this first step.

Once we start adding the life-cycle documents for each part, it will become a world unto itself. That's for another post.

Apart from the opportunity to see some films that I don't normally get the chance to see, long-distance travel lost its allure a long time ago for me. I appreciate different cultures and their food, it has to be said, but getting to experience them on business trips is generally not worth the price of jet lag, lack of sleep and missing the family. I'd rather travel to Kassel than Korea.

Sometimes, though, a trip can be rewarding in other ways. My recent jaunt to Shanghai was as special as it was exhausting; after many years of learning engineering and the specifics of my job, I finally became teacher.

To say "finally" isn't strictly true: helping out colleagues with technical questions is a large part of what we as engineers do. We're always explaining things to sales people or buyers (usually in full knowledge that it'll be out the other ear within milliseconds) as well as other engineers. But this was different - I was formally given the task of training our colleagues in the Asia Pacific region how our products work. It was like our own, private, in-company TED talk.

The background to the training was inauspicious: our colleagues in China had a few eminently avoidable issues (incidences or complaints, whichever word-avoidance euphemism is currently in vogue) that required a lot of effort throughout the company globally to resolve, even though for me the analysis and resolution were fairly trivial.

Even before the dust settled, the key action that emerged from all of that excitement was that we needed to increase the general skills level in technology, quality and manufacturing - we needed to spend the effort to train 'em up in order to save ourselves and the company a whole load of pain and cost.

From a business perspective, it was an investment that would result in a positive pay back (or at least a less negative one).

Getting the admin right is part of getting the product right

Just getting to Shanghai turned out to be a bigger hurdle than I had expected: cutting a long story short, I couldn't board my flight on the Saturday because what I had thought was a six-month, two-entry visa was in fact a three-month single-entry: I hadn't checked in advance. Whilst I'm proud to call myself an engineer rather than a bureaucrat, it was still pretty embarrassing, as it meant that I would miss the final organisational meetings with the team on Monday.

For various reasons, I ended up making use of a new rule in China - that you can stop over in Shanghai or Beijing for 72 hours without a visa, as long as your stay is just that: a stop-over. This meant that I couldn't simply fly back to Frankfurt after the training; no, I had to have an interim airport on my itinerary. In this case I was recommended to stop over in Bangkok.

Fortunately, bureaucrats being bureaucrats, they could only go by the letter of their rules, rather than the sense of them: I was admitted into Shanghai for those 72 hours, even though my return flight from Bangkok to Frankfurt was only two hours after my arrival in Bangkok.

Sometimes it's great that the law and its ilk are asses.

What matters is, I got there.

Presenting in pyjamas

Because of all the delays in my arrival, instead of having a few days to acclimatise, to organise and to finalise, I rolled up to the conference hotel just in time for my own presentation. And so, without the chance to change into my suit, I wandered up to the front of the auditorium still wearing what I had been travelling and failing to sleep in - whilst not really my pyjamas, they may as well have been.

Fortunately, that didn't matter one jot.

Not fortunately, I had practiced my presentation out loud to myself in an empty meeting room back in the offices in Heidelberg. I had given myself the rare chance to test the logic and flow of my presentation before flying, so I knew that I wouldn't be standing there, staring at my own slides, wondering what it was I wanted to say: I heartily recommend the practice of practicing to anyone.

So, finally I was there, adrenaline flowing as I stood in front of 70 colleagues who were all eyes and ears, ready to listen to what I had to say. Presenting the basics behind what we do and what our customers do with our parts once they assemble them was an enlightening experience. The things I was showing them were what I have lived and breathed at work for the past five years and more. Conversely, my audience really didn't have much of a clue - and they were agog. Those eyes followed me as I talked, as I tried to avoid walking around the stage too much (I do tend to use up the stage) and even as I noticeably faded towards the end: it went well.

The best of indicator of my success were the questions that people threw at me during coffee and lunch breaks over the next day and a half. For sure, there came many compliments but they weren't empty: they nearly always came with a question. It was this that really told me that they had been listening and were making the first steps towards understanding, namely confusion.

And the rest is a blur

That evening, we went out for drinks. The next evening, we went out for dinner and drinks. Early the next morning I had a meeting with Shanghai Volkswagen. That afternoon I flew to Bangkok. That night, I flew feet-first in a business class bed in an A380, to get home in time for breakfast.

Was that it?

I'm back in what counts as normality at work again, my temporary rockstardom popped back in the folder where my presentations lie like an unwanted old rag-doll. But, if all goes to plan, it will be taken out, dusted off, given the odd bit of nip and tuck and we'll be back on the road. The idea is that we take this "show" throughout the company; and that's going to be interesting, to say the least. We could say that Asia Pacific was low-hanging fruit. My colleagues there were (and still are) keen to learn, excited in the possibilities that this knowledge will give them when dealing with their customers.

In North America and Europe, on the other hand, I'm expecting a kind of tacit resistance. They "know it all", have "seen it all before" - even though in my experience they don't talk the right language of our products: I hope it doesn't go as far as apathy - but could well go that far.

But that's all to come. First of all, I have to get ready for that exciting trip to Kassel, where at least you can see through the air around you.

It's true, though - it doesn't quite have the same ring as Shanghai, does it?

Phew, what a day! What a lot of days! Things are pretty mad at the moment and have me racing from one fire to the next whilst juggling the other less serious blazes. Things are probably more or less the same for you (unless you work in aerospace ;-)). We need to get things done all the time and seemingly all at once. Priorities rest on ever-shifting sands, cups of coffee are gulped without enjoyment, nerves are frayed.

Having lots to do at work is both a blessing and a curse: of course we want to be gainfully employed, but there is a point beyond which the sheer number of tasks that we are responsible for becomes overwhelming. As a result, efficiency sinks to its knees, even if we physically manage to stay on our feet.

This fact has been recognised by many and has become the basis of whole careers on advising people how to do manage tasks. I've been on Time Management courses, as I described over at Engineer Blogs last year, I've tried hiding myself in empty cupboard-sized meeting rooms without my phones and I've tried all sorts of tools like the Tasks list in Outlook to try and find a way out of the mess, mostly to no avail.

Help is at so many hands that it's no help at all: there's such an uncontrollable thicket of to-do apps, self-timer apps, of notation apps and (e-) books to be bought that these have become an industry in themselves. All in the name of getting things done.

Late last year I caved and bought the book with those words capitalised by Dave Allen: Getting Things Done. I read it, too - and came away rather impressed. It's certainly a book of two halves (it feels a little like a 'buy one, get one free' deal, where you don't necessarily want or need the free item), but the first half, where the concepts and mechanisms of Getting Things Done are explained is well worth the entry price. Mr. Allen has an incredible font of quotes that are splashed liberally throughout the book, too.

This isn't a book review, though. It's a process review, about Getting Things Done, or, as it's now known in the trade, GTD.

In essence, the GTD methodology is about freeing up your mind, removing all the vague projects and to-do's lodged quaking anxiously in your brain and onto physical or digital lists. The discipline of creating lists, of categorising, of sifting and sorting into whatever systems best suit you is geared towards relieving the mental pressures of non-started or incomplete tasks and towards focussing your attention on the next thing to do.

Next steps are a key element of Getting Things Done and recognising this goes a long way towards success. When I have to update a drawing, that is not a task itself, it's a project. The next steps for me go along the lines of: Creating a new part number or release level in the system. Printing out the current drawing. Sketching up all the changes required: whilst I'm doing that I'll realise that I need to pull a Change Request number, so I'll need to go onto that system and generate a form and a number. That number goes onto the new print, which, once sketched up, goes to our CAD designer for modification. I wait. I get the print back for review. I make corrections, or I don't - I send the drawing back if I do need updates, wait again (doing something else in the meantime), then switch focus back to the print once it's finalised. Then I need to upload it and "publish" it... And so on.

Each one of those steps are all "small" things, but there are so many of them that constitute this mini-project called "update drawing xyz" that they easily clog up my mental passages (for want of a better turn of phrase). Listing the tasks out on paper or in some kind of digital software means that I don't have to hold them in my mental buffer. Equally, I won't have to worry about remembering where I am whenever a distraction occurs - a colleague walks in whilst I'm sketching and requires assistance (often setting off the next mini project of Things To Do), or quite simply when I'm waiting for that drawing to come back from CAD: I can quickly find the next open task and use that,

I've worked according to this methodology, applying the same logic to pretty much everything I do: ideas for new developments, testing that I need to do and subsequent reporting that I need to complete.

The general methodology works very well. It took some time to sift through my projects and my emails, but surprisingly quickly, I found a decent system of project taxonomy and began to see more and more white space in my inbox.

Tool-wise, I ended up using the browser-based software Asana, mainly because I wouldn't need to install anything on my locked and stitched-up work laptop. Outlook is too stuffed to work for me. It has all the functionality - emails, notes, to-do's, ability to drag and drop emails into Calendar and into Tasks - but somehow I need to escape the Outlook environment and keep things as focussed as possible - Asana provides this "cleaner" environment for me.

Up until mid January, I had a good set of lists and tasks, as well as an email in-box hovering around the zero level (each email is either archived or generates a set of tasks in my list setup). It was only when I embarked on a series of business trips - to Shanghai, to Kassel - and became sucked into a series of "urgents" that things started to subside back to the old ways of inbox infinity and anxieties everywhere I looked inside my head.

The focus of GTD is very much on mastering the low-level tasks. Dave Allen addresses this regularly in the book - he acknowledges that life-goal-setting (his "50,000 ft+ view") is a way of finding orientation and goals in life; but if you're mentally overloaded with pending things to do, you don't have the headspace to creatively think about the bigger picture.

Get your everyday tasks under control, unload your mind of that burden, and the bigger picture has more room to grow of its own.

Honestly speaking, I'm a bit like a dieter here: bouncing from inbox-zero and being on top of things to feeling overwhelmed. I'm back at the overwhelmed phase, which is why I feel that now is an interesting time to write about all of this: not from the perspective of a smug succeeder, but from that of the struggling disciple, trying to turn things around again.

I am starting to get back on top of my tasks and lists again. I know how it feels to be overwhelmed, to have a brain buzzing with alerts and anxieties; and I know how it feels, however briefly, to be in control.

So - here's to engineering more efficiently, fluently and... more cannily

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!

December. Time of cheer and good will to all colleagues, rushing for presents, updating projects, Glühwein, clearing out inboxes, eating far too much chocolate, finalising reports and… 

And getting audited. 

Yes, we were audited this week and one of my projects was in the spotlight. It was all going swimmingly until the auditor heat-seekingly locked on to one particular thread of my project that wasn't really parcelled up and tied with string - ironically enough, the DFMEA.

Being shown up as lax in my own project was certainly embarrassing, one of those half-expected shocks to the system; I felt a bit like a child hoping rather than expecting not to be found out about those stolen chocolates. I was hoping rather than expecting to be able to skim over that the incomplete DFMEA (structure present and correct, values not), knowing that it was a weakness without really having polished it off beforehand. I was found out, and rightly so: that’s the reason audits happen.

We were marked down for it, of course, and I’ll have to get things back into shape sharpish.

Reading those words of mine just above (“that’s the reason audits happen”), I surprise myself with how true they ring.

Have I finally come to accept them? And if so, how do I accept them? Gladly, or grudgingly?

For years I’ve harboured a deep suspicion, a dislike of audits and what they stood for. For me, they stood for engineering by checklist, for doing rather than thinking, for rewarding completeness rather than innovation and - for the vast majority of my auditing experience - huge cleaning up operations for close to zero benefit.

When is something that is good enough not good enough? When it’s being audited.

I have experienced both sides of auditing; I have audited and have been audited. From being part of an auditing team, working alongside quite an enlightened auditing colleague, I understand that the mindset of an auditor should be a positive one, aiming to help the subject improve by pointing out the weaknesses and working on agreements to correct those weaknesses before they lead to genuine failures. This mindset should match that of the auditee. When both see the positives that can come out of the (like FMEAs) negative messages, then things are heading in the right direction.

Nevertheless, audits are a not insignificant burden on everybody involved. Couldn’t we just wish audits, along with PPAPs, away?

Well, not easily: auditing is a multi-billion dollar industry in its own right, valid across a whole spectrum of industries, and it’s a difficult edifice to start chipping away at. But even so: wouldn’t our engineering lives be so much more enjoyable without them?

Initially, yes - they would be. We would be freed up again to design and develop as we know best: we know what our products are supposed to achieve and how to get them to that stage, even if not every Excel list has been filled out to the n’th degree en route. We could potentially become more like Google, where “...in the innovative and fast-paced world that [the Google developer] lives in, you get what you get.” (From How Google Tests Software)

We would have more money and time to spend on D&D, too, not having to pay those auditing firms their crust or having to spend all of those man-hours preparing “just in case it’s audited”.

But let’s look at it another way. Let’s say we want to start using a lower-cost supplier, more than likely in the old Eastern Bloc or somewhere (usually very large) in Asia. What are these companies like? Can we entrust our intellectual property, our quality and our good name to them? What better starting point could there be than searching for a certificate alongside customer references? (well, it’s true that there are differences in auditing rigour in China, even amongst the financial big four, as The Economist magazine writes)

Audits cannot guarantee a good name, nor necessarily a good engineering company: there are firms with certificates on their walls that I wouldn’t wish on our fiercest competitors. In the same way that financial audits have missed gaping holes where the subjects have been playing the game better than they have - like Lehman Brothers, Enron and, it seems, Autonomy  - quality audits can almost be guaranteed to miss something big from time to time.

Even the auditors themselves get themselves in a muddle - our December date with auditing destiny came about when the auditing company missed a submission deadline. This swiftly became our problem when our certificates were due to expire and our emergency re-audit date last December became our annual date. Thanks, we appreciate it!

So, what are audits good for, then? Qui bono? For starters, audits are a reassuringly expensive starting hurdle to business: my industry - automotive - and many others have gotten themselves into a standardised twist, whereby an ISO / TS 16949 certificate is a prerequisite for supplying to an OEM. It’s a pay-to-play move gives potential customers a guide that the company won’t royally mess things up when they start a supply relationship.

Audits also place a burden of duty and therefore responsibility on companies and their employees – from management right down to lab technicians – to get things right. Not only to “get things right” but also to “design things right”. This applies both to the product itself and to the process of how you get the product into a customer’s hands. Ideally, an audit should be imperceptible other than having to make some coffee for a visitor and answering a few questions. Why should you have to prepare if you are living the systems that you have declared fit for your own purpose?

Umm, too much other stuff to do, perhaps? Not enough time to focus? Not enough mental energy left for yet another list-trawl?

Well, if audits and all the stuff that we have to prepare for them really are a burden, then - again, ideally - they should become the impulse for genuine improvements in the way we work, in the way we communicate and collaborate. All of that form-filling, report-writing and change log management should have a genuine purpose, even if it is occasionally completed in the grudging spirit of passing an audit. All of these items are part of the company's index of information. When we change and update those forms, we are changing history, improving it. It's about creating a legacy, hopefully one of that will make sense of our successors' past.

The one thing that can make audits bearable is for everybody involved to treat it as a human thing - checks and balances are inevitably required whenever human endeavour is at work, so go with it. Let the auditors ask the good questions and let them discover how you work - even I with my DFMEA fail this time around will have shown that overall we’re working well and are going in the right direction. So, I’ll take that “nonconformity” hit and try to improve on managing my projects along with managing everything else, and let’s see if we can find some mental space to put to use on streamlining our work so we can do better next time.

And so back to my initial question: do I accept audits gladly or grudgingly? Well, of course it’s still the latter, but at least it means that I aim to keep them as low profile as possible: for that, though, I’ll need the support of my management – and I can assure you that the audit result was a wake-up call for them, too. Perhaps better things will come of it (or perhaps more oversight and review meetings – still, they’re a way of switching the focus to projects).

One final note on all of this: I don’t recall ever hearing anything about audits when I was studying engineering at university. That’s something that should change (perhaps it has, already), as they are a real, if occasional and generally unloved, part of this engineering life. If the next generation of engineers know what’s in store for them, they’ll know to focus on how they work as well as what they actually work on.

The glance that resulted in the (low energy) lightbulb switching on in my head that in turn resulted in this blog was towards a book lying sideways on top of Dad's collection of Marcel Proust's recently translated In Remembrance of Things Past. The title (unlike that previous sentence) was pithy and the text large: "On Music," it was Alfred Brendel's collection of essays from his career as a pianist: about the music, its playing and interpretation, about selecting the right piano for the right piece and the like. It set me thinking On Engineering. What sort of essays (blog posts, of course, these days) would that entail? Brendel's writings range from the highly technical ("I note with regret that in bar 73 of A major II [Schubert] softened the staggering G major chord by turning it into a G sharp appoggiatura" is highlighted in the Guardian review) to the anecdotal, but he stays focussed on the subject of music. I had the notion (I may still be wrong and my Google searches insufficient) that there is little out there that seeks to describe in a similar way what it is to be an engineer. Whilst I am no Brendel of the engineering world (or Brunel, Tesla, or Tupolev) my blog should focus on the career of someone working as a hardware engineer.

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…)

Quality issues cannot be counted amongst my favourite activities. They can normally be categorised as "urgent-uninteresting", which is just about the best demotivator I can imagine. They're negative, cause huge floods of emails, assumptions, obfuscation and general panic. Some people thrive on this sort of situation. I, generally, don't, as was again proven by a quality concern with some Chinese colleagues.

I get involved simply because our Tech Centre has the best kit, so we can test what others can't. It's annoying, because development people rather prefer looking forwards than downwards at self-shot feet.

Nevertheless, some quality issues are useful ("never let a crisis go to waste" and all that). Some are excellent impromptu team-building exercises and others simply turn up some interesting artefacts, like this beauty below. It stopped me in my tracks - never have I seen an Ishikawa diagram illustrated so literally as by my Chinese colleagues...!

For those not yet in the know, the Ishikawa, or fishbone, diagram is a way of formalising the investigation into the potential causes of a particular issue. It's a methodology that forces you to look at each the 6 M's (others call 7 or even 8) in order to gain the full picture of what might have gone wrong to cause the issue (sorry, problem) that we're working on (the Environment one is clearly an awkward 'M-ification' for the purposes of alliteration):

Machine (technology)

Method (process)

Material (Includes Raw Material, Consumables and Information.)

Man Power (physical work)/Mind Power (brain work): Kaizens, Suggestions

Measurement (Inspection)

Milieu/Mother Nature (Environment)

I can't tell you precisely what the 5 Chinese characters represent in this one. Whatever the causes of this particular quality issue, the discovery of this putrid gem of a rotten, stinking fish amongst the rotten, stinking debris of a quality concern almost made up for it...

Engineers are, by all accounts, a fairly unsociable lot. That's of course not to say that we're particularly obnoxious in any way - it's simply that engineers have not, over the decades, dispelled the notion that we are difficult colleagues. We're not great at meeting people, we dislike meetings, can't spell and can't express ourselves with any degree of fluency. Yes, we’re generally capable of having families and we do grudgingly recognise the need for working with others but we communicate at best wordlessly, through diagrams and drawings, prototypes and graphs, with equations if we’re showing off. Thrown into the deep end of human interaction - with real live people - we flounder a little, then try to escape into our own little air bubbles, wide, panicked eyes magnified by refraction.

I threw myself into the deep end last week by attending a two-day seminar on FMEAs run by the software company APIS, which makes the rather special IQ-FMEA product family. I survived the experience. And it seems that most of the others that attended did, too. Whilst I can’t completely repudiate the notion that engineers can be a little insular or initially difficult to connect with - well, that’s human nature at work rather than the type of human in the conference.

The seminar was held at Maritim hotel in the lovely town of Würzburg in the Franconia region of Bavaria (there lurks a lot of history behind that statement, meaning that the Franconians don’t appreciate being called Bavarian). The APIS team organised the conference very well indeed, including some opportunities to get to know the town, its history and its culture, in particular its wine.

So, you're thinking: wine, history, culture, coffee. But how was it even remotely possible to fill two days with lectures and presentations on this one, dry old topic, whose output is typically a spreadsheet used only to pass audits? How can over 200 people gather to discuss the FMEA?

It’s true: most FMEAs are merely vestigial remnants of a potentially great tool. Most companies get away with paying the merest lip-service to them (they have to, in order to pass audits), as they can often rely on long experience in designing and producing their product - or they are sufficiently fleet of foot (and well funded) that mistakes can be made and quickly rectified. Yet the FMEA, like many tools, is there for a purpose and, used properly, can lead to surprising revelations and to a fundamental understanding, including a detailed library of lessons learned on your own product. The FMEA is worth exploring and talking about.

So, how were the two days filled, other than with coffee breaks and lunch? With presentations and - most importantly of all, during those self-same coffee and lunchbreaks - talk.

As a quick background of what was presented, here’s a little taster:

•  “FMEA-Lite” by a representative of Autoliv, the safety equipment manufacturer, who admittedly made the FMEA-Lite look like a thin filling of a very chunky sandwich: the FMEA portion may have been light, but it was surrounded by fat block diagrams and manually created Excel robustness management matrices that looked far more complex than their potential benefit could ever merit.
• A pair from Continental (one of whom was an ex-developer from APIS) who shared their experience and advised on the Simultaneous Engineering of FMEAs - disparate groups of people working on different portions of a larger FMEA at one time.
• There was a critique of the wording within the latest VDA guidelines from a chap from Festo
• an FMEA consultant / trainer introduced his thoughts on how FMEAs can be effectively be implemented in today’s ever more complex mechatronic systems.
• There was even a light hearted and entertaining introduction to the workings of the brains of FMEA moderators (those people who run the software, run the meetings and therefore need to be attuned to the personal and emotional signals and needs of the participants, no matter how grouchy, quiet or aggressive they may be - i.e., often engineers dropped into a very non-engineering style role).
• Some insights into the future of the IQ-FMEA software itself from APIS ("we like to stay around 5 years ahead of the competition)

So, how did I get on in the world of conferencing? Not great, to be honest. I came away with a mere two new business cards, though also with a few undocumented discussions with representatives from BASF automotive coatings, Siemens automation and Kärcher (they of the pressure washers and much more). But I didn't break into any cliques. Reading down the attendees list, I would say that well over half of the representatives were there amongst company groups: Continental, Daimler, Magna, Bosch and so on. I don’t recall meeting a single first-timer like me, either, so cliques were both inevitable and slightly difficult to break into - for an engineer like me: the value of conference networking stems from the second time onwards, when people vaguely recall my face, remember that I was kind of OK to talk to.

I’ll dedicate a future post or two to FMEAs themselves. For now, though, it’s good to have made that first step into the conferencing world…

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!

Software seems to be getting all the glory these days, with the notable exception of the Curiosity landing - but any system that uses a a rocket crane to gently place a one tonne nuclear rover into a crater on Mars is astounding. Aside from the MSL, though, it's all Facebook this and Google that - even Microsoft, the uncoolest of them all collects kilometres of headlines. I get the impression that engineers like me, working on "things" like metals, coatings, fluids, remain unlauded. In modern parlance, I work on "dumb*" things. They are non-trivial things, of course, otherwise I wouldn't be engineering them, the products I work on also have many millions of users and the company I work for even makes a profit - but it's not software.

The world of software deserves its acclaim. The engineering that I do could hardly be imagined without IT. Spreadsheets and presentation tools, web browsers, emails, data analysis software all across the spectrum to text messages are an integral part of my working life. In one sense, then, software is "merely" a tool that enables me to add value to things. Equally, I am aware of the tools that I use when I'm not in the office: music sequencers, smartphones, GPS systems - and blogging apps, of course.

All of this software resides in hardware, but in many cases the physical is largely transparent. Software defines the utility of the hardware.

So software is one of modern life's key enablers. It can be stunningly complex and is in a perpetual state of development (unless the company goes bust or is bought out for its team). The question is, though: is software engineered, or does it somehow "happen"?

Put another way: if I were to dust off my Basic or my Turbo Pascal and hop over to a software company, would I recognise what I would do there as engineering?

The title Software Engineer certainly exists. It can be found in the job pages of Facebook and Yammer. There are university courses offered in Software Engineering the world over. There is a Software Engineering Institute at Carnegie Mellon, and the Fraunhofer Institute has its own Experimental Software Engineering group.

Yet despite all of this apparent validation, the title still seems diffuse and interchangeable. Some companies avoid the title Engineer altogether, using by preference the word "Developer", which seems currently to have the highest cachet, whether the practitioner is Junior, Senior, Expert or Chief Expert. A developer friend tells me that where he works, the title "engineer" is not used at all, as it smacks of robust inflexibility grounded by paperwork, whereas developers are by nature free to react quickly and autonomously to the ever-changing requirements and bug discoveries that define software.

I see what he means (and take slight, but acknowledging umbrage at that assessment of engineering). But others use the title "Engineer" as a standard moniker - including Google, of all places. So how do they use it?

James Whittaker (now back at Microsoft) in his highly engaging book "How Google Tests Software" describes many of the development tools used by Google during software development. They seem to be parallels of my own tools. He talks about specifications, about a kind of FMEA (risk derived from what Google calls ACCs - Attribute / Component / Capability factors), about test and validation, about breaking things to find their weak points and subsequent focus on fixing those areas.

A Google Software Engineer (also described in the book as a "feature developer") is responsible for delivering tested, bug-free code to a particular project. Software Engineers in Test are geared up to write code and test-frameworks to find bugs in the product, and Test Engineers work specifically on ways to break the total product in clever ways.

It all sounds quite similar to my world. Instead of code, I write drawings and specifications. I organise testing and validation, I have to deal with change. Our manufacturing engineers ensure that product can be made and our quality engineers ensure that product is measured and released for sale. However, whilst specifications, documentation and requirements are all present and largely correct at Google, they come across as being secondary to the ultimate goal of shipping bug-free code.

This is of course totally true. They are secondary (I shudder when I hear Quality Managers refer to what they do as "value add." It's cost-added for value saved.) However there is a different emphasis on rigour between software and hardware that may be reflected in the real titles of hardware engineers but software developers.

One of the directors quoted in How Google Tests Software explicitly states "I suppose there is a fairytale world where every line of code is preceded by a test which is preceded by a specification… But in the innovative and fast-paced world that I live in, you get what you get… Demanding a spec won't get you one… I can whine or I can add value." Equally apposite: "Test plans are the first testing document to be created and the first one to die of neglect."

These statements reflect the same pressures that I experience as a mechanical engineer. We also have timing pressures to deal with, and spec writing is also a necessary evil. But the attitude seems different. I simply could not imagine such a statement coming from a GM or Daimler director, let alone from that great automotive bureaucracy, Volkswagen.

Documents and specifications aside, subtly but tellingly, in a series of interviews with Google Test Directors at the end of How Google Tests Software, each director refers automatically to developers and only occasionally use the word "engineer" as a secondary term.

So perhaps engineering is a nice-to-have concept in the world of software, a little bolted on. On the other hand, we engineers may be too static and outmoded for the modern and fast-paced world of gold-medal software firms like Google. Perhaps our production models that involve factories, process engineers and ISO / TS audits are too rigid to take the liberties that the softies can take and get away with them as often as they do.

But as we have seen, the title Software Engineer is very much in existence. Maybe we need to take a step back from software's cutting edge to where software takes a secondary seat to the hardware. Car or aircraft entertainment systems, or production process control systems would be good examples, as would be the medical equipment industry.

The clearest answer I have found so far to the question "Are Software Engineers Engineers?" lies in a job description for a medical equipment manufacturer. Here's what this software engineer is supposed to manage:

• Development of software
• Verification…of Quality Management and Regulatory Affairs
• Collaboration for the development of software requirements
• Development of the software architecture
• Implementation and integration, supervision of external resources
• Support of product maintenance
• Production and customer care

This collection of responsibilities sounds more like what I have to manage on a daily basis. This software engineer must juggle the code and its application, must (this being the medical industry) monitor specs and regulations carefully and must ensure that production is secured, whilst also designing in a certain ease of use for the end user (I wonder if they say "end user" or "patient"? I think it makes a difference…).

It doesn't sound as sexy as a startup's freedom or a Google's heavyweight fleetness of foot, and it doesn't reflect much of the pioneering spirit of a Brunel or an Edison; but it's engineering as I know it.

Perhaps the difference between the software developer and the hardware engineer really is as simple as the maturity of the market and of the company. Just as terrible auto accidents in the 1970s and 80s resulted in ever-increasing regulation, so potential privacy disasters at Facebook and Google is landing them with audits and governmental control.

Perhaps the Zuckerbergs and Larry Pages of today are the Rolls and Fords of yesteryear, and their companies are destined to become as bureaucratic as their successful forebears. The attraction of startups is that they are small and start under the radar of heavy regulation. To achieve the scale and success of Microsoft or Apple, of BMW or General Electric, they too must generate a strong, supporting skeleton. The trick and the challenge is not to let that become a fossil.

So in the end, what's my answer? Is Software Engineering Engineering? Yes, it can be. There are sufficient differences that both worlds can learn from each other, even if they cannot often transfer people (I see myself more easily transferring to the nuclear industry than to Google) but the disciplines and tools involved have their parallels. In the balance, I feel that my world could learn more from software than vice-versa, especially in terms of sleekness and agility. What could they learn from us?

Apart from great paperwork, I mean…

I'd love to hear your thoughts on this theme, too. Are you a Software Engineer yourself? Or are you somewhere in between (in avionics, say, or electronic gadgetry? Fire away!

*dumb: software is deemed smart, but it, too, can be reduced to equations and lots of "if…else" statements. Not as dumb as they sound, my components react to certain conditions in particular ways, and with more subtlety than many programmes do.

Terracotta Warriors photo from romainguy on Flickr

As an Englishman living and working in Heidelberg, I am often asked if I work for SAP, the business software giant based down the Autobahn in Walldorf. I don't, of course. If I did, I'd be writing about software development, the management thereof and how utterly astounding their legendary canteen is.

The question is not a daft one, though: around 10 thousand people work at SAP in Walldorf, forming a more or less willingly thrown together (or at least well-paid) melting pot of 80 nationalities with English as the working language. It’s easy to assume, then, that a middle-class, technically minded foreigner living in Heidelberg earns his crust and her Grauer Burgunders at SAP.

I know a few people who work at SAP, and they are generally of a particular ilk (physicists and mathematicians, i.e., not my type) so I know that I don't need to yearn to work there, but there’s one thing I envy them: resources for R&D. Globally, (2011 figures) SAP has 16 thousand employees working in R&D (12 thousand work in sales…).

16 thousand in R&D...

(drifts into a reverie)



(Snaps back with a jolt)

I’m not in that place. I am a development engineer at an automotive supplier; my development activities really only skim the outer atmosphere of the unique world of R&D. Is this a surprise? Is it a disappointment?

Let’s think about the surprise factor first. When I consider my time at university, I don’t recall ever having heard the word “resource” discussed in any manner other than as a general term for learning material. We picked up the material, used the libraries and even the nascent internet; but I was never a resource myself.

Resource was always a “hidden” theme. We were aware of time pressures with the need to study such a wide range of subjects whilst maintaining sanity and health through extracurricular pursuits, but it was always a case of everybody finding their own balance.

My aerospace engineering course did involve one larger team design project that was formative, but as far as I could see, research projects could run in a business vacuum, free from excessive emails or telephone calls, requests for assistance from around the world and quality alerts to have to jump onto. Ah - there we go. Did you notice that word in there, mentioned for the first time in this post? Team.

Entering the workplace was a relatively soft jump for me: I joined Ford in the UK which at the time was recruiting heavily - and, crucially, I joined a team. By that I mean there were several of us who could do each other’s jobs, if necessary and we worked both on improving the product and on improving the ways we worked on those products.

Recently, I was part of a globally distributed team that developed a new procedure for drawing release and approval. The word 'team' in this case represents more a collection of perspectives than anything that could really work to fight the necessary fights. We had representatives from design, from quality, from manufacturing; but none of us were interchangeable in the way that my team position at Ford was.

Developing the process itself was the fun and interesting part. I managed to find a spare license for Microsoft Visio (alas only the 2003 version which is now looking very old indeed) and used it to create the workflow. As it is a cross-functional process, the workflow runs in lanes - development, manufacturing engineering and quality - so the visual aspect was initially quite appealing. Adding the "if… then" loops and the different entry points for product at the various stages in their drawing lifetimes certainly de-streamlined it, though.

But actually running the procedure has been no fun at all. The problem is that it was implemented as a project in itself without great consideration for the resource implications of centralising what was in effect a totally distributed (and therefore wasteful, if potentially evolutionary) process.

So the current situation is that I am currently the only person in a company of over 16 thousand who can create the drawings that those 16 thousand people need.  Imagine SAP setting up a system whereby those 16 thousand in R&D could only work if I finished one particular task amongst many. It wouldn't really make sense, and this is something that I'm struggling with at the moment.

And so to my second question - am I disappointed not to be part of that resource pool? In a word, no. It's harder to explain, but perhaps this is only because of a lack of imagination: I simply cannot imagine being able (or only being allowed) to work on one problem at a time. Whilst I am trying to relearn the art and discipline of focus, it doesn't come naturally to me. I thrive on bandwidth, even if the transmissions occasionally get muddled up and jam because of it. I'm a variety type.

Coming back to those cohorts of SAPlers, though: despite their numbers, there have been reports recently that even they are feeling pressured to breaking point in their jobs. Which means that you can spread even 16 thousand researchers thinly. R&D resources generally expand to fill the product lines a company is working on; even within the relatively low number of headline products SAP produces, there is a vast number of modules that require development and linking in to others, so there's plenty for lots of clever people to do. (Google has around 33 thousand employees, Microsoft 92 thousand, of which 35k are in R&D).

So today's R&D behemoths are commercial, distributed amongst the universities and amongst the startups that thrive or die on their findings; I'm somewhere in no man's land - where are you?

p.s. Happy 40th, SAP!

The number of technical books within the field of engineering is far greater than I can count (Google gives a number of 5 million results for the search phrase "engineering books"). Yet few are the books or even blogs about what engineers actually do. I mean on a day to day basis. Yes, we solve all the world's problems, we turn ideas into reality, we make things and their processes more efficient, cheaper - we optimise - but what do we actually do? All day?

I have been in engineering since completing my studies and degree in Aerospace engineering at Bristol University in the 1990s. Whilst I could never claim to be a top engineer, I am good enough and thoughtful enough to be able to write about it from the perspective of an experienced practitioner. So I thought I would give it a go.

This blog is also a little test to see if I've been paying attention all those years...

Are you blind to detail? Source Wikipedia Ishihara diagram

"It's just a minor detail" is a commonly-enough heard phrase, with only two problems: the words "just" and "minor." Take those two belittling extraneous modifiers out and say it again: "It's a detail."

Often enough, putting a concept or even prototypes together is the easiest (and the most fun) part of a project. The main parameters are in place; detail is "the rest" required so that something that vaguely resembles a manufacturable, saleable product results. It's those unknowns that need pondering, the "not quite rights" that need purging.

Put romantically, not just devils but angels, cherubim, seraphim, orcs, gremlins and all sorts of other critters reside in detail. They battle continuously to make or break your product, whatever that might be. Wrong material or tempering grade? It'll deform too soon, or just snap - if you're lucky at the prototype stage. You got your tolerances wrong? They'll bite you within three months of start of production, on a Friday afternoon before Christmas. Overspecified things to be on the safe side? Your product might be unfeasible to make, or too expensive. When you get the details right, however, that product can go out there and do what it's supposed to do - satisfy customers and make money.
So, we "just" need to get them right.

The first thing to realise is that there are no "hero" details. Every item on a drawing or in a specification can lead to something going wrong, and every item that is not there can, too.
Picking your way through the thicket requires concentration, discipline and focus, namely the three things that are almost impossible to come by in a normal working environment.
So, alongside placing the spotlight on details, this post looks at how and when to work on details.
Without thinking, problems don't go away. Without doing, they don't go away. Normally, one of those activities preceeds the other...

One key way is thinking solo: giving yourself the time, room and environment to think. Daydreaming is often for me the best way of filtering out my surrounds and letting ideas or understanding drift into my conscious view, when I'm least expecting them. Then I at least know what I need to work on. Then it's a case of separating myself from the others and going somewhere quiet to focus on something.
Brainstorming with colleagues is another method - call a guerilla meeting, half an hour over a coffee, just before lunch to ensure the meeting finishes on time; longer-scheduled DFMEAs is another good way of at least discovering what needs to be determined and proven before a product hits the scrap bin more often than the "goods out" one.

There's a key difference between the solo and the team thinking methods: thinking is often misconstrued as "not doing anything" whereas a team meeting is by default acceptable, no matter how inefficient. Let's have a look at solo thinking, then.

Or rather, look away - solo thinking is by and large impossible where I work and, I suspect, where you work, too.

We have an office with around ten people packed into around twenty square metres. It's not a sweatshop, but it is an open shop. Generally, whenever I need to get any quality thinking done, there will be others gossiping, discussing the price of petrol, mortgages, coffee (in fact, they are always talking about the price of something). Then an empty skip lorry will race past the windows, chains flailing and rattling, simply making an almighty racket. It is simply not possible to concentrate.

So I try to escape.

I go off and make a coffee. Or I'll go for a wander to the labs, but not actually get there. I'll saunter nonchalantly down to a meeting room without any meeting planned or find an unoccupied office, sit down and open up the one thing that I want to be working on at that moment.

I turn off Outlook
I leave the phone on silent and on its charging station so that it doesn't vibrate.
I shut down my browsers.
Then I load them up again (I nearly always need them for research and many of our documents are online). Browsers are a huge distraction or temptaion, but I find that if I'm really focussed I forget to browse the news or check my private emails or Google+.
Sometimes I'll uncap my fountain pen and start sketching, or I break open Excel and start working on tolerance calculations, O-ring compression sets; or I'll start searching the internet for the one key factor that I need to define what I'm working on.

In any case, I have to admit, my task-focussed multimedia shut-down strategy can be a tad one-sided. I often need to call somebody - a colleague or a supplier - for an insight on a particular detail. Or I'll send them an email. And I disrupt their work in the process.

So I can do detail - but, like drawings, I can admire detail but I don't necessarily enjoy it; I can occasionally lose myself in detail work, but in the same way that I am slightly colourblind, I don't see detail like a real clear-headed, focussed checker can. Working on the details of a design is often an effort that is sometimes too much and ends up in frustration. I'm not your stereotypical engineering bureaucrat who will gladly and with a sense of achievement check every last entry on a drawing or bill of materials. I'm not naturally a detail person; but others are and that's why we should work together. It's what teams are for.

p.s.

Jobs I could not do because of this:

• teacher marking exams (= engineer marking PPAPs)
• lawyer (=engineer getting involved in patents)
• customs administrator (= engineer and his paperwork (= engineer))
• forensic scientist (= engineer working on quality complaints)
• politician (= engineer trying to get all parties on board)

Oh. I am all of those.

The relationship between engineers and numbers is often an uneasy one. Engineers are by and large mathematically literate after all those years at university, but we don’t necessarily feel at home in the world of maths. It’s a subject that we feel is to be dropped at the earliest opportunity.

Once we enter employment, we don’t need maths anyway. We learn the formulae and relationships that are pertinent to the subject matter at hand - and forget the rest. If we do happen to need something from “the rest”, we generally know where to unearth it and, after some thought, can apply it.

My own mathematical world is rather limited. I need to interpret test data, certainly, but have found that it’s the qualitative information that I extract that is useful rather than any best-fit curves or dynamic equations of state. I do sometimes need to calculate friction coefficients, but since the formulae are simple enough to encapsulate in a spreadsheet, I don’t actually need to know what precisely those formulae are (but I can find them if required).

If mathematics is one aspect of this relationship between engineers and numbers, numeracy is the other. Whatever results we get out of testing, or whatever design information we wish to convey, I need to talk numbers with colleagues, suppliers or customers. Given that I’ve living and working in Germany, these discussions often take place in German. Now, whilst I’m pretty good at the language from a linguistic standpoint, I have a real problem with German numbers.

I’d like to point out at this juncture that I was never bad at simple additions and subtractions in English. But the quirks of the way the German language treats numbers make me stumble when naming or hearing numbers in isolation and often I’ll simply give up if I need to engage in a little mental arithmetic.

The problem is that German numbers are - partially - enunciated backwards.

If I want to say the number 65 in English, I have a nice mental image: sixty-five - 65. However, German tells us the smaller number first: fünf-und-sechszig. This means that my innate numerical image is messed up and I need to hold figures in a buffer before I can complete my own natural image: (5)´6 -> 65. 

My internal workings are a very fast version of this:

“OK, he’s just said the number five, and there’s an “and” being said, so there will be a number coming before it… So, what is it, then?… Wait for it… Ah, OK, so it was a sixty. What was the first number again? A five. So, that sixty was the tens digit and five was the unit digit, so he meant to say sixty five.”

That usually works, as I say, when numbers are mentioned in isolation. But having to perform arithmetic with them seems to be a mental effort too far.

“So, he wants me to take five and sixty, then subtract eight and twenty. So that means… scramble…scramble….seven and thirty.” My German colleagues, who have grown up with this nonsense, can cope with this much better than I have been able to and are therefore usually much faster at computing the ansewr and beat me to it, meaning that, after a short while, I gave up even trying.

The mental effort is compounded by larger numbers where the hundreds are spoken first, then come the units, followed by the tens. So these end up as:

“Six hundred two and fifty.”

My internal numerical imaging is so strong that as well as my problems in parsing and understanding the numbers I hear,  I have problems in saying them, too. This has caused at least one near miss in my time as an engineer in Germany, where I told a prototype builder to make something one hundred and fifty eight millimetres long, rather than one hundred five and eighty millimetres. Thank goodness for sketches and prints, is all I can say to that.

I know German primary school teachers who have confirmed that the German numbering system really does create difficulties for children at school - but given that quite a lot of German engineering seems to work reasonably well, it does not seem to be a handicap for life.

Other languages have their idiosyncrasies, notably (in my experience, anyway), French with its sixty-fourteen (for 74) and four-score-and-three (for 83): but since these quirks are still sequential, I can cope (but still hope that the Belgian "septante, octante" and "nonante" take over the francophone world. Maltese numbers are so complicated that they have been almost completely done away with; but there is even a slight hiccup in logic in English: "thirteen", "fourteen" and so on are a version of the German, with their units being named first. But it's such a short sequence of exceptions to the rule that I would treat them along with "eleven" and "twelve" as practically being units in their own right.

If you’re a German reading this, I’d be fascinated to know what your mental processes are for this, and whether you feel that you’re at some kind of mental processing disadvantage because of it; or even if you feel that it’s a kind of mental brain training that gives you that additional edge.

If you’re an Asian right-to-left reader reading this, I wonder if your mental image of numbers is different to mine, or whether the western numeral notation system has become so dominant that you think sixty five as a six followed by a five.

Now of course, it can sometimes simply not matter which way the numbers crop up…

554 + 445 = 999

545 + 454 = 999

… But by the time I’ve worked that out, it’s too late: I’m frazzled and am looking for the nearest pen - or a cup of coffee.

I had a couple of hours today at work in what I can only describe as -for the workspace, at least - blissful calm with my laptop offloaded to IT for new software and general updates. It was positively therapeutic having my twin displays switched off, docking station bare and keyboard stowed away. All of a sudden, I could see my working environment for what it was - a mess.

So I cleared the decks. Drawings that had lain scattered around in various states of checking or revision were brutally culled. Specifications for review that had sat there for months were shredded. Samples for testing were tidied away for the ever decreasing likelihood of them being required (the usual samples that arrive with no reference documentation or any indication of what they were for, let alone including a formal test request from someone who knew what they wanted). All of those things had become mere symbols, signs to my colleagues that I was - am - busy.;Which is of course a far cry from doing anything useful.

Finally I could see my desk again. That little expanse of off-white reflected my inner calm, the sun shone outside and my cup of coffee smelled great…

Then I realised that I need to do some desk clearing with my blog-life, too. I started this blog with the intention of writing about those aspects of engineering that generally aren't taught in uni. Things like PPAPs or finding things. As part of my background research to this blog, I came across a site called engineerblogs.org with some decent observations from a range of writers. They had a notification up saying that they were looking for writers, so I ended up submitting oneor two posts, which became threeand soon four. I'm still a guest blogger there, but I realise that I am neglecting my own blog.

Hence the need to order my thoughts in terms of what ideas belong to this blog and what to EngineerBlogs. I can't say I'll have any answers straight away, but I don't want to switch off the Canny Engineer just yet.

It's a while ago now, but over Christmas, I was (watch out, this is going to get exciting) doing the washing up after my sister had made the dinner. (Just to write "pork chops" does the meal an injustice, but that's basically what it was). The item I cleaned last, because it had by then rather unappetising looking bits of wet pastry on it, was the beater from our old Kenwood mixer. As I washed, I remembered how this piece of utilitarian design had always fascinated me through its complexity and simplicity. So I took a photo, which I just rediscovered:

It is designed as a 'K', instantly bringing the branding to the forefront. Whether or not this is optimal for mixing pastry I cannot say; but it works very well, generally resulting in great cakes, so its impact on the mixing dynamics of pastry is at least not negative. Its complexity is subtle, but everywhere present. It warps in all three dimensions, combining rigorous straight elements with beautiful curves, tubes with flat and developing blades.

 Some of the joins are no longer quite so beautiful on our example, but after over twenty years of use, that can be expected. Doubtlessly the assembly process has improved significantly since then (or has been made ever cheaper), but the K-Beater design remains to this day and, even when mass production using 3D printing becomes commonplace, it will remain in the future...

 A classic.

At the very beginning of this blog, one of the questions I asked myself was - what do I do all day? Between cups of tea or coffee, lunch and hometime, I mean.

(an aside; had I not settled down for a cup of coffee and a natter with a colleague recently, I wouldn't have heard of silane coating systems, nor he of critical entanglement in polymers, so coffee breaks do have their uses).

It's a tricky question to answer, in reality. We have where I work a form of time tracking database where we record the hours that we spend on particular projects. I can't extract my own time from each pot, though, so I'd be working on overall team trends, which would only loosely represent my own. Suffice to say I'm not that interested in setting up my own private tracker; for now we'll say that I am pulled in so many different directions, it's difficult to focus on any one activity for any length of quality time. One task that takes up an inordinate amount of time, one that I want to discuss here, is finding things.

Others would refer to it as research, but sticking to the simpler term of "finding" better reflects what I am usually doing. Our labs have produced thousands of reports in the last years. Many are for repetitive tests for series production control or "requalification", lots are investigations into manufacturing or quality issues. Many are validation reports that prove to a customer that we can deliver to an overly complex and largely unchallenging specification. We even have some that are reports on new developments (gasp!). At present, all that good data contained within those reports is effectively fossilised in the hardening goo of Microsoft Word.

How do we detect patterns? Generally, we don't. How do we find the totality of relevant test reports over the years for a given product? I won't say that we can't, but it's harder than just tapping a query into a Desktop Search. We can search and filter through our test database, but that's clunky, too (searching across several years? Forget about it).

So the eternal problem remains eternal - how do we develop the relevant knowledge so that we can design better systems? That's one of the key challenges I think we face.

A small example: recently I had to answer some questions from a colleague in Korea regarding a hose connection. Simple, on the face of it. The connection requires a particular tube endform profile to ease insertion into the hose and to promote the fairly crucial function of sealing. Unfortunately, the drawing he was referring to was created in 2003 and I had no idea where the design principles that led to that particular drawing came from.

I searched and found… another copy of his drawing, but not much else. So, it came down to the oldest of information transfer systems; colleagues. The colleague who created that endform drawing all those years ago still works in my department and ask him I did - but could he remember for the life of him how he arrived at those particular dimensions? No. What and where are our tools? Here's a possible search pattern:

1. Desktop search for anything containing that part number (emails, report, lists, etc) or description

2. Search for reports containing that part number or description

3. Search for reports containing similar parts of a similar description

4. Search for relevant specifications5. Ask colleagues

If nothing interesting is dredged up by that lot, then it's a case of redesigning from scratch. How do we do that?

10. Use Design of Experiments principles to get parts made at various diameters and angles and tested

20. Request some Finite Element Analysis on the joint to ensure that nothing's going to give too soon.

30. Get some fluid dynamics studies done on it to ensure that I'm not overly constricting the joint

40. … umm, file a report somewhere (go back to 1.)

The answer here would then be to link the report to the drawing somehow, either simply by placing the report number somewhere on the drawing, or by placing the link somewhere in the CAD model, or as an additional link or document next to the print on our SharePoint system.

Yes, we use SharePoint. It's clunky and has some great functionality holes at the moment (we're still on version 2007), which means that people don't like to use it. However this, or a dedicated PLM system, is the way forward in terms of linking everything up.

Curation of data is also important. Labelling, Keywording, making more searchable. It's a dull and dry task to start or to perform retrospectively (company librarians required), but if it can become second nature to document control, it could help.

Generally, putting data to use to obtain information, knowledge and even wisdom is becoming ever more important: Big Data is Big Business, as HP proved by stumping up $11.7 bn for Autonomy corp. In theory, using an Autonomy search would be better than hit and hope: hitting the Windows Desktop Search button and hoping that you've entered the right keywords, both in the search and in the document (and praying that the report was written in English by somebody who could spell). But I've only experienced Desktop Search and I don't expect to see such enlightened methods used where I work.

Another tack is social. I am a follower of blog, Confused of Calcutta, run by J.P. Rangaswami who now works for Salesforce.com. He is a true social enterprise and open market evangelist who loves the ways of communication available to us with Facebook, Google+ and their more enterprise-tuned cousins, Chatter and Yammer (an unfortunate name that sounds like the German for "to complain"). The idea behind these tools in the work place is an interesting one. Using my example above, I could write on my wall: "Wondering why this here endform pilot angle is 32° and the other 38° and whether or not it matters in the slightest". The post will be seen by all of my followers and - the theory goes - one of them may know the answer, or know where to find it. Social beats email because the author of the question does not need to think about who a mail would need to be addressed to, who should be "carbon copied" on it and does not need to run the risk of either missing people out or annoying disinterested parties. Social beats email because the act of "liking" or responding to a post broadcasts that action to the connections of the person responding, potentially creating a snowball of knowledge.

However, we all know the downside of our social networks - signal to noise. How can we ensure that the right people even read our question and hold it in their active mental buffers for long enough to action in amongst all the other questions, observations and general banter going on around them? This is where filtering comes in - but filter incorrectly and you'll miss the occasional important missives in the storm.

So, right now, I don't know. In so many ways. If you've used Chatter, Yammer or tools like Autonomy, I'd love to hear from you. Has it transformed the way you work, the way you search, the way you engineer?

In the meantime, I'd best get back to what we engineers do best, which is to… Umm, where did I file that job description?

There's one thing that I need to get off my chest early on in this blog, as it has been weighing on my mind for some time. It is the bane of my automotive life thus far, the PPAP.

Almost nobody knows or nor really cares these days that PPAP stands for "Production Parts Approval Process," nor that the system is responsible for terabytes of redundant data. The idea behind PPAPs is - I admit - sound, in that each and every part in a car is fully validated before being built into a vehicle. However, having worked on tube fittings for a few years and come across PPAP submissions "weighing" 26 megabytes for threaded nuts weighing 13 grammes, and still being wrong, I feel that the PPAP process itself needs investigating.

The PPAP is an information pack that includes the drawings, measurement data (with capability), test data, measurement and test equipment certification, FMEAs, control plans and process flows for the part in question. All of it needs to be correct to be accepted by the customer.

It was created by the AIAG (Automotive Industry Action Group) that originally consisted of the "Big" (now "Detroit") Three of Ford, GM and Chrysler. One of the driving principles behind it was to standardise the requirements for these three manufacturers so that their suppliers need only produce one data pack per part and not have to reproduce it with tweaks for each customer. The other key principle was and remains that parts will fit and work properly when they are assembled into the cars they are destined for. Equally, the PPAP should prove that the supplier is ready to produce good parts at volume and it provides baseline information for the life of the part ("back then at the beginning is was like that, now it's like this"). However, the PPAP system has become a monster. This monster has generated its own sub-industry; dedicated employees who work only on generating or approving PPAPs, and people like me checking supplier submissions like school teachers marking essays. There are great chains of PPAP submissions, from sub sub suppliers to suppliers to the OEMs, and the whole system is populated by disinterested humans.

The number of submissions that I have checked and rejected in the past for vast swathes of missing information was depressingly large. So these packs (of lies) are being batted back and forth from server to server, person to person and hours are being wasted the world over.

My relative fortune in my secret PPAP life was that I only had to check the technical aspect of the submissions; somebody else in the quality department was responsible for going through all the other documents and certificates (generally "is there something here that looks like a certificate, or not?"). But even the technical side of things, which really should have been simple, always seemed to lead to confusion.

Why should it be simple? Well, there are drawings with dimensions (some with complicated GD&T, admittedly, but still doeable) that need to be measured (and not just reported with the value "OK"). The supplier just needs to check off the dimensions one by one and show that what is being produced on real parts meets those requirements. Fine. But, the drawings also have words on them, sometimes in the form of specifications, which should give the supplier a small hint about some other aspect concerning the parts - like, say, performance - but often somehow don't. Maybe it is actually all just too subtle and not simple at all. It was alas very rare in my experience to receive a PPAP and to be able to complete it there and then, on the spot, no more questions asked. So not only do the PPAP submissions need to be sent along the chain of suppliers, they need to be reworked and resubmitted. Usually this involves testing being (re-) started just as the parts are urgently required, which means that we have to grant deviations for a limited period until all of the testing is completed (corrosion testing, anybody?), we have to request deviations of our customers and we have to keep track of those deviations as well as the versions of those PPAP documents... and so on.

So, there's lots's of time wasted, there are megabytes of redundant and duplicated information sloshing around, repeated for each of the approximately 15000 unique parts in each and every car driving around the world (I'm not sure PPAPs are used by Khodro in Iran, however).

And yet, PPAPs, like audits, are impossible to argue against. I recall hearing that Continental tried to settle on a basic level of PPAP above which the customer would have to pay, but I think that rebellion was quickly crushed. If you've heard more about it, let me know in the comments.

In the end, my recommendation is that, if you're a young budding engineer looking for a first job, try to avoid anything that says "PPAP" on it. If you still want the job, then make sure that the PPAP bit is not too high a percentage of the job and is for a limited period only - and spend that time finding someone else who will do it for you (preferably not an engineer!).