Dropping drafts

A review of Umberto Eco’s The Island of the Day Before

created 2023-09-06

This is a most typically Umberto Eco book, of an unknown, uncertain narrator reconstructing the putative, fragmentary notes of a shipwrecked passenger of a sailing ship, weaving them into an improbably rich, thoughtful, infuriating and nebulous narrative.

Had I not read Six Walks in the Literary Woods, Eco’s talks on his theories of narration, including the constructs of the Model Author and the Model Reader, had I not already re-read The Name of the Rose and Foucalt’s Pendulum, I may well have given up on this book.

Is Agile agile?

created 2023-09-28

I remember years ago reading about an almost unbearably enlightened concept in project management called Agile. I wished, as we trudged along those familiar, well-worn yet somehow always overgrown, brambly and muddy paths through gates and past millstones - sorry, milestones - towards yet another similar product launch in the automotive industry, that we could put those paths behind us and start afresh, be agile.

The name itself was glorious, tantalising, joyful, even, bringing to mind fleetness of foot and unbounded creativity with the goal of bringing something new and fresh to the world.

That, I had to admit, didn’t seem to very closely describe the world I worked in. With Agile’s origins in infinitely malleable software, I knew I would never personally experience agile project management. Herding recalcitrant parts into vehicles was always going to be an uneasy fit with agile methods, I was sure.

I would never experience agile; until I suddenly did, at my new company in a new industry - and I have some thoughts I’d like to share.

No, agile is not agile

What I can say, after five cycles of sprints, workshops, reviews, retrospectives and planning is: the method never for a moment felt agile.

In our short training course we learned how we could achieve a goal even within the constraints of stupidly and very artificially short development cycles. Rapid feedback loops would trump planning and design (which always leads to trial and error anyway).

But the way I experienced our agile project was remarkably rigid. We brainstormed a load of User Stories against an equally brainstormed set of OKRs (Objectives and Key Results), which formed the “Backlog” (even though they weren’t at that time uncompleted or delayed, which is my usual term for items that are in backlog), then dumped a load of them into the first Sprint.

That Backlog was in one sense the Prologue to the whole project, and our very own, self-defined Millstone.

Now, of course we weren’t totally naive about it: we knew which User Stories represented basic functionality and which would naturally come later, once these basics were sorted. But a number of difficulties with our systems meant that we got bogged down even at that early stage and the prospect of closing off User Stories in an acceptable and documented fashion diminished day by day.

And then, suddenly, it was time for the Sprint Review, for the Retrospective from that Sprint and planning for Sprint 2, with the Backlog looming like some Godzilla of Not Done, no paradigm of agility.

We were able to add User Stories as other issues cropped up, and we did in the end discover that some User Stories were irrelevant or completely incapable of being completed with the systems we were working with: these were ultimately tagged with “Won’t Do” rather than Done.

But that initial setting of User Stories set our path in just as rigid a manner as the traditional “Waterfall” method, and I even began to think that the Waterfall has some benefits like repetition of tasks and documentation for each milestone, ensuring that they mature with the project, rather than being looked at once, documented and dumped.

What did I learn?

This is a key question for any initiative and is built in to the Agile method in the guise of the Retrospective.

…. another beginning

At work I - with the team, of course, it couldn’t be any other way - recently completed my third ever sprint review, took part in its corresponding retrospective (the cool kids say just “retro”), and planned for the fourth sprint, by reviewing and prioritising the backlog.

To put that into context, I am now - finally! (I can no longer write “Finally” without thinking of Vaughan William’s A Sea Symphony) - involved in my very first “agile” project, and I’m at least getting used to the jargon. But, is it as good and as efficient and energising as I imagined it to be, back when I was on the outside, jealously looking in?

From the confines of automotive industry projects and the traditional task-and-milestone mills that were our project styles, I would hear and read of some distant enlightened lands of agile project management: from where I stood, agile appeared desirable, enjoyable, more efficient, “better”: today I wonder if this is really the case.

As with any , including training that included the agile manifesto, descriptions of sprints, retrospectives, workshops and all of those good things - or at least a variant (the purists would no doubt say ‘deviant’) of it - at work, and I have some issues with it.

I’m also somewhat distracted by the vocabulary, especially the notion of the word “backlog."

Before starting the project, the word backlog felt wrong to me: it implies work that behind its planned completion date and is building up through some form of bottleneck, whether this be . Before kick-off, backlog is prolog(ue)

This Guardian opinion piece on the British NHS, or, more generally, this search: (NHS backlog site:theguardian.com) for articles containing the words “backlog” and “NHS” in the Guardian, or this article referring to the backlog of asylum applications in the UK really give a sense of what I mean

Now that we’re a sprint in, and we see what we had collected as “to-do’s” and did and didn’t complete in that first sprint, we see the collection of unedited “User Stories” that really does act as a mass to be reduced. A backlog, perhaps, but also a mountain of ice cream needing to be eaten spoonful by planned spoonful

User Stories are not tasks

Project Management is a technology, a process, a human-made artefact, which also enforces a lot of documentation (that most people in the world won’t read)

Engineering engineering

created 2023-10-14

really for my Literally Engineering engineering blog

I tumbled literally not engineering into the New Year 2023.

Now working again, a confirmed escapee from the automotive industry, I find myself contentedly and, by my own reckoning, at least, gainfully installed in the engineering community of a medium sized company making sensors for industrial applications.

I also find myself wondering whether I might still actually be literally not engineering.
Information wrangler

My new working environment, beyond the desk, the chair and the coffee machine, is digital. I no longer handle parts or discuss testing in the lab. Instead, I deal almost exclusively with data and information: electronic representations of real, or potentially real, things (sensors that other companies buy), and with “non-things” like methods, guidelines, specifications and communications.

Through this last point, clearly I do deal a great deal with the very real, the occasionally thoroughly perplexing and frequently enriching interactions with my colleagues and other humans in all their complexity.

In this combination, my role combines both forms of knowhdge characterised by Aristotle that I’ve been focussing on, techne and phronesis, which refer to making (in the original sense of the crafts) and practical politics respectively.

Aside from the physical handling of parts both new and old in my previous job, is this any different?

In one respect, no, it’s not very different: the technical drawings that I used to produce, or, better, have produced for me) are informational representations and intentions of something that should ultimately end up being made, manufactured, turned real. But my current position puts me at at least one remove further from our final product. I help to ensure that our data and (data + meaning + truth or accuracy = ) information ends up in the right form and location, with sufficient accessibility and searchability that it is useful to those colleagues of mine who do work on products that will ultimately be manufactured, sold and put to constructive use in industry and society.

Gotta role with it

My position currently consists of three main roles: representing mechanical engineering in our company’s new PLM initiative, updating and managing our design guidelines, and, closely linked to those, managing our CAD systems, methods, and - surpise! - data (servers, databases, etc).

This new working world of mine has an expanded ontology compared to the previous one, in that I now also have dealings with two additional domains, electronics and software. These, too, work mainly informationally (electronics schematics creating the general logic, plus the software and firmware that tame the chips).

These domains can be seen as models for my own new sense of engineering, if engineering is what it is that I do. They construct “devices” that work according to particular rules and logic, to meet certain goals, within a largely technical domain.

They make use of tools and consider ways of testing their output against predetermined requirements and - that word again - constraints (price, availability, approvals, maturity, etc).

In total, this set of roles raises the question for me: what of that is engineering?

Intriguing devices

If electronics and software can be considered as “devices”, then so could the objects and elements that I work on: the outputs of my work are not physical but logical devices of varying complexity, that need tweaking, tuning and, occasionally an overhaul or complete replacement.

To be able to do any of that, I need to understand their mechanisms, weak points, inconsistencies and failures - just like in any engineering context.

I can consider as actually being secondary to their actuality in the engineering environment as actually being secondary to their actuality in the engineering environment.
Infra-engineering

Like infrared or infrastructure, infra-engineering is my imagined term for the work done “below” engineering, to support it. Foundational engineering , we could call it.

What of what I do is engineering? This is where my uncertainty regarding the definition of engineering itself requires that I attempt to break things down into sensible components to see if, during reassembly, any parts or subassemblies look like engineering as I understand or have experienced it.
A more philosophical stance

One attraction of where I now stand in the engineering landscape is that I can view the whole more philosophically than before. I can use the term “ontology” in both the technical, “PLM” sense of listing out the parts that we have, and in the more philosophical sense of “what are we dealing with here, exactly?” This would include discussion of our beliefs in PLM entries representing physical products, those entries including thumbnail images of CAD models of those components ; or, indeed, considering CAD assemblies as mere containers for the components, plus positional relationships.

It can all get me back to the very beginnings of this blog, considering the writings of Gilbert Simondon , and his considerations of concrete and abstract parts.

Outputs

Perhaps the clearest way of investigating the essence of my work is to ask what I will be “producing.” For a “true” engineer, the product would be clear: designs and specifications according to which items could be made and sold to a market.

Rather than items that can be sold onto a market, I am helping to design the environments in which our engineers work. My customers are my own colleagues, the engineers - and they can be demanding! In addition to designing that environment, I’ll also be documenting it and specifying how these colleagues will work: I have to define both the path and the handrails / safety railings for it.

That sounds very bureaucratic, I’ll admit. But here, too, is a question: are bureaucracies engineered?

Outputs

• A realistic, understandable and internally marketable (acceptable) system and structure for storing and linking engineering data with other and with non- engineeing data.
• Workflows
• Administrative constraints and guardrails
• Specifications
• An organised knowledge base
• Installed, tested and approved software
• Tested and approved methods for working with that software

so, whilst I no longer deal with labs, I certainly deal with testing: I write (or at least imagine) test scripts, and I record the results in text, screen shots and screen captures.

A digital Dewey

The obverse of outputs is of course the inputs that I need to consider. Now, since I’m not personally generating much of the data, but figuring out how best to organise and present it, like a digital Dewey for libraries, my inputs are the platform that we must tune to our needs, representative data for testing, and in Agile project management speak, User Stories and challenges, known issues and ways of working, that need to be selectively reimplemented or optimised, or bypassed, with the new systems.

There’s a train of thought that the administrations, procedures, methods and laws of modern society are themselves forms of technology. And technologies are engineered.

Here, I am still defining and specifying how our CAD engineers will work, including fruitfully constraining choices in terms of things like material selection, design for injection moulding and the like. These outputs will be the design guidelines and standards to which our engineers should or must adhere.

On the PLM front, I’m helping to define the form of engineering data and collaboration on that data within the confines of a pre-existing PLM structure.

Tools and methods

• Graphing and flow charts, procedures and guidelines
• Ways of thinking and interpretation

Thinking as an engineer who does rather like to minimise bureaucratic effort. Lifecycle and maturity states. Drawings and metadata. Relations, links and causality.
Knowing what we need to prove, our affordances

Handling our CAD data, our releases, reports - and the network of components, assemblies that ultimately lead to products being sold on the market.

Action and agency

In this role I do quite a lot. Testing to understand the limits and constraints of our systems.
How else would I describe it?

If what I do at work is not engineering, then what is it? Luciano Floridi refers to philosophy as conceptual design… So, could what I am doing at work, as well as here, in this post, be referred to as philosophy?

Or a chemistry of engineering: picking the atoms of information and turning them into valuable molecules, rigid crystals or flexible polymers of information that undergird the products that we make.

Perhaps I’m operating as a lawyer of technical information, determing what’s “right” in engineeringly “legal” ways.

The classic analogy for this sort of work is to the architect: someone who, combining innate, but trained, aesthetics with technical understanding and realism, creates - in combination with a vast range of experts - a new structure that can be used by many people over time.
Design engineer

I am a designer of engineering methods. The basic software elements are already present, the systems made available by companies larger than our own. But we need to select the

… and I didn’t get further than that (yet)

Jeptha (a Handel oratorio)

created 2023-10-31

Last Saturday, on the 28th October, I sang in my second Bachchor concert in the Peterskirche Heidelberg. Once more in English, though notably less heavy than Vaughan Williams’s A Sea Symphony, this time we were singing Handel’s final oratorio, Jeptha.

Wikipedia, with its patience of multitudes, has a much more informative summary on Jeptha than I could presume to write, so I won’t go into the details here.

We had an excellent young lineup of soloists, including an emerging talent in the English tenor Gwilym Bowen , who sang the title role.

I did end up wondering about the political implications of the message contained in the story of Israel’s victory.

Employment (and) agency

created 2023-12-04

This time last year, in December 2022, I was coming to the end of my employment at Cooper Standard. The company was doing what alert companies do, reconfiguring the business to focus on growth areas, and my expertise in threaded fasteners and coatings was no longer considered to be of sufficient value to retain in an increasingly plastics world. Some discussions on timing and payout later, I was to leave at the end of the year.

It’s interesting to look back on that time of wrapping up: calling key contacts to let them know that I’d be moving on, reminiscing on fun and challenging times, wondering what gardening leave would be like; and, of course, digging out the CV to give it a good old refresh, and starting to wonder what I wanted to do next.

Even with the buffer of gardening leave, hope and expectation were tinged by uncertainty. What sort of industry would I end up working in, and would I be able to hold to certain standards (no military, no fossil fuels, for example) indefinitely? How big a commute would I accept, having been able to cycle to work for all those years? Uprooting the family wasn’t really a consideration, but the idea did lodge itself at the back of my mind, along with that other associated mental paraphernalia of leaving a position without having a new one already lined up - including starting the unemployment process in time, in - gasp! - Germany*.

That combination of hope mixed with unease at the directionlessness I was faced with (my pending gardening leave may have felt enticing, but it still led nowhere), held a certain diffuse meaning that it’s worth reflecting on now.

The value of work is grounded by predictability and security. If these are lacking, as they are in so many areas like the arts, or catering, or fixed-term contracts, and for those brave enough to set out as consultants, then you’re permanently on shifting ground, seeking balance, always having to stay alert for new opportunities and less able to switch off, to reflect and - in the extreme case - to appreciate the good things in life.

Fundamentally, it’s about having agency, being able to decide your own path, in your own time, on your own terms, resulting in Action - taking Hannah Arendt’s interpretation of the word - in which a person has the opportunity to show who (rather than “what”) they are.** Merely enacting (carrying out) jobs doesn’t suffice for action in this sense, which is why so many jobs can be unsatisfying, even when they are settled on a baseline of security.

Now, writing this in the luxury of a secure position, in which both I and the role(s) I have at Pepperl+Fuchs are developing, and with the buffer of time behind me, I can admit that the timing of my leaving Cooper Standard was right for both parties - sometimes inertia sets in and we don’t quite reach the threshold for action, requiring an external impetus to get us going again.

How should I summarise this post, then? What’s its moral? Just to make us aware again of who we are in the working world, to be appreciative of security, to be wary of dulling ourselves, and aware of all the other factors that play a role in our decisions, especially, of course, the people and society we live in.

* The Arbeitsamt turned out to be an excellent institution, proactive and leaving me to my own thing in the right degrees, and remarkably uncomplicated, once I got the hang of their website!

** This perspective taken from one of my favourite philosophical books, Back to the Rough Ground, by Joseph Dunne, chiefly about forms of technical and practical/political knowledge.