Putting together a new standard

The topic I jettisoned from my talk about MPE at last week’s conference was my thoughts about what makes a good Working Group, as I didn’t want to imply any criticism of the MIDI Manufacturers Association or its members.

As Chair of the MPE Working Group, I neither presume that I can pilot harder projects through technical and diplomatic adversity, nor will I tempt fate by attributing much talent to what might just be beginner’s luck. All I know is that, over the years, I have seen a couple of things.

Some time in the past, I sounded off about what is wrong with MIDI, and every now and then I still do, but always with a veneration for a standard that has managed to age so gracefully while seeing off so many rivals.

The HD Working Group has been meeting at least weekly for more than a decade now to define a successor to MIDI, and we’ve all been waiting, reading, and preparing. It’s not been an easy journey, and HD has recently stumbled at one of the last hurdles. The MIDI Manufacturers Association functions as a democracy of individual companies, and getting a new idea ratified means convincing important stakeholders that they will benefit from your changes and not be threatened by them.

This has always worked for small changes. But a wholesale replacement for MIDI must be non-disruptive, and a non-disruptive replacement is a paradox. After ten years of development, the HD spec is more complex and intimidating than MIDI, there’s no straightforward compatibility between the two, and it’s too new even to be clear how it’ll be used. MIDI has survived nearly 35 years being meddled with and patched up — MPE is just the latest way of doing this.

The HD spec would fix a lot of our problems automatically and for good, but it’s in a tricky place. Every passing year, the tweaks to the old spec gain some ground on the new, and the case for the new diminishes.

Either in its current or a modified form, I want HD to thrive. It seems that there are a few options open to the Working Group to keep it alive, all of which might work, in varying shades of palatability. Some of these are happening, and some aren’t:

  • Keep working on the market model, convincing the company representatives who intend to vote ‘no’ that it’s in their interests to vote ‘yes’.
  • Allow companies to start commercialising the draft specification without permission, on the basis that the first few compatible products will create a small ecosystem, prove a market for HD devices, and establish a commercial case without frightening incumbents.
  • Encourage software framework developers to add implementations of HD to make it easier for third parties to assimilate.
  • Approach a different standards body, such as the USB Implementers Forum or the ISO, to ratify the specification as a standard that is independent of MIDI, and bring it back to the MMA as a fait accompli. This might be less hard, but risks destroying the MMA by driving it into irrelevance (or making it look like this is the intention). Doing so could alienate much of the industry.
  • Go back to the drawing board, and work out a roadmap where MIDI 1.0 can be turned into MIDI 2.0 by backwards-compatible steps, each of which will require a little work in exchange for some exploitable advantages. For example, MIDI 1.1 could mandate full-speed USB, assume bidirectionality by default, revise its note model to support MPE, respond to the System Exclusive Device Inquiry message, and abandon Polyphonic Aftertouch (the messages for which might then be reappropriated at some point in the future). All of these have clear commercial value, ease communication with computers, and pave the way for a ten-year plan of improvement. The new spec gets chucked away, but not the underlying vision, which is actually the important part. Who, after all, knows what the market will need by the time MIDI 2.0 sees the light of day?

The last one would, of course, be terrible. HD isn’t at this stage and I hope it doesn’t reach it. For what it’s worth, though, here is my conclusion from what little I’ve seen of Working Groups.

Creating a new specification is just like software design …

  1. Have a short attention span, because you never know which way the industry will turn tomorrow.
  2. Surgically fulfil specific, identifiable needs.
  3. Always have an up-to-date implementation so that the spec makes sense.
  4. Engineers have enough to learn. Resist the temptation to change established practices. Even if it hurts a bit, make the old spec fit new requirements.
  5. Put something out within a year, or two things will happen: the world will forget you, and the sunk cost fallacy will sink its teeth in. In other words, hardly anyone will volunteer to junk more than a year’s work even when it’s the right thing to do.
  6. Capture neat ideas in a roadmap, and leave space to put them in, but promise as little as possible. Non-essential features should be marshalled into a to-do list for a future spec. They may never be needed in practice, so don’t burden early adopters with them.

… Except for the bits that aren’t.

  1. Keep the door open. Never work in secret or limit discussion. These days, being courteous and responsive to keyboard warriors is part of your marketing campaign. However —
  2. Don’t let your guests take over. Good specifications need clear ownership, so limit scope and limit control.
  3. In this industry, don’t sell your spec for money, as it will need all the help it can get. People have grown very accustomed to getting stuff for free.
  4. Make it really easy. Great documentation isn’t enough these days: people expect TED talks, code libraries, unit tests, and preferably source code for a working demo.
  5. Persistent and contrary people will drive you crazy along the way. It may not look like it, but many of the people that work you the hardest will turn out to be your greatest friends and advocates. Like you, they want this specification to meet their needs and succeed in the wider world, which is why they push back so hard. Do all you can to understand them, be unfailingly polite and positive, and go out of your way to accommodate them if that’s what it takes to keep them on-side.

Book Depository: The Five Dysfunctions of a Team by Patrick Lencioni

The first part of this book concerns an experienced CEO called Kathryn, who is brought in to fix a software company. Agonisingly, she turns around its dysfunctional leadership team, its decision-making, and its results. The second part unceremoniously picks apart the desiccated carcass of the tale, adding worksheets and teaching material.

Pyramids as diagrammatic aids are troublesome at the best of times, as it’s never clear from a glance what the illustrator wants to say about the hierarchy of information. Do we head from base to summit, as one might climb a real pyramid, or is our eye supposed to scan it from apex to base as a page of text, the tiny top broadening to weightier things? How do the middle tiers interrelate? The Five Dysfunctions themselves are depicted as a pyramid. Thus the only graphical aid in the book requires the whole text to explain it.

Never mind. The core message is that great teams argue, all the time. They argue to determine a company’s goals; they argue to decide how money and time is spent; ideally, they argue without ego. Teams that hold meetings without conflict hold meetings without consequence, where nothing is decided, and people zone out, dumbly acquiesce, or cower in fear. Lencioni says that the most fundamental dysfunction is an absence of trust. Everybody has a different perspective of what’s important and why, so meetings should be dramatic: full of tension, disagreement, fresh perspectives, and negotiation.

This being a bottom-up pyramid, trust is drawn at the base. This is the first step in fixing a team: it is on trust that everything else rests. Every member of the team has to trust the others. To invite disagreement, they must allow themselves to be vulnerable to criticism and counter-argument without their openness being abused by personal attacks or political plays, and this requires good facilitation. The antithesis of trust is invulnerability: if you don’t argue, you won’t ever lose, but you’ll have to sit through a lot of lousy meetings.

Absence of trust / Invulnerability

Without complete trust, there cannot be authentic, game-free argument. The next stage of the pyramid concerns unfiltered conflict. In a supportive and respectful environment, ideas are primal, truth wins, and it doesn’t matter who has volunteered a suggestion, only how appropriate and useful it is. Conversely, in places where a person can be shouted down for dissent without a real counter-argument, there will be people who feel they are being neutralised for political reasons. They will not buy into the eventual decision, and may decide to strike out alone.

Fear of conflict / Artificial harmony

The result of hours of conflict and resolution is a plan that the whole team can commit to. If there isn’t universal agreement, some people will not contribute sufficiently to the plan, so the overall mission of the company will not be coherent or complete. Argument airs the rationale behind a decision, which allows people to understand and commit.

Lack of commitment / Ambiguity

Commitment to a plan then leads to responsibility to deliver it. This means maintaining high standards throughout the team, and leads to other necessary conflicts: holding team members to account if they miss targets, ignore work, or get distracted by other goals.

Avoidance of accountability / Low standards

People may be members of many teams, while also attending to their personal ambitions. One team always comes first. If you’re on the leadership team, that’s your first team. Maintaining trust and confidentiality in your first team is paramount because it’s how a company succeeds. It’s important that you work towards the collective goal, that conflict will be handled with discretion, and that the team can call you out if you don’t perform.

While it’s easier to let people pursue individual, ego-led projects than holding them to account when they fail to deliver collective goals, it’s the wrong thing to do. You accept such attitudes at your peril.

Inattention to results / Status and ego

These problems are simple to state but, as we see in other books, it’s not always possible to dismantle political structures that preserve internal truces. Sometimes teams cannot be made to work like this without replacing parts of them, or forcing them to change in the face of an external crisis.

Book Depository: Black Box Thinking by Matthew Syed

I didn’t find this book at ROLI, but Matthew Syed’s everywhere these days and this one looked like it might be worth a glance.

Matthew Syed is a tall man with no hair. His book is full of this kind of observation that never goes anywhere: the muscular build of a bereaved man; the hairstyle of a pilot who committed suicide. Here we are, forensically deconstructing the aftermath of a medical accident; suddenly, Syed jerks our gaze to meet a widower’s eyes, welling as his tapering fingers tremble.

This gives the reader two problems. First, the central message of this book seems claustrophobic and insincere because we are constantly distracted from the primary narrative. Second, these soft-focus vignettes sit poorly with the tragic flavour of much of its material. Sometimes they feel voyeuristic. At other times, when you feel Syed is building up to a killer punch, he pulls it to patronise his subject. This surgeon’s tyranny in an operating theatre nearly killed somebody. His obstruction of a subsequent investigation nearly leads to more deaths. But remember, he’s a hero. They’re all heroes. Atul Gawande trod this ground years before Syed, and did it authentically, as a driver rather an a back-seat passenger.

Syed’s book, then, is a poor recruiter for a great employer. At its core is a simple, powerful and universal message about the power of scientific inquiry. Here again, though, some flaws are unforgivable. Central to a writer’s integrity is a clear and honest use of words. You can’t tell your readers that science is what they need in their lives and then, in the next sentence, cut off its limbs to fit your bed.

Syed refers to ‘open-loop’ and ‘closed-loop’ thinking in a way that, for no good reason, inverts the established meaning of these terms. Hence, a ‘closed-loop’ system which, to the millions of us with technical training, is something that is ‘closed’ by a path that provides corrective feedback, is now ‘closed’ in the sense of ‘guarded against feedback and the influence of evidence’. Did anybody edit this book?

Lesson one: collect data about everything you’re doing. The title ‘Black Box Thinking’ refers to the two data recorders that capture the cockpit voice and telemetry in aircraft, so that crashes and near-misses can be better understood. Dispassionate forensic analysis of this data provides vital information about what went wrong. If you don’t have data, you’re reliant on lucky guesses to prevent disaster.

Lesson two: depersonalise this information, and don’t use it to shame people. The fear of shame leads to the deliberate concealment of errors, so everybody loses opportunities to learn. Humans are fallible under stress, and the first duty of a crash investigator is to improve flight safety. Before critical failures, there are near-misses, and people must be allowed to report and challenge these without fear. The exemplary attitude in aviation allows mechanical problems to be caught at an early stage. Best practice is also improved in the cockpit. In-flight checklists control the narrowing of a pilot’s concentration under stress; improved human factors fix problems with the flying controls; Crew Resource Management addresses the psychological difficulties of cockpit hierarchy. This is why, as we know, civil aviation becomes safer even as aircraft become more complicated.

Lesson three: learn by building, make marginal gains, iterate often, create theories and try to falsify them. Syed summarises with unusual concision, ‘If I want to be a great musician, I must first play a lot of bad music. If I want to become a great tennis player, I must first lose lots of tennis games. If I want to become a top commercial architect known for energy-efficient, minimalist designs, I must first design inefficient, clunky buildings.’ Nobody gets great without a lot of practice. If you’re a product company, solicit feedback from customers at a really early stage, while you’re a bit embarrassed by your offering: you’ll learn if you’re doing a really great job designing the wrong thing.

On the subject of iteration, there is another use of the term ‘Black Box’ that is more commonly employed by engineers. A Black Box model is one in which a system is characterised merely by measuring and relating its inputs to its outputs, without attempting to understand the internal process that connect them. This might have been woven into the central chapters on evolution and marginal gains. Here, in many places, it would have bolstered the book, but it doesn’t. The dual meaning is dismissed in a footnote on Page 33 and never mentioned again.

In a central chapter, Syed notes that Unilever employed physicists and biologists to approach a difficult optimisation problem from two directions. Detergent granules are produced by firing a hot, pressurised liquid through a nozzle into air, where it rapidly solidifies and lands as a powder. The power has to have the right grain size and consistency, and be adequately mixed, so the nozzle design is critical.

First, as Syed narrates it, physicists tried to characterise how the nozzle worked by modelling the flow of fluid through it. Their failure to build a decent nozzle highlighted the intractability of the problem. A team of biologists then successfully optimised the nozzle with a typical ‘black box’ approach: starting with an existing, poorly-functioning prototype; measuring the powder it produced, tweaking its design, and favouring the best-performing candidates over dozens of generations; finishing when it was as good as it seemed it was going to get. Hundreds of prototypes later, the ‘black box’ approach produced a great nozzle.

Syed narrates this as a victory for the empirical, evolutionary approach. Dyson, who created thousands of prototype vacuum cleaners in order to arrive at the DC01, is press-ganged into Syed’s war. Take that, theorists!

Unilever nozzle

Had Syed been a scientist — had he taken his own advice — he would have seen this story as more than a battle between schools of philosophy. Both teams’ methods are in alignment with best practice: each collected data, analysed it dispassionately, and thus approached the truth. One school attempted to find a theory to solve the general case, realised that their best guesses were false, and conceded defeat. The other school set out to attack a specific case — a smaller problem — and succeeded. My conclusions would be:

  1. Failure informed the approach that led to success, as it often does. Failure’s a great teacher, but a slow and expensive one.
  2. Reducing the scope of the problem allowed a different tool to be used, which succeeded. The price of success was the abandonment of a general understanding of the problem.

Unilever have a brilliant nozzle, and the method that produced it, but they’ll never know why, or whether there’s one they missed that produces three times as much powder. Every time they want to increase flow through the nozzle or reformulate their detergent, they’ll have to make a hundred more prototypes.

Lesson four: understand and eliminate cognitive dissonance. Resist the temptation to spin failure as a success, or deny that something went wrong. Accept such failures as an opportunity to learn and improve.

If you’re involved in a technical discipline, you’re already a servant of hard physical truths. No amount of post-event rationalisation will excuse a prototype that is not fit for sale. (Although, if you’re building Mars landers for the European Space Agency, it seems you can crash-land at every attempt, act as though you succeeded, and continue to get funding, but I’m talking about real jobs.)

An external perspective of scientific method may help a wider audience to discover it. There are certainly pickings in this book for technical readers, but it’s principally for an audience who don’t get, or even seek, the same class of feedback from their work that the technologist must. Recommend it to your boss. Next time you have a corridor conversation, though, remember that ‘closed-loop’ is open-loop, ‘open-loop’ is closed-loop, and ‘black-box’ means collecting and responding to data. Or ‘science’.