The making of sausages and standards

Laws are like sausages, it is better not to see them being made. -- Otto von Bismarck.

I sometimes feel the same way about standards. My best friend and I have been in software for more than 25 years. For more than half of that time, we've been working together, at four separate companies (and not just name changes or purchases, counting those, it would have to be 7 or 8). He's always been the one too see two sides of any argument, to drive consensus, and adeptly manage people (including me). I've always been, well, as he describes it "A Cowboy", or as I do, a tilter at windmills. I can tell you that I've knocked down a windmill or two, but that many others have won. Today, my friend is writing code for his own company for too many hours a day at his kitchen table, and I'm deeply involved in standards, and much to both our amazement, "Politics" (the word is often said from one side of the mouth, and then you have to spit afterwards).

Those who understand the strategic importance of standards to their organizations have involved their best leaders in these activities. That sometimes make standards development and selection a political process, and it has more than occasional skirmishes. I can think of about 4 or 5 offhand going on right now, without even blinking. Some of these are fairly mild, and others are real battles, and at least one is on the verge of war. Often these battles are held in areas populated by a number of rather innocent, and sometimes even, totally unaware bystanders.

Slightly more than a decade ago, I participated in my "first" standards activity. I was a member of the interest group for the W3C DOM2 (Document Object Model). The company I worked for had many people involved in W3C activities, include the product manager for the product team I led. She used to regale me with stories of the battles between two of the major players on how DOM2 would go, and which of their implementation feature sets would become part of the new standard. When two 500 pound gorillas have a dominance fight, everyone better clear some space. Her descriptions of the (dare I call them) discussions were reminiscent of scenes from Bloodsport, although not at all physical.

There are three ways of dealing with difference: domination, compromise, and integration. By domination only one side gets what it wants; by compromise neither side gets what it wants; by integration we find a way by which both sides may get what they wish. -- Mary Parker Follet

Often, one way to resolve these sorts of disputes is to make sure that neither of the gorillas win. Both are often willing to agree to a "draw", as neither gains any advantage from the outcome of the battle. But what about those not directly in conflict? Like most bystanders, they more than likely lose, at the very least valuable time, and in some cases, a chance to make a truly good choice.

Another way to resolve these sorts of disputes is to look very clearly at both sides of the issue, and try to craft a solution using the best aspects from both sides. When this does occur, the collaborative process really shines. This synthesis produces something advantageous to all, and we are no longer playing a zero-sum game.

What I learned from those days was that standards discussions that are motivated by financial incentive and not based on technical merit are to be avoided at best. If they cannot be avoided, then at the very least, financial motives should be very clearly laid on the table. In many organizations, there is a taboo on discussing practical realities such as cost. However, these considerations have a significant impact on the utility and uptake of the standard. We need to find ways to discuss the topic of implementation costs openly, and not hide debates related to that topic in some other guise.

Some questions I use to tackle this topic follow:

• Can it be implemented with open source tools?
• Can it be implemented with commercially available tools?
• Is implementation of this a senior project, a doctoral thesis, or a massively funded effort?
• Can I hire software engineers from any field to build it, or do they need to be specially trained?
• Can I buy a book on it?
• Can I take a class on it?
• Does it work with existing infrastructures, or will I have to rip and replace?

Later in my career, I entered healthcare and the realm healthcare standards. I found myself unwittingly not just in the middle of another battle, but as the field general in a war. This was a highly political disagreement between a pair standards organizations that I was a member of. Tactically, I believe that battle to have been concluded successfully, and the peace treaty seems to be holding. Strategically, I think it's still being fought, but as a rather meager guerrilla action. I know I'm not paying much attention to it these days. I learned a great deal from that war.

• Pick your battles.
• Stick to your principals.
• Respect the opposition.
• Religious battles are never won through logic.
• Persistence Pays

Pick your Battles

The technical work of standards development is time consuming enough, as anyone participating in it well knows. Fighting political battles takes time away from those activities at the very least, and often you wind up with nothing to show for it. In a world where you see the same people involved in many places, making an enemy in one place is something that can follow you around to many others. You don't become a target alone, but so does anyone else associated with you.

Stick to your Principals

Make sure that your issues are openly aired and debated. If there is something that you are unwilling to talk about, consider your motives. You never want to be put into a position of being embarrased by having your motives either questioned or exposed. If you cannot be shamed by that, then you can never lose from embarrasment.

Secondly, fight clean. Stick to technical merits. Avoid falacious arguments, ad hominem attacks and other dirty tactics. Standards development is a long process. What you lose from fighting dirty (even if you win) will stick with you for a long time, and can make future debates even more difficult.

Respect your Opponent

Act as if your opponent in any debate has good reasons for their position. Try to see those reasons. Remember what I said about trying to make sure that you aren't playing a zero-sum game. Learn how to agree to disagree, and then go eat sushi (or have a beer). Standards work is best done with people that can respect others with differing opinions. Mutual respect often allows all parties to find win-win solutions, and we can all benefit from that result.

Religious battles are never won through logic

Never try to teach a pig to sing; it wastes your time and it annoys the pig.
-- Robert Heinlein

Just about everyone I know who is involved in healthcare standards has a deep passion for their work. When that passion overrides intellect, useful discussion often ceases. Be aware, and don't engage yourself in the same mistake. If you find yourself trying to preach to the unconverted, and aren't succeeding, stop. You might very well be wasting the time of both parties, and worse yet everyone else around you.

In this particular field, everyone I run into is an expert, with credentials out the ying-yang. I've discovered that's really meaningless. Don't trust your gut. Try it out. What really counts is what happens when the paper hits the code. In your own arguments, stick to technical merits, and not your opinions, others can usually discern fact from opinion.

Failing that, if you have encounter a religious debate, there are at least two useful strategems:

• Identify the topic as being one that is "unresolvable" and work on other aspects (agree to disagree).
• Identify the topic as a pre-established "religious" debate that experts have been arguing about for X or more years, without any resolution. This tactic works only if your opponent is unwilling to move at all, but you are.

You can usually identify a religious debate by noting two polarities (x vs. y or black vs. white), where neither has yet dominated, and where expert opinion may still be divided on the topic. In these issues, the beliefs of both sides are often well documented. The document vs. message debate in computing has existed long before HL7 ever showed up on the scene. The element vs. attribute debate in markup languages has been in existence for 20 or more years. No solution to either of these debates has yet proposed itself. Most experts these days agree that there are places for each. Putting yourself in a position of espousing "one true way", when in fact there are many, is simply asking for failure. Who after all, wants to be associated with a radical?

Persistence Pays

In the end, being persistent counts.

One man scorned and covered with scars still strove with his last ounce of courage to reach the unreachable stars; and the world was better for this.

-- Don Quixote

P.S. I'll return to the topic of Genomics and Structured Family Histories soon.