The Power of Inertia

"The principle of inertia is one of the fundamental laws of classical physics which are used to describe the motion of matter and how it is affected by applied forces. Inertia is the property of an object to remain constant in velocity unless acted upon by an outside force." [ Wikipedia ]

Like physical objects individuals, teams and organisations have the property that they will continue uniformly straight ahead unless acted upon by an external force. This can be a good thing, it can also be a bad thing. Sometimes it is necessary to find an external force sufficient to effect change.

When this happens in individuals it is often described as "a habit" - one can deliberately cultivate good habits (e.g. writing and running unit tests) and can accidentally fall into bad habits (e.g. failing to resynchronise the code being worked on with source control). Once developed these habits are unlikely to change unless some "external force" (perhaps in the form of a colleague's comments) motivates a change.

Teams are the same - once a build & test server is in place reporting the status of the project after each check-in it will remain there (until something happens) but if it isn't there very few teams will make the effort to put it into place. Actually, much the same can be said of source control.

When it comes to organisations the same is true, they will cling to processes and procedures that are demonstrably against their interests until there is sufficient pressure to cause a change.

It can be frustrating when trying to effect a change in a person, team or organisation - because it will often feel that one keeps pressing and pressing and nothing happens. On the other hand, once the desired change is, finally, under way it then has inertia on its side.

The latest in the ISO C++/CLI story

Since my editorial in Overload 75 about the ISO "Fast Track" last year there have been few obvious developments in the C++/CLI story. There has been no new revision of the standard submitted and the Ballot Resolution Meeting has been scheduled in Oxford (for the Friday, Saturday and Sunday at the end of the ACCU conference week).

Behind the scenes there have been things happening - the ECMA group responsible for submitting the standard (TC39/TG5) has been trying to decide what to do next. This isn't as easy as it might appear - just as there is no provision for National Bodies to say "please withdraw this from the standards process", there is no provision for a submitter to withdraw a standard once it has passed the "comments" stage.

And so, despite the significant concerns expressed by various experts in the field, things are rolling relentlessly on. As the ISO C++ working group is meeting in Oxford the week following the ACCU Conference, they should be well represented at the Ballot Resolution Meeting.

And now for something almost, but not entirely, the same

As expected, the ECMA Technical committee for Office Open XML Formats submitted the ECMA Office Open XML standard to ISO for fast track approval on the 5th January. According to their schedule of work [ ECMATC45 ] this 6000+ page document is intended to standardise "Office Open XML" which is the latest way for Microsoft Office applications to store and interpret documents as files.

Making this information public is a commendable piece of openness on the part of Microsoft, but there is no advantage to the wider community from this being made an ISO standard. One does not have to read the whole thing to discover its true nature is documentation of a proprietary format. How else to explain the many references to the behaviour of Microsoft products (e.g. requiring the replication of bugs in Excel's date handling) and the incorporation of Microsoft technologies that are clearly not open (e.g. Windows Metafiles).

One of the principles for ISO standards is "Consensus - The views of all interests are taken into account: manufacturers, vendors and users, consumer groups, testing laboratories, governments, engineering professions and research organizations." [ ISO ] It doesn't take much investigation to discover that most manufacturers of office software products are supporting the existing ISO standard for document formats. (For a list of products supporting the ISO OpenDocument format [ ISOOpenDoc ] see the list maintained by the OpenDocument Fellowship [ OpenDocApps ].)

As I noted before, the National Bodies have a thirty day period to identify "contradictions" that could prevent the standard being adopted by ISO. (So this period should be closed by the time you read this.) Andy Updegrove [ Updegrove ] summarises this process as follows:

During the first one-month step, any member may submit 'contradictions', which, loosely defined, means aspects in which a proposed standard conflicts with already adopted ISO/IEC standards and Directives. Those contradictions must then be 'resolved' (which does not necessarily mean eliminated), and these resolutions are then presented back to the members during the second stage to consider as part of the voting package. During this second, five-month step, other objections, questions and comments can be offered by members.

There are also many users and consumers who do not feel that ISO standardisation of this standard is in their interests. There is even a collaborative (Wiki based) project to document contradictions on Grokdoc [ Grokdoc ]. It remains to be seen how many of the National Bodies can be persuaded to take action to oppose this standard as a result. (For the reasons I described in my earlier editorial the default position is, in practice, to vote for adopting a standard that is under discussion.)

In the case of Office Open XML, even more so than in the case of C++/CLI, the presumption that any standard being submitted to voting on by National Bodies has been properly reviewed is wrong. It is a large document (over 6,000 pages), has been created in a relatively short period of time and with a small number of reviewers.

There appears to be no advantage to anyone outside of Microsoft in ISO adopting this as a standard - when there are requirements like 'Emulate Word 6.x/95/97 Footnote Placement', this is not going to be easy for anyone else to implement. What is more, the licences I've seen for these products forbid reverse-engineering to discover how these features operate.

Despite all this I fear that Office Open XML will follow C++/CLI down the fast track. The responsible ISO (JTC-1) committee will not find the contradictions a sufficient cause to divert this standard from the Fast Track and the longer (5 month) voting period will begin. If this happens, a lot of effort will be required to produced sufficient informed "no votes" to force a ballot resolution meeting, and this may still decide to proceed with adoption.

The ISO Fast-Track process

I'm sure you'll realise by now that I feel that the ISO Fast-Track process isn't always working in the best interests of the IT industry (either consumers or producers) and not even in the interests of ISO itself.

I think the problem resolves to one thing - it doesn't impose a condition that there is sufficient interest from the National Bodies in the adoption of the standard. The first question that should be asked is not "does this standard contradict anything we have already?", but "do we want to work on adopting this as a standard?". The problems arise when too few of the National Bodies care enough to scrutinise a submission properly.

Hopefully, as a result of the input it is getting, JTC-1 will recognise the need for change and revise the process accordingly.

Overload and Overload

As I explained in my last editorial, there has been something of a crisis in the Overload team. You'll see that the names in the credits have changed yet again to reflect the new line-up. Thanks again to those leaving the team for efforts over the years that have passed, and to those joining the team for their efforts in times to come.

Thanks also to all of you that submitted articles - especially the few whose articles I had to turn down because they didn't quite seem to fit Overload. I do hope the feedback was helpful and that we will see more submissions from you in the future.

The current issue didn't quite run as smoothly as in the "golden age" I described last time - in particular I have to apologise to a couple of authors for feedback taking longer than it should have done, and also to the production editor for a slightly late delivery of the edited articles. We understand how to address these mistakes and - fortunately - no real harm was done. We intend to do better next time.

After the difficulties with Overload 76, I'm pleased to see that the new team has settled into the task and I confidently look forward to things running smoothly straight ahead for the foreseeable future.

All that remains to keep Overload going is for the rest of you to submit some articles for the next issue. And this is the time to do so: with many of the "usual suspects" focused on conference presentations, this is a chance for the rest of you to sneak in and write the article that everyone will be reading and talking about at the conference.

Those of you that are presenting should not rest on your laurels - you have the material for an article to hand - so now is the very best of times to write it up.

Overload on the web

My comments last time about making Overload available on the website seem to have overlapped with Allan Kelly making the archive publicly available. The result isn't what I've been intending: instead of a single PDF for each issue I plan for the articles to be presented separately, preferably as HTML, and for links to work. Once again, sorry for the delay.