Early in my career I joined a company that was pursuing a previous form of ISO 9001 certification. One Monday morning, every inbox (the box type, not the digital) was filled with a photocopy of a quote from that great 1960s book by Robert Pirsig, Zen and the Art of Motorcycle Maintenance:
“Quality is a characteristic of thought and statement that is recognized by a non-thinking process. Because definitions are a product of rigid, formal thinking, quality cannot be defined.”
A bit obtuse and clearly provocative, given that we were all chasing a certificate, based on strict compliance with procedures (as the standard required in those days). But it did get many of us thinking, and for my part to read the book.
And what a great read that was! Not as bizarre a hippie trip as I expected, but instead a deep discussion of what this ethereal idea of “Quality” should be. Sounds dry, but I found it to be very readable.
If you don’t know it, the book uses the metaphor of a motorcycle. To some, a bike looks great, and that is a form of Quality. To others, it is a perfectly worked-out machine, and that is also Quality. The book argues that true Quality is in fact both coming together: the intuitive with the functional. As an engineer I thought it made a lot of sense.
Over the years I have spent a lot of time analysing engineering systems. During this time, I have seen the tools for the job, engineering software, come an incredibly long way. Graphics these days are realistic-looking and instant, while processors can handle a phenomenal amount of data. It takes a whole new skill set. In a recent cable-lay analysis, the engineers were running no less than 20,000 simulations to produce a single set of operating envelopes. The task was as much about data manipulation as it was about naval architecture.
So, to my point. In amongst all the programming there is as much need for engineering good sense as there ever has been, or as Pirsig calls it, “gumption”.
Consider this recent example. My colleagues and I were investigating a wear problem with a very long, flexible pipe. The problem could be represented simplistically as a chain passing over the lip of an overhang. Easy enough to hand-calculate the reaction forces at the contact point. However, when we ran a finite elements model of the system it said that the reaction force was negligible.
Which was right? Temptation was to believe the software rather than the hand calculation – after all the model was so realistic. Except that it was also wrong. The problem was a nonlinear one and the finite elements application simply couldn’t handle it. Lesson learned: know your software’s range.
Another case. Operating envelopes for a cable lay installation had come out with a conservative feel to them. The next step was to batch up another block of simulations around the most severe wave in a 3 hour weather event. After several days of processing time, the new envelopes were produced and showed a huge improvement. Too good in fact. It turned out that one incorrect sign on one number, repeated in 200 input files, had resulted in the wrong wave being picked up. An important catch.
Practitioners will tell you that there are many things to watch in analysis, but the general message is this: while software is powerful, its use must marry with a healthy dose of practical insight. Again, the take away from Zen and the Art.
So let’s embrace the amazing power of software and maximise its effectiveness in cracking open tough engineering questions. And let’s also be sure to keep that all-important experience steering the equations. A good analysis is always a team effort.
To quote Pirsig one more time:
“if you have gumption and know how to keep it there’s absolutely no way in this whole world that motorcycle can keep from getting fixed”.
Nigel Robinson is managing director of Apollo Marine and Renewables