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 certain from first 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 from apex to base, starting with the smallest stage to tackle ever larger ones? How important are the middle sections? How do the 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 the company’s goals; they argue to decide how money and time is spent; ideally, they argue without ego. Teams that hold meetings where no conflict happens hold very boring meetings, 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. Problems aired in company meetings matter to everybody, and everybody has a different perspective of what’s important and why, so meetings should be dramatic: full of tension, disagreement and discussion.

Trust is thus drawn at the base of the pyramid. This is the first place you visit when fixing a team, and the thing that must be right before anything else can be addressed. 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 ad-hominem attacks or disingenuous political manoeuvring, and this requires responsible facilitation. The antithesis of trust is invulnerability: if you don’t argue, you won’t ever lose.

Absence of trust / Invulnerability

Without complete trust, there cannot be honest conflict. 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 an adequate counter-argument, there will be people who feel they are being ignored for political reasons. They will not buy into the eventual decision.

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.

Lack of commitment / Ambiguity

Commitment to a plan then leads to responsibility to deliver that plan. This means maintaining high standards throughout the whole team, and yet more conflict: 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 of these teams must come first. If you’re on the leadership team, this your first team. Maintaining trust and confidentiality in this team is paramount because it’s how a company succeeds. It’s important that your team can expect you to work towards the collective goal, that conflict will be handled with discretion, and that the whole team can get on your case 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. Black Box Thinking luxuriates in glib journalistic dazzle. In one instant, we are forensically deconstructing the political aftermath of a medical accident; in the next, the writer’s attention alights on a widower’s eyes, welling as his tapering fingers tremble. This is modern self-help in Dale Carnegie’s image: recounted with a ferocious zeal that that feels claustrophobic and contrived, and presented with a chattiness that sits poorly with the importance and tragic flavour of its material. It occasionally verges on voyeurism but, where a sting of criticism might hit home, it is immediately emolliated by condescension. After reading of a surgeon whose tyranny nearly killed somebody, we are reminded not to forget that even a doctor who, in an instant of hubristic idiocy, almost kills a patient, and then obstructs attempts to investigate procedural errors, is nevertheless a hero. They are all heroes. Atul Gawande trod this ground years before Syed, and did it better: directly; sincerely; sensitively.

Syed’s book is a poor recruiter for a great employer. At its core is a simple, powerful and useful message, but some flaws are unforgivable. Central to a writer’s integrity is a clear and honest use of words. You cannot, in one paragraph, tell your readers that they must learn a new subject and, in the next, treat the subject’s core vocabulary with a lazy disdain. Syed earnestly understands that there would be a better world if the scientific method were more widely understood and better applied; if objective truth were served as slavishly as the will to power. He wants his friends to know this too. But remember, journalist, that we engineers will continue to practise and hone our trade in our tiny rooms long after your friends follow the siren call of something more lucrative. Our tools and our knowledge are ours: do not abuse them.

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 millions of us with a modicum of 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.

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.’ Prepare to produce a lot of dross on the road to success. All performers are poor at first; nobody gets great without a lot of practice. Solicit feedback from customers at a really early stage, when you’re still a bit embarrassed by your product: 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 from measurement of its inputs and outputs without attempting to understand the reasons for this relationship. 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 didn’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 nozzle optimisation problem from two directions. This nozzle must create detergent granules by firing a hot, pressurised liquid into air where it solidifies and lands as a correctly-sized powder. 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 successful working model 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, tweaking the nozzle design, and iterating the best-performing candidates over dozens of generations; finishing when it was as good as it was going to get. Hundreds of prototypes later, the ‘black box’ approach worked, and Syed narrates this as a victory for the empirical, evolutionary approach. Dyson, who created thousands of iterations of vacuum cleaner to arrive at the first commercial prototype of his dual cyclone, also finds himself press-ganged into Syed’s war. Take that, physicists!

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 practices. Both teams’ methods are in alignment with scientific best practice: each collected data and analysed it and approached a truth. Some physicists were attempting to develop a theory that solves the general case and failed. Some biologists set out to attack the specific case and succeeded. My conclusions are:

  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. Changing tactics saved the project, at the cost of limiting scope. The price of a solution was paid by abandoning a general understanding of the problem.

So Unilever have a brilliant nozzle, and the method that produced it, but they’ll never know why it works or whether there’s an even better one. The only way to double its capacity or change the formula of their fluid is 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, and no amount of post-event rationalisation excuses a non-working prototype. (Although, if you’re building Mars landers for the European Space Agency, it seems you can crash-land as many as you like, act as though you succeeded, and continue to get funding, but I’m talking about real jobs.)

An external perspective of scientific method will help a wider audience to understand it. There are certainly pickings in this book for technical readers too, but it’s principally for an audience who don’t get, or even seek, the same class of feedback from their work that a technologist will. 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’.