← Home About Archive Photos Replies The Point Engineering Sea and Shore Also on Micro.blog
  • Here Be... Stuff

    Stuff. Is that the best word I could come up with to start my philosophically tinged blog on the nature of engineering? Well, at present, it is. It’s the best. Up to now, I’ve been reading more than I have been writing, and in all honesty, “stuff” seems, as a word to use, more human, more engaging, simply more meaningful, than plenty of other words that I have encountered in my early reading into the philosophy of engineering.

    Who’s talking about whom?

    One fascinating subject that I have encountered, and one I am sure I’ll come back to quite often, is whether it is more valid for professional philosophers to philosophise about engineering than it is for professional engineers to “try” and philosophise about their own metier (which is, naturally, what I’m up to here). At present, in my current, extremely limited state of philosophical fluency, the vocabulary that philosophers use looks to me to be as technical, as opaque, as anything that I’ve encountered in engineering. It’s as if philosophers are talking to themselves about us: we’re the specimens in the lab and they are the all-knowing experts looking in and occasionally prodding. Looking back through the bars at what they have produced in writing (do philosophers have any other form of output?), I have the impression that if philosophers love one thing, it’s the exquisite agony of defining words exquisitely.

    Those “omniscient experts” just seem to be talking to themselves. Therein lies the appeal of the word “stuff” to me right now: it’s maybe an overly familiar word, but it has the charm of being familiar, and carrying with it a rather vague set of meanings, so I’m not totally nailing somthing down too soon. I could equally assign a letter to represent the thing I’m referring to: F (we tend not to use S because of 5). Or, even better, something Greek: [\theta].

    Back to the Stuff at hand

    What I’m referring to with the word “Stuff” - or F - is the things that humanity makes. This means that F is a subset of “things”. Nature makes plenty of things without our intervention - but nature doesn’t make “stuff.” We do that, all by ourselves.

    We don’t tend to give “Stuff” all that much thought, unless we’re going to be buying more of it and want to make a choice. An awful lot of Stuff is just there (indeed, an awful lot of Stuff is junk, or “tat” - but that’s something we’ll have to think about more deeply another time). Yet all of this stuff has been designed, developed (in various ways), made, and, increasingly, engineered. With all our concerns about energy consumption, efficiency and emissions these days, engineers have ethical questions to answer, along with the industries we serve: is cattle farming - or, more precisely, its outputs like cheese or beef, for example - “Stuff”, and can it be better engineered? But generally, most Stuff ends up as background noise to most people, like the fridge in the kitchen that you only notice when the compressor switches off.

    It has become normal for us, even as engineers, to work on F or to use it without pausing to ponder the “what does it mean” of our endeavours. Others have done this in the past, and continue to do so now. These others are professionals, too: their job is thinking. That leads to another train of thought that stems from business: is a philosopher’s work an opportunity cost? Could they have been better put to use doing something other than “just” thinking, writing and publishing?

    That’s something I’d also like to consider over the course of this blog.

    The Languaging of Experience

    I may have appeared to be a little scathing about philosophers’ use of words, but I also need to take care with my choice of words, and how they are packed into the text that I’m hoping to use to transmit my thoughts or experiences to you. So, I will be as careful as I can be - and gladly accept any criticism of vagueness or confusion generated through my choices. If I were to be grammatically correct about it, the title of this post should be “Here is Stuff”, taking “Stuff” as a singular word denoting the plural - but because “Here Be…” just sounds better, more piratey, than “Here Is”, that’s how I’ll take it for now. Arr.

    What am I doing, again?

    I’ll do lots of reading. I’ll list out the reading I’ve done, and estimate how much I have understood what I read. I’ll write posts on thoughts that arise from that reading, as well as from my own engineering experiences under this new perspective; posts on various topics and concepts that I stumble across during these hobbyish endeavours. Perhaps something will form out of it: an idea, a concept that might help me, possibly even a reader, to understand a little more the “why” of what we, as engineers, do.

    This is all at the risk that it might all have been my very own opportunity cost, too; I should have been practicing the trombone instead.

    Sorry.

    (especially to the design and process engineers who designed, developed and made my particular trombone, to the engineers who designed and validated the materials in roads and ships, to the developers of the logistics systems, of the barcode readers and truck tyres that, together, managed to get my trombone to me. To the printers of music, the extruders of aluminium music stand components - and to the makers of earplugs.)

    → 5:48 PM, Oct 27
  • The Brexit FMEA


    The Brexit pre-mortem: BFMEA


    Of all the engineering tools that I have encountered, the one that spans the widest spectrum of respect and scorn, hope and despair is the FMEA, the Failure Mode and Effects Analysis.


    Developed by the US military and NASA and gradually adopted by the automotive industry from the 1970s onwards, it is intended to highlight things that could go wrong before they do; it's also a way of collecting and tracking the evidence (models, test reports, etc) that shows that the nuts and bolts have been proven before putting them on a rocket - or, indeed, jettisoning a country out of the European Union.


    At its heart, the FMEA is a "what if?" analysis. Other methods are available, like the Potential Problem Analysis from Kepner-Tregoe. But I'm automotive, and the FMEA is a requirement in our field, so I've sketched up how a BFMEA (Brexit Failure Mode and Effects Analysis) might have been constructed and eventually look like. Why? Because I simply don't get the impression that the British government perceived the need for any such thinking before diving in to the apparently urgent political necessity that was the Brexit referendum result. And also, because sketching one up isn't all that hard - with practice.

    Building the structure


    First of all, you need to define what your product or system is, perhaps by following what was defined in the project scope (ABQP). The FMEA might be for a full system, or it might be for an individual component that fits into that system: For our purposes now, it's Brexit. Brexit has a few functions and requirements that I cobbled together in five minutes (naturally with no little help from hindsight):

    What could possibly go wrong (failures)?


    With an FMEA, you focus on failures first and foremost (it can be a depressing trudge, initially, which is why engineers are always so miserable. Are we? We must be). Put yourself in Law-maker Murphy's shoes, maybe even his socks and underwear, too. The fresh ones.






    Then "all" you need to do is to go through each of your functions, wishes, desires, needs, etc: and define all the ways they can fail (one more example here):


    How could it come to this (causes)?


    If failures are the symptoms, then causes are the bugs that deserve our attention. 

    Again, with every failure having its very own potential cause, or causes, we need to repeat the trudge around the houses. I've kept it relatively simple here:

    Somebody will have to do something about this (actions)!


    The whole point of the FMEA is to discover potential failures and to cut them off at the source: we don't want those bugs getting in that resulted in us hollering into the toilet bowl. So the positive aspect of the FMEA is assigning to-dos to each cause, like "make sure you wash your hands before eating", with the intention of preventing those causes from occurring in the first place (absent a time machine):


    So much to do! Where to start (Effects)?


    There's one letter we haven't touched in the FMEA yet: the E. Effects. Determining what happens as a result of the failures can be useful in figuring out what actions should be prioritised. You might for example preferentially allocate work on avoiding failures that would otherwise result in conflict on the Irish border over events that would lead to slightly less curved cucumbers still landing on British shores.


    But understanding where to prioritise political effects (disgruntlement amongst 48% of voters, for example) is beyond my realm of experience, and represents a clear disconnect between the "plodding reality" of engineering and the human rationality (in all its technical irrationality) that defines politics. Some things might not be "prioritisable" at all. At least until someone works out an official Happiness scale that would be able to balance lots of low-level general contentment (hey, being in the EU isn't actually all that bad most of the time) against intense doses of uproar (they're defining cucumbers again!). Do I digress? I believe I do.

    Presenting the BFMEA


    Typically, FMEAs aren't presented in the network style that I employed to build mine: the traditional method is the worksheet, which typically leads teams to try and build them in Excel or similar. This is what mine would look like in that format.



    It's OK, but a bit sterile. Which is I suppose how it should be. Right? "Real" FMEAs have ratings numbers that help in the prioritisation of tasks, which I have omitted here.

    Build and forget?


    The FMEA is intended to be a so-called "living document". As new events occur and lessons are (ha!) learned; as new and fantastical failure modes with subtle, complex, causes are discovered, the FMEA grows: often becoming unmanageable, or at least rather unwelcoming in the process. Unless someone or some team is really "living" complex FMEAs as a role, they will bulk up, dry out and fossilise.


    In one sense, that's not necessarily a bad thing: if at least in the act of setting it up important considerations were made in that emotionless setting, potentially resulting in actions being taken that avoided some grand faux pas or other, then it will have been useful without too much investment in resources.

    Do they? Can they?


    It would be fascinating to find out what methods the British Government has at its disposal (and which were used thus far): because, to all appearances, they weren't.


    Perhaps they're saving them for the debates surrounding the re-entry into Europe, then.

    BFMEA network and other points


    Here's the network FMEA that I built up over the weekend. To those engineers reading this who are experienced in FMEA methods: I acknowledge the existence of Occurrence and Detection items. I didn't bother with ratings, as FMEAs can really get bogged down with them - but some sort of prioritisation is required, of course. To those outside of my industry: have you encountered similar "constricted thinking" methods? It would be fascinating to hear from you!



    → 8:28 PM, Mar 20
  • ABQP: Brexit as an automotive project


    ABQP: Advanced Brexit Quality Planning


    It is surely doing the British Civil Service an injustice to suggest that there was no planning process for Brexit. However, what we see in the media strongly suggests that whatever planning did take place was swiftly overcome by politics: the votes upon votes in Parliament, the pontificating and hardening of views, the dreams shattered and still dearly held. We hear of Papers stating one potential outcome or another, but the feeling remains of a Brexit ship veering ponderously from port to port, turning away from each in disgust without ever reaching one.


    I'm an automotive engineer, and could imagine Brexit being an automotive project; there would (in my imaginings, anyway) have been a clear baseline for planning, thinking, moulding, approving or even cancelling the project before it's too late.


    Comparing Brexit with a VW Polo facelift? Ridiculous! Well, yes, but I feel there are some lessons in the processes that we use in industry that might have been better learned before embarking on this huge undertaking. (Otherwise I won't have writting this, I suppose).


    Naturally, the advantage that the auto industry has over the Brexit project is that it can produce many models and, with experience, assuming the company survives (which many didn't ), see what sticks. Brexit is a one-shot action that will take decades to mould after the event. But, anyway, here are my thoughts on the Brexit Project from an automotive perspective:

    APQP: Advanced Project Quality Planning


    Every automotive company has its own flavour of APQP, but the basics are defined and even - of course - available on Wikipedia. Some key aspects that I would highlight here would be:

    • Planning and Defining the Program
    • Product Design and Validation
    • Understanding the needs of the customer
    • Analysing (/predicting) and mitigating failure

    It's a plodding, check-box laden process and certainly not in the vogueish agile development process domain - but therein lies its strength as well as tedious weakness: it enforces slow, measured and team-based thinking, rather than snap decision-making.


    Irrespective of whether I think Brexit is a good idea or not, the process appears to have been entrained without even a basic level of planning. Was there any sensible product definition of Brexit before kicking off Article 50 and the two-year negotiation period? (Leave Means Leave is not a helpful definition, at least in my book).

    Advanced Brexit Quality Planning: A light-gloom-hearted ABQP Statement Of Work


    Project Name


    The United Kingdom of Great Britain and Northern Ireland to exit the EU.

    Project Scope


    The United Kingdom of Great Britain and Northern Ireland intends to leave the EU. No other countries will leave the EU. All components of the UK shall leave the EU, including Gibraltar and the Channel Islands. The UK intends not to bow to EU regulations. This normally means not having the same level of access to the European market as available at present. The UK intends to keep the same level of access to the European market. Leaving the EU means developing new alignments with... well, every country in the world, as well as with the EU.

    Project Type


    APQP: Advanced Product Quality Planning with 5 Phases.

    1. Plan and Define Program
    2. Product Design and Development Verification
    3. Process Design and Development Verification
    4. Product and Process Validation and Production Feedback
    5. Launch, Assessment & Corrective Action

    Phase 1: Plan and Define Program


    1.1 Identify the needs of the customer


    1.1.1 Identify the customer


    The customer is all citizens of the UK (including those younger than 25 at the time of voting who, though disproportionately affected, voted at a significantly lower rate their older, perhaps more caring compatriots). Citizens of other EU countries in the UK will... have to lump it. British citizens resident in the EU will... have to lump whatever treatment they are given wherever they are living (they deserve it, the traitors) until such time as they return to the fold.

    1.1.2 The needs of said customer


    Right. Those needs. Yes. It is absolutely clear that all inhabitants of the UK want the best possible deal. In fact, they want more than the best possible deal, they want the best of everything, which is what was promised.


    Also: no more immigrants and no more being told how to run a country by a democratically-challenged council of flouncing Eurocrats.


    And: no European Superstate.

    1.2 Develop timing plan


    Target date: Open-end until Article 50 is invoked, so plenty of time to develop a statement of work, specifications and requirements, a strategy and tactics to achieve an acceptable level of that target.

    Article 50 has been invoked


    Wha...?

    Deadline is now May 2019.


    You're kidding... Umm, on what grounds was Article 50 invoked?

    None that anyone can discern; negotiations will be the easiest ever anyway. There was something about the EU not showing its hand until Article 50 had been invoked: unhelpful gamesmanship, a trap that the British Government, gleefully bellowing "freedom from!" fell into


    1.3 Develop Budget


    The EU will be on their knees in a few months. So no real budget is required, no contingency planning, just a few negotiators and the rest is a win for us!

    1.4 Assemble Team


    See 1.3 above, OK, plus their advisors. No need to listen to the people any more, they've had their vote. And we don't need experts any more, either. We'll ignore the Civil Service, too.

    Phase 2: Product Design and Development Verification


    2.1 Develop Product requirements


    The Brexit product requirement is... Leave! OK, more seriously, there might be some relevant functions of Brexit that we might want to consider:

    • Restore / Increase British national autonomy
    • Restore / Increase national togetherness
    • Significantly reduce immigration
    • Increase internal investment (e.g. NHS)
    • Retain and protect UK integrity (e.g. Northern Ireland)
    • Protect inter-Irish peace
    • Avoid becoming part of the EU Superstate

    Are these measurable? Most are. The intangibles (national togetherness) will need more definition as the programme progresses. Can they be modelled? What sort of Brexit would result in maximising the wins across the maximum number of functions?

    Predicting and mitigating failures (BFMEA)


    The FMEA (Failure Mode and Effects Analysis ) is a key engineering tool, initially developed by NASA with the intention of foreclosing failures before they occur.


    NASA was also a specialist in one-shot efforts.


    ... but that we'll save that for my next post.

    Phase 2 (Continued)


    Oh never mind: Phase 2,3,4 Finished!


    LAUNCH

    → 9:44 PM, Mar 17
  • RSS
  • JSON Feed
  • Micro.blog