I have been thinking recently about professional engineering communication.

I was reminded once again of the lack of consensus by Nancy Leveson’s comment that “[t]he type of limited interaction that is possible by email is just not conducive to communication” as well as her regret at being “… pulled into one of these web debates because it takes so much time and produces so little”, on the University of York safety-critical systems list http://www.cs.york.ac.uk/hise/safety-critical-archive/2009/0369.html. I don’t agree with this view on email. I am a heavy user of email, both for longer essay-style pieces (although I am now moving more towards blogging) and for short exchanges. I consider e-mail lists such as that run by York to be an appropriate and helpful form of professional communication. I might agree partially with her view on WWW forums, because I find some forms problematic for professional purposes, but then again I think some of them work well (for example, the York list archive is a WWW forum).

I think no one medium available to us satisfies all the communicative needs of engineers in a developing field. I propose that prowess in engineering communication, traditionally required for evaluation of academic personnel, be based on more than traditional journal- and conference-paper publishing.

Advance in engineering depends on communication somehow. If one person in the world finds out how to solve engineering problem X, then unless heshe spreads the word, or word gets around via hisher customers, that technique remains hidden and others will not use it to solve problem X.

For the solution of specific engineering problems, or for the communication of engineering problems themselves (such as the “hot topic” of ice particle icing), it seems to me that traditional journal and conference publication works quite well, even though there are all sorts of problems with peer review procedures.

However, for discussion of current practice, or historical practice, and for discussion in general, declamatory articles such as those which appear in journals or conference proceedings don’t work that well. Neither do the magazines (because articles are by their nature declamatory). Journal or magazine letters pages also don’t work that well – witness the recent interchange between Keith Miller and myself on the Gotterbarn/Miller paper in the June 2009 IEEE Computer, which proceeded much more rapidly and fruitfully, but also privately, by e-mail than it did through the letters/reply section in the magazine (IEEE Computer, August 2009). See previous blog posts here for the public exchange.

I hold discussion to be very important in the engineering profession. Witness, if you will, again, the Ladkin/Miller exchange. Had this not occurred, Messrs Gotterbarn and Miller would be on record as holding that the recent A330 incidents were an instance of SE ethical problems of a certain sort, whereas they now agree that the issues are more subtle, if not other, than they originally proposed. A change of view arrived at through discussion.

Consider another example: how does one best handle issues of best practice, such as formal-language specifications versus natural-language specifications? Such issues need discussion: some think “natural language specs are best”; others think “formal language specs are best”, and there are different communities of practice built around these views. If you work in safety-critical electronics in the European railway industry, you must use natural-language requirements specifications because the standard says so, even though you might think this is a load of junk. Whereas if you work in one of the more prestigious sectors of avionics, you would likely do formal-language specs, even if you were a nat-lang-spec enthusiast.

Some people think the standardisation processes suffice for communication of best practice. Others think, as I do, that the neither the standardisation process nor the emission of standards suffices to communicate best practice. Indeed, I would go further. I also do not think the emission of standards necessarily embodies best practice, as my contributions over the years on the functional-safety standard IEC 61508 on the York list may indicate.

So what does embody best practice and how does one tell? Well, one thing to observe about the engineering profession is that there is no one way to skin a cat. There are many, and the best engineers will be intimately familiar with all of them, or at least with as many as they can be. One engineer may prefer one way, another engineer another way. What could they suggest to a third engineer, also attempting to skin a cat?

Engineer A: “Do it my way.” Engineer B: “Don’t do it his way; do it my way”

or

Engineer A: “Do it my way.” Engineer B: “Yes, do it his way; don’t do it my way”

or

Engineer A: “I do it this way, but any other way will work. However, I can help you best with my way.”

All these answers are possible from responsible engineers, who would have taken into account their interrogator’s environment and that of hisher task.

Engineers must interact this way. It is an important part of what they do. It is communication, it is necessary, and the question I wish to address is how, using what form, it may best be accomplished.

Let’s make it more concrete, with a concocted example whose content appears regularly on the York list.

Question: “I am building such and such a safety-critical system and we have to use the programming language C because that is what we have a compiler for, for the chosen hardware. Is this OK or should I veto the project.”

Answer 1: “Your source code, if it is written in C, will have no well-defined unique meaning. C compilers have odd quirks such as producing different object-code behavior depending on which order one writes the arguments to a test, and ………. So you will not be able to tell exactly what your object code does and thereby not be able to assure the behavior of your system to the required degree. To get the highest degree of assurance attainable by any practice to date, use, say, SPARK and an Ada compiler to avoid the problems with C detailed above, and to take advantage of the documented quality of SPARK code development. This may necessitate changing the underlying hardware if there is no Ada compiler targeted to your hardware. If you can’t change the hardware then recommend SPARK for the above reasons and at the same time veto the project.”

Answer 2: “There exists enough experience with C and C subsets such as the MISRA subset and C static analysis tools that you can be fairly assured of a more-or-less unique meaning for what your object code does, providing you pay a lot of attention to the known weaknesses of C constructs as listed in [a ten-year-old book] and you are careful about your choice of compiler and carefully research the known problems with the compiler and avoid them. The available analysis tools aren’t perfect but they are pretty good for most purposes. And, besides, Engineer Y has shown one can [read: he can] do this in a significant project. And, besides, everybody does it. And, besides, if you are stuck with this hardware, as you say you are, you have no real choice.”

Ripost from Answerer 1: “Sure, Y is one of five people, or fifty people, or one hundred people in the world that have a track record of doing this. Hire him. Or one of the other 5/50/100. Then you might be OK. Else, do it the way I said.”

Now, imagine you are buying the car in which this equipment is installed, one of a few thousand, or a few hundred thousand, or a few million built, for your family. Wouldn’t you rather that such a discussion had taken place in a highly prestigious forum, which as many eminent engineers as possible read, and can contribute their views, as required? And that some sort of consensus had developed as to what the questioner should do, and that some sort of assurance was available that heshe had done it?

So what would that forum be? The York mailing list? Not really- not all professionals read that list, and some of them think about it that “[t]he type of limited interaction that is possible by email is just not conducive to communication.” Leading journals that everybody reads? Well, it doesn’t happen. Or, better said, in my experience the journals in which such things appear are not much worth reading. Why is that?

It is that way, I propose, because this kind of discussion is not accorded the prestige which, say, journal publication of research accrues. In my view, a way should be found to value participation in insightful and fruitful discussion as prestigiously as journal publication, because such discussion is equally vital to engineering, as I hope I have just shown.

Well, a gainsayer might say, Engineer A can publish hisher view in a journal. Then Engineer B can reply. And then Engineer C, and so on.

I don’t think that will work in general. Consider the following recent example.

On June 1, an Air France A330 crashed into the South Atlantic in an area of unstable weather, having sent a series of cryptic maintenance messages from the Central Maintenance Computer as its last communications. Bits of the aircraft have been found, but not the bits most important to knowing why it went down.

Somebody found and published a report from another airline of a flight which had suffered similar phenomena at a similar altitude. And then other reports surfaced. People who had access to these reports had their own professional interests which would induce them to certain behavior, such as keeping them quiet or broadcasting them. Broadcasting is the only stable state: you cannot keep something under wraps once it has been broadcast. One of the major players is an anonymous broadcaster, a WWW site, called eurocockpit.com. The advantage of broadcast in this instance is that all the various pieces of data, available only to some people and not to others, have been brought together into the public domain.

The result of this communication activity has been that, probably within a month and certainly within two months, almost all pilots are aware of and wary of a phenomenon which on May 31, 2009 was not known to exist: high-altitude ice-particle icing of air data sensors. There were individual incidents, indeed many, but nobody knew about them all, and if you just know about one or two perplexing incidents there are many possible causes of it or them. But when you have a dozen, or a couple of dozen, and another one occurs as you are wondering, then it concentrates the mind wonderfully. The result is that EASA has published a proposal for an Airworthiness Directive aimed at replacing all those sensors thought to be more susceptible to ice particle icing than others.

The odd thing about this example is that the airplane in question has been in service for well over a decade, indeed much nearer two, and these incidents have apparently only occurred since March 2008. Explain that one! (Anyone who says “global warming” must go stand in the corner for an hour 🙂 )

My view is that you cannot explain it at the moment, but that the communication behavior around whatever symptoms of whatever phenomenon we are talking about here (likely ice particle icing) could have been different from what it was up to the loss of Air France flight 447 on June 1, 2009, which apparently suffered these symptoms. And maybe it could have been different in such a way as to have led to measures which could have averted the loss of an airplane and its occupants? A fine article on this history, which raises this question, has recently been written by Jens Flottau and appeared in Aviation Week and Space Technology on August 10, 2009: Response to Airbus Pitot Tube Incidents Under Scrutiny.

To be clear: I am talking here about forms of communication which we use, and not at all about any specific individual or organisational behavior. I am not suggesting that any individual, group or organisation did less than the very best they could about the evolving issue. Indeed, this remark serves to strengthen my suggestion that the communication forms themselves can give us a level of control over engineering developments, such as experiencing, recognising and then handling ice particle icing of air data sensors, which we do not currently possess.

It is not just ice particle icing of air data sensors. Ice particle icing caused engine problems to one type of engine on the BA146 airplane. It was not known to occur to others, but some Boeing and Honeywell engineers looked at incidents of surge, flameout and other anomalous events at altitude on other airplanes and came to the conclusion that they were due to icing phenomena at high-altitude, sometimes in cloud which was so thin that it barely hindered visibility. This stuff has appeared in the journal literature: see The Ice Particle Threat to Engines in Flight by Mason, Strapp and Chow, 2006, which refers to Cloud Particle Measurements in Thunderstorm Anvils and Possible Threat to Aviation by Lawson, Angus and Heymsfield, 1998. And in 2006 there came NTSB Recommendations to the FAA. But there were still 20,000-hour long-haul pilots (for all I know, still are), a group of people to whom this phenomenon would surely be of great interest, who apparently do not know of this work. One said even as late as a month ago that he does not accept ice forms below -40°C: http://www.pprune.org/tech-log/381558-ice-crystals-2.html#post5070024, and http://www.pprune.org/tech-log/381558-ice-crystals-3.html#post5074951.

It is through the communication of incidents, each of which was previously known only to a few people, many of those people being different people, that a dangerous phenomenon, ice particle icing of air data sensors at high-altitude and cold temperatures, has been identified. This is a significant engineering achievement. How did it happen? WWW. E-Mail Lists. WWW Forums. And, also, traditional methods of communication amongst appointed representatives of involved organisations. But by no means solely the latter.

So, given that discussion and communication is vital to engineers, and the traditional form of journal publication does not suffice, how should the contribution of, say, a research engineer be assessed? (For purposes, for example, of awarding a prize, or awarding tenure, or of getting an academic job in the first place.) I propose that such assessment also look at participation in these other essential communicative activities and not just traditional publications. I agree there is a problem of parameters and quality control. Just getting hits on your blog isn’t necessarily a good measure; but getting the most hits on your blog of anybody working in your area just might be.

To finish up: what forms of communication work, and how?

1. Obviously peer-reviewed journals and conference papers work.

2. Obviously WWW sites with journal-style papers work.

3. I would contend that moderated, selective forums such as the Risks Forum work.

4. I think some sorts of blogs work. I am sceptical of the frequently-written 200-word anecdotal variety of the sort the IEEE is promoting , but I do like the weekly-essay variety employed to such notable effect by people such as Nobel laureate Gary Becker and Judge Richard Posner at the University of Chicago in their blog. It is by following such blogs for a while that I believe I have come to understand what they are good for, and have started trying to emulate.

5. For specific purposes, such as the wider collection and dissemination of controlled information, carefully-moderated anonymous forums such as eurocockpit.com

These are all declamatory forms, with only limited possibility, asymmetrical, for discussion. What works for the kind of essential discussion I illustrate above?

6. Not anonymous WWW forums. I don’t yet know a forum which can be successfully followed unless one has lots of free time and a huge tolerance for purposeless commentary or for poseurs. For example, I have made two unsuccessful attempts to develop a presence on PPRuNe, the professional aviation people’s forum, and PPRuNe seems to me to be head and shoulders above anything else in which one can discuss aviation accidents. The main issue seems to be that moderation attempts are often overwhelmed by the task on high-interest topics, and no one seems to have a good solution to this phenomenon.

7. Yes, non-anonymous controlled-access WWW forums. Such as the York mailing list. (Note that its archive makes this list into such a forum.) A colleague to whom I once mentioned that I had been contacted to write a textbook on safety suggested that all I had to do was collect what I had written on the York list over the years and organise it. (Yes, well, the organisation part. It was simpler to start writing from scratch 🙂 )

8. Something that does not exist, but well might. Peer-reviewed or moderated (same thing, maybe?) non-anonymous forums for publication of essays and for discussion. There is a fundamental tension between encouraging comment, insight and debate, and insisting on quality. Quality means taking time over composition, which in turn discourages people from contributing. There are such forums at present, for example the functional safety area on the IEC WWW site, but they are not hives of intellectual activity.

9. Jan Sanders suggested using video. A forum in which engineering questions could be put, and engineers give their answers verbally in a video, and videoconferencing could be used to resolve, or at least further to discuss, discrepancies. Like written forums, this would be moderated to ensure quality. The advantage of videos would be that it takes many people less time both to record their views and to receive the views of others through speech than it does through writing, and speech is most effective when one sees the speaker speaking.

I am a fan of debating, I like mailing lists and, newly for me, blogs and I wish there were some way of professionally assessing contributions to these forms of communication.