Ship it

Finally! Our long-awaited prototypes have arrived from the shop, and they look presentable. All they need now are some measurements at a specialist lab, additional treatment at a coater or, if you’re happy to chance it, assessment by a customer… and our enthusiasm hits a wall as we realise what comes next. With a sigh and a last sip of coffee for what will probably be a while, we steel ourselves and enter the arcane world of packaging, form-filling, cost centre allocations and handcarts - namely, shipping.

There will be boxes to find to fit our goods, filler to prevent rattling and damage, packing tape, too (bonus points if you have one of those hand-held dispensers with the jaggedy cutter available); no doubt you’ve already equipped yourself with ruler and scales, plus pen and paper to jot down the parcel’s weight and dimensions for when you have to fill out one of those shipping forms later. Perhaps you’ve been thoughtful enough to write an accompanying letter, and alert enough to have printed it out, signed and even put it into the box before taping it up. But you didn’t just seal up your contact’s details that were in the letter into the box, did you? You’ll need that perspn’s email address or a phone number for the form, too.

With steady resolve tinged with trepidation, as a supplicant to a sage, you pile your slightly too heavy to carry box and sundry notes and scraps of paper onto a cart or trolley, and trundle across site to the shipping department, where I can only wish you the support of willing and contented colleagues. Form filled out and ready to go? Great! But no! For shipments to other regions, you’ll have to slink back to the office to sift through and decipher mysterious customs categories under which to declare our goods, fearful of the potential delays and further costs that will be incurred if you get it wrong on the additional forms you took back with you, or had to find somewhere on the network and print out yourself.

And on it goes - finally getting it sent out, obtaining the tracking number to email to the recipient, perhaps monitoring the shipment over the next day or two. It can be exhausting, and it feels… well, perhaps a bit mundane.

Engineering is (largely) mundane

Packing and shipping is just one example of the mundane that deflects from our engineering, dragging it back, we feel, into some kind of bureaucratic swamp from the blue skies of thinking that we strive for. There are plenty of other such activities: receiving and booking goods and prototypes, planning business trips, filing expense reports, logging IT tickets, organising meetings (attending meetings!) - they can all feel like disruptions to our engineering flow: we’d much rather be dreaming up or working on solutions to immediate problems, than “just” plodding through this admin and bureaucracy.

But what if these actions are also engineering?

Even if we don’t possess the mindset to really make those “engineering-adjacent” activities our own (thank goodness there are others who seem happy to fulfil those roles), without them our intended products - just as clearly, in the extreme case, as if we were to forgo CAD modelling or simulation or validation testing - simply wouldn’t get made properly. Which, if engineering is the fulfilment of technical intentions, also makes them part of engineering.

Have someone else do them?

There are companies (German Mittelstand companies, for example) where someone else does all of that administrative stuff for you - assistants to make the calls, box the parts and get them shipped. There’s a case to be made that that’s actually the most efficient allocation of resources. But it is, fundamentally, the same thing: we need and expect to eventually get the results, and when have we ever been able to mutely hand something over to someone and expect the correct outcome? We can’t seriously do that: we have to specify our needs and transmit them to our helping counterparts.

That, too, is “a mild case of” engineering: we specify something that needs doing, and the better the specification, the more likely it will be that the output will match our expectation more closely.

Feel the community

Engineering is part of life in a company. Each individual action we take as engineers and the sum of them all reveals the realities of that company life, how everything fits together, or doesn’t quite; how the company tries to protect itself from the risks of error or fraud; how we’re all in the same boat, operating often ridiculous-adjacent bureaucratic systems, often without a clear reference guide, with not always clear outcomes - and how it can all make more sense and be more engaging when everyone pulls together with humour and good grace.

Feel the project

There’s also something in the argument that it’s better to “feel” the product, to really experience it as it develops within the project. Wrangling parts into boxes, or fitting them into test equipment, or visiting the production line can bring you closer to those technical objects, linking what we see “through the screen” to the physical perspective whilst engineering what we engineer.

In Eric Berger’s book Liftoff: Elon Musk and the early days that launched SpaceX there’s quite the implicit critique of a particular type of engineer:

At some government labs and large aerospace firms, an engineer may devote a career to creating stacks of paperwork without ever touching hardware.

Those stacks of paperwork (or Excel files, PowerPoint presentations, but also CAD designs, FEA simulations) help the project to progress, of course, but at the expense of feeling the product.

At least activities like booking travel, which, granted, truly isn’t that much of an experience, give you that sense of breadth in the company - what it all gets up to to ensure its progression - and the travel itself is an experience, even if it does involve sitting around in other forms of moving boxes, most of the time.

What this all drives at is what philosophers call the phenomenology of our undertakings, the experiences and how we “feel” it all through our senses, as engineers, as humans.

Isn’t it all engineered?

The thing is: what objects and systems have we been using all this time? If we think about it, don’t they also come across as being engineered? They manage inputs and outputs, capture certain forms of logic and reason, and bring us a step closer to our goals, even the shipping systems and the forms and the costing systems. They have all been designed and built (or have evolved) for robustness and accuracy, from the humble cardboard box which has already been shipped five times, to the robust tape and the goods inwards receiving systems - they are all, too, the result of design and a form of production, presentation to the market and were deemed - by whom, exactly, under what criteria? - good enough, fit for purpose.

So, whilst the “control switches” are different to the ones we use in our daily work, they are there, they serve our purposes and help us to achieve our goals, just as much as Excel, PowerPoint, and our favourite CAD and FMEA tools.

Engineering contains the mundane, the mundane engineering

All of these mundane actions can be treated as being “of”, as well as “along with” engineering. There’s the case to be made that, as a result of the this, we should treat them with the same mindset and discipline as we treat our “true” engineering activities. We may not like them as much, or be as good at them as we would like, but with that mindset of valuing those actions, we can become better at them, and our products better with them.

The artistic flipside

The counter case would be that of course we need these systems, just as trains need rail and our PCs electricity and cloud servers. They are infrastructure: complex and important though they may be, they are “just” infrastructure to us, when we’re engineering: background. Logging in to our workstations in the morning isn’t “engineering.” It’s just preparatory work, using the infrastructure around us to elevate us to the correct, expected level of work. It helps to get us into the zone that we need to be, focussed on the task at hand, tools usefully evaporating away and around us so that we are only seeing and interpreting our work towards the product.

It’s perhaps like a sculptor who needs the block of marble to be there where it can be worked on, but doesn’t “care” how it gets there. Only when focussed on the block and the form steadily being revealed; when setting the hammer and chisel at the precise angle and gauging the required force to chip and glide away: only then can the artist be the artist, truly.

Of course the artist needs to purchase the marble and to be paid for the work, of course tools need to be maintained or replaced, but those are non-core activities that could also be done by (skilled, for sure) lackeys and apprentices.

Perhaps that’s the true test of what is engineering. Could someone who gets our parts shipped out take over our work? Could they really interpret what we see, feel what the right course of action should be to resolve that tricky little set of clashes or contradictions that confront us? Could they even see that there is a problem there at all?

Mastering our metier and our tools gets us into our bubbles, focussed on the value that this product should gain. Ideally, we could murmur an aside: “that prototype needs to be shipped out”, and an AI agent would fill out the forms for us, ask someone to collect it and box it for us, whilst we continue working on the next phase of development.

But that would also mean cutting ourselves off from the rest of the company, and the messy humanity that that entails. It’s finding the balance between the two that makes engineering - despite its technicality, its techne and its hermeneutics - nevertheless a human activity, full of politics and phronesis, to use terms that bring me right back to the beginnings of this engineering blog, and to Aristotle. As two of the sub-headers above intimated: it’s about feeling our work, our lives, and making them not just “value-add” but also worthwhile.

Today’s Guardian crossword puzzle brought up the word “incipient”, which is a great fit to my previous post, What we engineer, referring as it does to something developing or beginning to happen.

Incipient was the clue - the answer was “inchoate”, which is more about something just begun. These are words that I’ll bring with me on my continued slow-plod thinking about engineering.

It’s almost as if René Magritte was thinking of engineers when he created his famous painting The treachery of images, famously undertitled Ceci n’est pas une pipe, which I am sure you will recall looked almost exactly like this:

Is it a pipe? In the minds¹ of most engineers, it both isn’t, as Magritte insisted, and it is, and much more besides.

We’ll certainly talk about and refer to it as a pipe at work and - probably very briefly - if family or friends ask about our work. Since pipes rarely occur by themselves in a system, it will carry a distinguishing name, too: the feed or return pipe, for example; left or right, front or rear; high-pressure, low-pressure; gas or liquid. It might be called synonyms of the word “pipe”: tube, line, conduit, etc; it might be a hose. With such distinctions in the name, we as humans automatically grant it an identity that turns this idea of a pipe into an individual. During project meetings, we’ll talk about its status, open issues, timing, costs, suppliers and so on, all as if it were an object we could reach out to, pluck from the bill of materials, and place in front of us on the table. That image of it firms up the identity, even if we know that, in reality, it won’t be a simple, dull grey.

We’ll talk about its data as a 3D model, too: who needs to know what about it, how up-to-date and settled or mature it is, where the data is stored and whether it has been synchronised with its counterparts in the rest of the system.

Ideally…

Clearly, my pipe doesn’t yet contain enough information to be useful: it’s an idea or a concept that hints at what could be. Right now it can’t be connected to anything, not even virtually, as it lacks important features such as endforms and fittings, or any information as to what it’s to be made of.

It lacks itself, in many ways: it’s incorporeal, a “mere” representation, both of what it should be - a pipe - but also of what it isn’t: a pipe, yet. It is made up of (digital) bits and (human) ideas, not atoms, but it’s buzzing with identity and potential. In our minds, that image and its identity are hooks on which to hang further data and information that help to refine our engineering interpretations and definitions of it, to bring the pipe as we see it now closer to matching what we intend it to be.

As the researcher and philosopher of information Luciano Floridi would point out, our image of the pipe is a sign or symbol, a token: in all, a proxy, of some specific thing that is to be made. It stands for the pipe, but doesn’t stand in for that thing. Our intention of the pipe can’t carry any fluid, only the intention of a fluid. Whilst Gilbert Simondon wrote of The Mode of Existence of Technical Objects, what we’re talking about here is the mode of existence of technical objects that aren’t yet.

Data upon data, information and product

My representation comes from a CAD model. This we’ll want to update and complete, then send to someone (another mind) who will have to interpret and act upon the data by, for example, starting to develop the bending process to convert what was implicitly a straight piece of tube into a correctly, intentionally, bent pipe. We’ll probably need to derive drawings from the 3D, and will certainly have make sure it’s been properly and sufficiently specified, with materials and tolerances and other quantifiables, before we can distribute the design data more widely.

As the informational load associated with this part begins to increase, its sub-components, features and functions begin coalescing for us into the idea of a product that could be delivered to a customer somewhere, ready to fit into their system. Specifications and requirements (themselves needing interpretation) preceding, following and accompanying our CAD models, will result in digital simulation and then physical test samples (which, although now physically present in the world still aren’t the “thing” that we sell), followed by validation reports (always returning to data); the design generates cost estimates and expected profit margins and contracts then, eventually, hopefully, an official release to enable our object to be made and sold at volume, profitably.

There are many layers of information through which we can view it, but sometimes, more often than we realise, we simply call it: the pipe.

Let’s return to the tool that helped me to produce that simple idea, CAD.

Assembled for duty

When we see a CAD model on screen, we can apply several different mental layers of interpretation to it. We can correlate it to the intended product, as I mentioned above, or to specifications, functions, costs and all sorts of other aspects.

We use CAD to define the basic geometry of a product, which matures as our models and intentions progress. What we see on screen also informs and affects our design, perhaps even our intentions themselves. But what is a CAD model, actually, especially that of an assembled product? As a colleague of mine pointed out recently, a CAD assembly isn’t really much more than a list of the parts and components that it contains, plus some positioning information.

A little more precisely, a CAD assembly is a list of the components that comprise it, plus the “news” of their positions and relations to each other, in the sense of what features of which part are connected to which features of which other part, and where they all sit in space. Combined, CAD and PLM programs enable the integration of a very rich set of additional information, like materials, coatings, positional tolerances, constraints and mechanical degrees of freedom, special characteristics, and so-on, plus the metadata of the assembly itself, such as its maturity state (in work, released, etc), revision levels, authors, contexts and - as always - so on, all related to this one object (and all other associated objects).

Part and partial

The interesting thing to me is that those parts used in the assemblies are, at heart, the same in nature as the assemblies. They are not much more than a list of sketches and features plus (the news of) their dimensions and relations to each other in the sense of what elements of which feature are related to which elements of which other feature, plus where they all sit in space.

Actually constructing those parts in 3D requires a trained mind, ingenuity and patience, and the ability to apply clever methods to achieve the goal of describing the intention of the product - which is why we often see companies employing specialist CAD designers to focus on that work, in the same way that engineers don’t always end up hammering the part into shape (or into the final product), unless they’re working at a startup, or on very early prototypes. CAD designers are a bit like the software developers of the mechanical world.

The combined skills of engineer and CAD designer result in the 3D representation of that part that indicates how it is intended to “be” in the future: again, that word, intention.

Even less real

Now we’re in this flow, we can consider those sketches and features themselves. Fundamentally, they are “nothing more than” code describing basic shapes and complex curves so that they are interpretable by our workstations, both for further logical operations and - in our human-engineer-centric fashion - for displaying the results on screen for us to interpret.

Perhaps that’s the crux of what we’re considering here. Within this hierarchy of data, reaching all the way down to digital bits, up to fully manipulable 3D models and all the way back down to synapses firing, we’re constructing mental images, generating and connecting information and knowledge that we need to be as robustly interpretable as possible, so that when we come to pass on these informational ensembles to others - people, organisations and machines - who will, ultimately, make, test, buy and use the “real-world instantiations” of those models, we will be able to finalise the development, have met an SOP (Start of Production) goal, and call the project a success.

Return to data

As complex systems become ever more simulateable and “senseable”, we are entering the realm of the digital twin, where data returns to data. The physical objects that are doing work in the world are one aspect of the value that we have achieved, but the data that they produce and return to the models is just as valuable.

It’s like the data that our apps produce to send back to the makers… well, for advertising purposes, mainly, but also, more helpfully, to understand how we use the app and to tune their work accordingly.

Eventually, perhaps even soon, even in my world of mechanical design, data will be managed by data to create new and better data, all within machine intelligences.

This is where the ethics of the thing arise: should we set a minimum level of human interaction to accompany artificial design intelligence (generative design, etc), or could we envisage black-boxes designing things for us and rating only the outputs? I guess that’s a topic for a future post (by my AI agent…)

Gamification

There’s an interesting offshoot to this line of thinking: a pipe for a computer game. There, the pipe never leaves the digital realm, but retains many of its intentions, including that of carrying some (no doubt toxic or lethal) digital fluid. However, since it stays digital, it doesn’t need any “entry visas” or any other passport documentation to enter a market in the real world.

The mere fact that it doesn’t enter the physical realm appears to mean that it needn’t carry as much information as a “real” thing.

Thingifying it²

Once our original pipe has been released into the market wild, the question still pertains: What is our pipe, in the end? Even that isn’t always clear. From our initial sketches and CAD models, whole manufacturing lines have sprung up to make pipes by the thousands each day: sales and forecasts are loaded into ERP systems, machines and tools get swapped in and out to make certain numbers of these pipes - or whatever it is we’ve been working on - quality tests and measurements are made and logged. Boxes and cartons, racks and dunnage have been designed and made available to ensure safe and efficient handling, and our products are now distributed widely, perhaps even globally, unobtrusively doing their thing.

Is one of those pipes, somewhere, our pipe? Are all of them, in sum, or is the whole apparatus behind them “our pipe”?

Or is, really, ceci our pipe?