I am of the opinion that no one actually sets out to do stupid things. Rather, stupid things happen almost invariably for the best of intentions. Thus the phrase “The path to hell is paved with the best of intentions”.
And so it goes with standards. In the past week, I’ve been privileged to witness two crystal clear examples of first class paving of the path straight to the gates of hell. The root of both of these examples is the simple fact that the specification organization doesn’t have a process in place for dealing with the changing of a specification after it has been accepted as final. Basically, in this organization, the “final” version of the spec is presented to the members, and the members vote on whether to accept it. Sounds simple, right?
Well, the devil is always in the details and due to the way these things are scheduled, the reference implementations and conformance tests for these specifications aren’t finished at the time that the members vote on the “final” version of the specification. Consequently, if anything shows up in either the creation of the RI, or in the creation of the conformance test which is to verify that the behavior in accordance with the specification, there’s a serious problem that needs to be resolved.
In the two cases I’ve been privileged to see this week, the first was an issue with time. As with all things, resources are limited, and certain resources are scarcer than the sympathy in a banker’s cold, dead heart. Consequently, when the time pressure to produce something gets unbearable as the deadline approaches, the reality will set in and like survivors on a sinking lifeboat, everyone starts looking for stuff to throw overboard. And because this process is done under pressure, there’s not an awful lot of thought and strategy put into the choice of what is being chucked overboard.
In the first case, a particular feature of the specification
was deemed “too hard” to include in the impending release. Thus, it
was going to be chucked. Stupidly, I had the bad sense to ask “why?”
I mean, given that I had actually worked on the implementation which
led to this specification, I have the good (or bad) fortune to actually
have a good understanding of what is going on under the hood with
respect to the actual specification in question. Worse, I actually use
the feature in question quite frequently and have a decent
understanding of what it’s used for and what it does.
So, when I
asked for an explanation for why the feature was considered to be too
hard, the response I got back was a lot of hand waving. I mean, literally
hand waving. Now, I certainly understand time constraints, and if the
issue is just one of time constraints and this was considered to be one
of the things that we decide to chuck to meet these time constraints,
then that’s a perfectly valid reason. But for some reason, humans
aren’t willing to be that simple and straight forward. We have to
rationalize our actions so that they make sense. And that process of rationalization can get pretty darn ugly.
Which is, of course, why things like “process” exists. Process allows
us to formalize the process so that there is not need to provide a
rationalization for a decision which was made for other reasons. It’s
the mechanism which boils away the dross so that only the underlying
issues are presented so that the system can make a good decision
without being screwed over by our collective human nature.
Instead, I was presented with the simply hilarious process of persons trying to convince me that things as they were constructed were “fundamentally” broken. Now, back in the day, I used to do quite a bit of formalized debate, so I know a bit about argument structure. So, when someone makes claim X, there’s this little thing we used to call “Burden of Proof“. Basically, when you make a claim, you have to back it up. The failure to understand the burden of proof, and where this burden lay is the root of a lot of very tragic mistakes.
For example, back in the early years of this new century, the claim was made that Iraq had weapons of mass destruction. That was a claim. The burden of proof should have lain with the people making the claim to prove their case. Instead, what we witnessed was the farcical situation where the burden of proof was shifted to those who questioned the assertion that Iraq had weapons of mass destruction. The result was predictable and quite tragic. We’ll be paying the wages of this insanity for generations to come.
And while not nearly even in the same order of magnitude of import as where the burden of proof lay with those claiming someone has weapons of mass destruction, the same basic stupidity and lack of logical reasoning was on brilliant display when I was flatly told that I had not “proved” my case that the feature being claimed as fundamentally flawed was not, in fact, fundamentally flawed. What happened instead was merely that some issues were presented and the mere claim that these were fundamental was presented. That’s it. I asked why these were fundamental flaws, and further asked for examples as to what couldn’t be done because of these flaws which were fundamental to the issue.
And thus it became quite clear that there wasn’t any argument. There was simply the need to rationalize a decision that was already made.
The second issue which I’ve been privileged to witness this week is somewhat more troubling. Granted, having no argument and relying on faulty logic is troubling, but the actual underlying reasoning had some merit, so even though it was done for the wrong reasons, the result wasn’t totally tragic. Not so with this issue.
In this case, the problem is that there is a fundamental problem with the specification. There is no “there” there. And consequently, when you try to make a conformance test for the behavior, there is nothing you can check.
This is, naturally, a troubling situation. And rather than step back and question the fundamental issue at stake: i.e. maybe you aren’t specifying anything at all in the first place – the reaction was to make an optional service mandatory so there would be something to test.
In the first place, the optional service is purely an internal API. That is, it has absolutely no user visible parts. Consequently, the API is there for the implementors of the specification to use. Now, there’s a zillion different implementations of this spec which don’t make use of this API in their internal implementation. I have a couple already working here in House Harkonnen labs, so I have proof positive. Further, no one actually disputes the fact that one doesn’t have to use this API to make an implementation of the spec – so there isn’t even an argument about whether the API is necessary – the fact that it isn’t isn’t contested.
And so, because there has to be something to test, we will be making a change to the specification – after we have voted on the final specification itself.
And this is how things go badly wrong. It isn’t because someone sets out to do something stupid. Rather, stupid things happen for the best intentions. Everyone is working overtime to make that eight lane hiway to hell as smooth as the best German autobahn so we experience no traffic and the smoothest ride ever.
Right up to the gates of hell.