The Canny Engineer Thinks

In praise of Process

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.

Sustainable Engineering - a circuitous book review

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!

Trapped in the validation nation

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.

Engineering Things Done

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

On Staying Engineer

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!

The power of the sketch

I was impressed by Enrique Scalabroni from the first day I met him – at Williams, in 1985.  He’d turn up every morning in a local cab and always leave late at night – also in a local cab.

via peterwindsor.com

This time, I simply want to share somebody else's blog post with you, The Spoon Test by Peter Windsor. It contains two videos with Enrique Scalabroni, a designer in the Formula One world, explaining the Coanda effect with some cutlery - and, in the second video, some wonderful sketching.

Never underestimate the power of the sketch!

Presenting in my pyjamas: to Shanghai, Bangkok and back

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?

On cracking up

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...

'Tis the season to be... audited

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.

Book Review: How Google Tests Software

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