• Welcome to the new Internet Infidels Discussion Board, formerly Talk Freethought.

The Rise and Fall of Convoluted Syntax

Convoluted language is a part of a wider fashion for elaborate decoration. It's a symbol of wealth, education, and class, and above all of scarcity, and makes an excellent marker of these things, as it is profligate with resources - time, money, and learning - that are unavailable to the common man.
I had no end of trouble with this tendency in Boeing's engineering community. Engineers spend about half their time writing descriptions, assembly/disassembly instructions, and operational procedures. Our school system tends to teach expository writing, which might make sense in writing essays and formal letters, but it doesn't help a lot in technical language. So you get a lot of fancy technical descriptions in manuals that could be written far more simply and clearly. The worst problem in a technical community is not just with convoluted ways to describe simple instructions, but the use of jargon to signal technical competence to the reader. The problem with that in the airplane industry and others with an international manufacturing and sales chain is that many of the readers can be technically competent but still struggle with English. And writers don't often realize that jargon may not extend to workplaces outside of the company or shop that develops it. I often found it quite difficult to make that point with engineers, some of whom would invariably argue that it was up to suppliers and customers to learn "proper English". I kept having to make the point that communication failures could cause loss of money, equipment, and lives, sometimes quite catastrophically.
Not quite true.

It depnds on the kind of engineer you are.

There are technical writing specialists that in the Seattle area work as contractors for aerospace companies. They ususally come in at the end of a project.

I have been a design, test, and manufacturing engineer. Wring documentation for complex problems and procedures is far more difficult than you might think. It can become impossible to put it into an obvious and linear step by step structure. At some point you have to rely on the experience and knowledge of the reader to understand it.

The same with writing specifications. There can be interlocking continginciess and dependent conditions that make a linear easy to follow structure. Again it reacquires experience to understand. It becomes a convoluted exercise in formal logic.

I worked o Boeing programs at a company, and had to trasnlate specs into a design.

As with all things, there are bad technical writers. There are engineers who intentionally make straight issues seem complicated. Probaly the same in any profession.

There are threads on math theory on the forum. I have a background in applied math. Not having any background in areas like set theory and other theoretical math the threads are convoluted and arcane to me. To a mathemician it wuld seem clear and straightforward.


There is aslo culture in a community. A way of doing things takes hold and people copy it. Thacan include technical and science writing.
Steve, I appreciate your experience as a contractor, but I worked at Boeing for a quarter of a century on many programs and for many line organizations. Since I was in Research and Technology, I was not just limited to one particular community within the company, and my remit had to do with the standardization of language used in technical documents, especially maintenance manuals, across the entire spectrum of organizations. There was always this dream of standardizing the language used by everyone, but the problems were complex and sometimes insurmountable. Engineers in different organizations and on different product lines would use entirely different nomenclature and local jargon to describe exactly the same procedures and technical systems. We didn't just learn of this problem anecdotally. We analyzed massive amounts of text in the technical manuals. And we were intimately involved in the politics surrounding language usage, including criticism from customers and resistance to change from the engineering infrastructure. One of the main problems was that the literature that ended up getting exposed to customers was at the end of the food chain from design, engineering, and manufacturing. By that time, a lot of the linguistic damage had already taken place and was fixed in stone.
 
This discussion helps show the HUGE variations possible, whether between languages or within a single language, in complexity and clarity. Sometimes complex syntax can be a help to clarity, sometimes a hindrance.


You believe this is better than the original?

IMO, the original is poetry. It is gold, as is the opening of the second paragraph, which Lincoln would turn to such advantage decades later. The opening lines of the Declaration are soul-stirring, even if they were written by a rotten slaveholder. Such are the little ironies of history. These people complaining about subordinate clauses and such would turn the Gettysburg Address into a rental contract the Shakespeare into kindergarten prose.

I agree that these parts of the DoI read like excellent poetry.

(Jefferson's morality was ... ambiguous. On the topic of Jefferson's "rottenness" as a slaveholder, this article might be an interesting starting-point.)
 
Convoluted language is a part of a wider fashion for elaborate decoration. It's a symbol of wealth, education, and class, and above all of scarcity, and makes an excellent marker of these things, as it is profligate with resources - time, money, and learning - that are unavailable to the common man.
I had no end of trouble with this tendency in Boeing's engineering community. Engineers spend about half their time writing descriptions, assembly/disassembly instructions, and operational procedures. Our school system tends to teach expository writing, which might make sense in writing essays and formal letters, but it doesn't help a lot in technical language. So you get a lot of fancy technical descriptions in manuals that could be written far more simply and clearly. The worst problem in a technical community is not just with convoluted ways to describe simple instructions, but the use of jargon to signal technical competence to the reader. The problem with that in the airplane industry and others with an international manufacturing and sales chain is that many of the readers can be technically competent but still struggle with English. And writers don't often realize that jargon may not extend to workplaces outside of the company or shop that develops it. I often found it quite difficult to make that point with engineers, some of whom would invariably argue that it was up to suppliers and customers to learn "proper English". I kept having to make the point that communication failures could cause loss of money, equipment, and lives, sometimes quite catastrophically.
Not quite true.

It depnds on the kind of engineer you are.

There are technical writing specialists that in the Seattle area work as contractors for aerospace companies. They ususally come in at the end of a project.

I have been a design, test, and manufacturing engineer. Wring documentation for complex problems and procedures is far more difficult than you might think. It can become impossible to put it into an obvious and linear step by step structure. At some point you have to rely on the experience and knowledge of the reader to understand it.

The same with writing specifications. There can be interlocking continginciess and dependent conditions that make a linear easy to follow structure. Again it reacquires experience to understand. It becomes a convoluted exercise in formal logic.

I worked o Boeing programs at a company, and had to trasnlate specs into a design.

As with all things, there are bad technical writers. There are engineers who intentionally make straight issues seem complicated. Probaly the same in any profession.

There are threads on math theory on the forum. I have a background in applied math. Not having any background in areas like set theory and other theoretical math the threads are convoluted and arcane to me. To a mathemician it wuld seem clear and straightforward.


There is aslo culture in a community. A way of doing things takes hold and people copy it. Thacan include technical and science writing.
Steve, I appreciate your experience as a contractor, but I worked at Boeing for a quarter of a century on many programs and for many line organizations. Since I was in Research and Technology, I was not just limited to one particular community within the company, and my remit had to do with the standardization of language used in technical documents, especially maintenance manuals, across the entire spectrum of organizations. There was always this dream of standardizing the language used by everyone, but the problems were complex and sometimes insurmountable. Engineers in different organizations and on different product lines would use entirely different nomenclature and local jargon to describe exactly the same procedures and technical systems. We didn't just learn of this problem anecdotally. We analyzed massive amounts of text in the technical manuals. And we were intimately involved in the politics surrounding language usage, including criticism from customers and resistance to change from the engineering infrastructure. One of the main problems was that the literature that ended up getting exposed to customers was at the end of the food chain from design, engineering, and manufacturing. By that time, a lot of the linguistic damage had already taken place and was fixed in stone.
I was not a tech writer. I was out at Boeing once. I had a contract job putting data into DOORS. It is a stanrd software package the at connect and maps all the signals on a system among other things. DOORS is a useful standardization so all programs document in the same way.

Documentation, hardware, and software revision control is another area where standard software packages were important innovations. There are standards for DOD and aerospace software development, documentation, and testing. When I worked for Eldec a software build on a Boeing system was a multi day exercise.

The adaption of ISO drawing standards was a major step in engineering standardization. Add to that the Systems International stabdard units.

What you don;t see is what engineering was like before standardization, and along with that manufacturing.

IBM® Engineering Requirements Management DOORS® (DOORS) is a leading requirements management tool that makes it easy to capture, trace, analyze, and manage changes to information. ... DOORS is an acronym for Dynamic Object-Oriented Requirements System.

You are speaking cliches and stereotypes.

In the 80s I worked at a large Lockheed division. Over my objections I was volunteered to participate in an inter division working group on standardization.

The leader started us off trying to flow chart all processes and procedures so everyone did everything the same way. Doomed to failure from the start,it lasted about 6 weeks. It quickly became impossibly complex.

In large companies somebody, usually a non technical manager, gets the big idea he or she will improve efficiency through standardization and optimization. Some structure is necessary, but it needs the flexibility for adaptions to local needs.

When I worked at Intel in the 80s when they made computers somebody got the idea to get rid of reliability engineering and replace it with standard procedures and it failed.

It comes down to complexity and the limits of human capacity. You can not reduce human creativity to a fixed set of rules. That apllies to human organizations in general. Too much structure and standardization stifles initiative and creativity, too little structure and there is chaos. I have experienced both.

Th term herding cats applies.

Boeing's recent problems are not fixable by procedures, the old Boeing culture of excellence and pride appears to be gone.
 
Convoluted language is a part of a wider fashion for elaborate decoration. It's a symbol of wealth, education, and class, and above all of scarcity, and makes an excellent marker of these things, as it is profligate with resources - time, money, and learning - that are unavailable to the common man.

When the ability to do something (and writing is no exception) is hard won, the ability to not only do it, but to do it the hard way, with style and panache, is an acceptable way to show off without seeming vulgar.

Once that skill is widely available to the common people, there's a tendency towards utilitarian and simple forms, that get the job done (perhaps even better than the artistic and complex forms so prized in earlier times), and away from decoration and embellishments that show the wealth and status of the person who commands that skill.

This can be seen clearly by making a comparison between non-linguistic products of the eighteenth and twenty-first centuries.

View attachment 37315

View attachment 37316

This is really true, and a great point. We can see this trend everywhere. An example is architecture.

An example is the rise of modernism, the “form follows function” school that arose in 20th century. It banished the decorative, often gaudy and ostentatious embellishments of the past for greatly simplified forms that followed from the function of the structure being built. This change was dramatized by Ayn Rand in her novel The Fountainhead. The protagonist, Howard Roark, simply reused to design modern office buildings and homes in the style of Greco-Roman, Romantic and Victorian architecture, going so far as the deride the Parthenon as “rotten.”

In literature, radical simplifications were developed, if not exactly introduced, by Hemingway, a lean, sinewy, get-to-the-point prose that many later extolled as exemplifying an unique American art form that had repudiated the floridity of earlier European prose in much the same manner that Americans had earlier repudiated the crown. Yet even before Hemingway, Whitman was doing much the same in American poetry.

But at the same time Hemingway was doing this, Joyce was writing Finnegans Wake, which to this day practically no one understands. From this and many other examples we can deduce that there is no linear progression or regression in literature or anything else, just change over time incorporating evolving cultures, including the fact that culture and literacy over time spread to Everyman.

In political rhetoric, Lincoln was steeped in the language of Shakespeare (“fondly do we hope, fervently do we pray, that this mighty scourge of war may speedily pass away”) yet already in his prose poetry we find a lean, sinewy style that prefigures the prose of Hemingway and others. At Gettysburg, after a long, windy two-hour oration by one of the great orators of the day, Lincoln spoke some 242 words in which almost every line hits the target and smokes like a brand.

As to the Declaration of Independence, the opening lines are intended to convey a sense of grandeur and moment that simply can’t be captured in radical simplifications, or at least not so easily captured. A pendant could argue, for example, that the first lines, “When in the course of human events,” and what follows, could be simplified or omitted, but at what cost? The phrase “when in the course of human events …” strikes you silent. You listen. It tells you that what is to come is of great importance. It’s not just for now, but for all time. It’s not just for us, but for all humans — a lesson Lincoln learned well, when he leaned on the later line, “we hold these truths to be self-evident, that all men are created equal…” as a cudgel against he slavers, and also in pointing to the declaration as evidence that the United States was older than the Constitution, and that the constitutional compromises over slavery were undercut by the older “all men are created equal” declaration.
 
...
The adaption of ISO drawing standards was a major step in engineering standardization. Add to that the Systems International stabdard units.

What you don;t see is what engineering was like before standardization, and along with that manufacturing.

Actually, there has never been a time when there were no standards in engineering, and I started working at Boeing in the 1980s. Language standardization was one of my areas of expertise, and I have published research and conducted quite a few training classes on the subject. So I think that you are jumping to some unwarranted conclusions about my experience. :)

...
In the 80s I worked at a large Lockheed division. Over my objections I was volunteered to participate in an inter division working group on standardization.

The leader started us off trying to flow chart all processes and procedures so everyone did everything the same way. Doomed to failure from the start,it lasted about 6 weeks. It quickly became impossibly complex.

:LOL: You have my sympathies. I know exactly what you are talking about. Not all standards are well-constructed. I have worked on projects and even chaired committees that worked on language standards--in Europe as well as the US. Trust me. I understand what you are talking about.

In large companies somebody, usually a non technical manager, gets the big idea he or she will improve efficiency through standardization and optimization. Some structure is necessary, but it needs the flexibility for adaptions to local needs.

When I worked at Intel in the 80s when they made computers somebody got the idea to get rid of reliability engineering and replace it with standard procedures and it failed.

It comes down to complexity and the limits of human capacity. You can not reduce human creativity to a fixed set of rules. That apllies to human organizations in general. Too much structure and standardization stifles initiative and creativity, too little structure and there is chaos. I have experienced both.

Th term herding cats applies.

You are preaching to the choir, except maybe that I believe standardization is absolutely necessary. I came to respect the difficulty of developing a standard by committee. Everyone wants to develop a standard, and they all want it to be based on their individual experiences and practices. I'm no different from everyone else in that respect. You can't develop a standard without making compromises, which are sometimes quite crazy sounding when they get down to the level of training and implementation. The problem is that the lack of standardization is far, far worse than making the effort, and there is no such thing as a perfect standard. Good engineers make the effort to go along with them, even if they don't like them. We developed a good working process for maintaining and evolving the standard to meet the needs of engineers that it was inflicted on, although I know that doesn't mean that our efforts were always appreciated. Not all change requests get approved, although we made a point of explaining a rejection to the person asking for a change.

Boeing's recent problems are not fixable by procedures, the old Boeing culture of excellence and pride appears to be gone.

Tell me about it. I lived through the culture change. I have many scars to prove it.
 
Boeing has word police? One is never surprised at anything anymore. What happens when somebody does not conform? Or are they recommend but not required?

Is there a list of approved terms? I would think use of terms in a Boeing document cod have legal ramifications in a court case. There is a legal difference between shall do and will do in a document for example.

What was the material results of your work?

There are standards for engineering terms.




Abstract
Keywords
Metrics

Abstract:
Advertisement, IEEE. In the expanded and revised IEEE Standard Dictionary, you find over 300 sources of input, including terms from all IEEE Standards since 1972; many from ANSI Standards. The 20,254 entries make up the bulk of the text Over 7,000 terms are new, or have been revised since the 1972 edition. Each entry is an official standard of the Institute of Electrical and Electronics Engineers, Inc. This is the most authoritative single-volume dictionary of electrical and electronics terms available anywhere. Here are some of the features: 20,254 definitions, embracing the total language of E/E engineering; 896 pages; more than 140 illustrations; Comprehensive revisions assure most up-to-date definitions of terms; Identification of defining document and source field; New coding system simplifies identification of sources; Equations and formulas set in large, easy-to-read type; Designation of preferred terms, deprecated terms and alternate usages; Explanatory notes; and Cross indexing provided.

But all this does not address the OP on convoluted science documents. To me that is for peer review to acess.

A Boeing process document is written for general usage. An engineering and in the case of the OP a science paper is written for peers, not general reading or undemandi outside of the community.

A Boeing manufacturing document has to be readable by customers, lawyers, and company personell. A paper on new materials does not.
 
Boeing has word police? One is never surprised at anything anymore. What happens when somebody does not conform? Or are they recommend but not required?

I started out my career working on a project to create a kind of grammar checker that would help engineers writing aircraft maintenance documents to adhere to the international aerospace standard now called ASD Simplified Technical English (formerly AECMA Simplified English). You can get a copy of the standard on the web site, if you are interested. All aerospace manufacturers are supposed to comply with it in writing maintenance documentation, but it has become something of a more general standard across other kinds of documentation. Airbus, but not Boeing, actually uses it for aircraft operations manuals as well and uses that fact as a marketing tool when trying to sell to airlines (especially Asian) that are not in English-based countries. I've taught classes on the subject in a very wide range of industries with technical writing needs.

Is there a list of approved terms? I would think use of terms in a Boeing document cod have legal ramifications in a court case. There is a legal difference between shall do and will do in a document for example.

It's something known as a "controlled language". There is a core of basic vocabulary, but different companies are free to develop their own technical nomenclature and terminology as long as it conforms to certain guidelines in the ASD-STE100 specification.

What was the material results of your work?

There are standards for engineering terms.


The standard tries not to step on the toes of other existing standards, especially ASD standards. ASD Simplified Technical English has been widely regarded as the gold standard for industrial controlled English. As the chair of the US national committee, I was the US representative to the ASD STE100 committee in Europe for quite a few years.

But all this does not address the OP on convoluted science documents. To me that is for peer review to acess.

It does in the sense that controlled writing standards are designed to prevent convoluted language, but this is something of a diversion from the topic of the thread. For example, the STE standard does not allow sentences for procedures and instructions to be longer than 20 words, which forces writers to break them down into simpler steps. Sentences in descriptive text cannot exceed 25 words. Technical names, to the extent that the writer can control them, cannot be longer than 4 words--a big problem for engineers who like to create mile-long names for things. (But existing nomenclature can override the restriction.)

A Boeing process document is written for general usage. An engineering and in the case of the OP a science paper is written for peers, not general reading or undemandi outside of the community.

A Boeing manufacturing document has to be readable by customers, lawyers, and company personell. A paper on new materials does not.

Well, that all depends on what kind of section you are authoring in the document. Unfortunately, lawyers are not overly concerned with readability, and STE is designed to improve readability. So there is a little war going on between lawyers and those who promote plain English writing standards. One thing I can say with confidence is that lawyers should be bound by restraining orders that keep them away for the language in warnings and cautions. Those are exactly the kinds of text that you want engineers to read and understand, but lawyers do their best to make sure that the language is convoluted as hell. From a legal perspective, they are only interested in making sure that the company is not liable for damage, injuries, and deaths when the company is being sued. Procedural language should be written to minimize or prevent people from actually causing damage, injuries, and deaths.
 
Boeing has word police? One is never surprised at anything anymore. What happens when somebody does not conform? Or are they recommend but not required?

I started out my career working on a project to create a kind of grammar checker that would help engineers writing aircraft maintenance documents to adhere to the international aerospace standard now called ASD Simplified Technical English (formerly AECMA Simplified English). You can get a copy of the standard on the web site, if you are interested. All aerospace manufacturers are supposed to comply with it in writing maintenance documentation, but it has become something of a more general standard across other kinds of documentation. Airbus, but not Boeing, actually uses it for aircraft operations manuals as well and uses that fact as a marketing tool when trying to sell to airlines (especially Asian) that are not in English-based countries. I've taught classes on the subject in a very wide range of industries with technical writing needs.

Is there a list of approved terms? I would think use of terms in a Boeing document cod have legal ramifications in a court case. There is a legal difference between shall do and will do in a document for example.

It's something known as a "controlled language". There is a core of basic vocabulary, but different companies are free to develop their own technical nomenclature and terminology as long as it conforms to certain guidelines in the ASD-STE100 specification.

What was the material results of your work?

There are standards for engineering terms.


The standard tries not to step on the toes of other existing standards, especially ASD standards. ASD Simplified Technical English has been widely regarded as the gold standard for industrial controlled English. As the chair of the US national committee, I was the US representative to the ASD STE100 committee in Europe for quite a few years.

But all this does not address the OP on convoluted science documents. To me that is for peer review to acess.

It does in the sense that controlled writing standards are designed to prevent convoluted language, but this is something of a diversion from the topic of the thread. For example, the STE standard does not allow sentences for procedures and instructions to be longer than 20 words, which forces writers to break them down into simpler steps. Sentences in descriptive text cannot exceed 25 words. Technical names, to the extent that the writer can control them, cannot be longer than 4 words--a big problem for engineers who like to create mile-long names for things. (But existing nomenclature can override the restriction.)

A Boeing process document is written for general usage. An engineering and in the case of the OP a science paper is written for peers, not general reading or undemandi outside of the community.

A Boeing manufacturing document has to be readable by customers, lawyers, and company personell. A paper on new materials does not.

Well, that all depends on what kind of section you are authoring in the document. Unfortunately, lawyers are not overly concerned with readability, and STE is designed to improve readability. So there is a little war going on between lawyers and those who promote plain English writing standards. One thing I can say with confidence is that lawyers should be bound by restraining orders that keep them away for the language in warnings and cautions. Those are exactly the kinds of text that you want engineers to read and understand, but lawyers do their best to make sure that the language is convoluted as hell. From a legal perspective, they are only interested in making sure that the company is not liable for damage, injuries, and deaths when the company is being sued. Procedural language should be written to minimize or prevent people from actually causing damage, injuries, and deaths.
My main problem with documents at MDC/Boeing was conformance with MilSpec standards out of Dayton. Government-ese at the time made corporate-ese look like child's play. Of course I wasn't writing corporate specs and procedures. I was writing funding requests from DoD sources. For that we got lots of help from professional writer teams within MDC and Boeing. Thank goodness for that.

My main gripe with corporate documentation was with the silo mentality, In the eighties and nineties each division had a funding arm so proprietary was reduced to this and that division. Artists groups had equipment from one vendor while design groups had vendors from another vendor and manufacturing had ... and retrofit and maintenance had .... and customer support had another .....

It ended up with drawing having to be translated from one format to another just to get the damn product to market. I made a fortune solving that little chestnut. BTW the problem cost MDC about two billion dollars in fines by DoD in 1991 on the C-17. Actually it was that MDC had no CAD design images because they were not willing to pay the price in personnel and equipment to keep schedule in phase four of acquisition process. They just had artist renditions at the time. Couldn't keep schedule.

Saved the company billions of dollars by just getting common or multiple format capable equipment throughout the company. We even had divisions within the corporation with incompatible CAD systems up until 2000.

Now that is dysfunctionality.

My greatest contribution was in driving integration of remote sites with common access and measurement embedding in video and remote CAD via internet to design, retrofit, and built systems with image and document processing, functions, and certification (electronic signature). This resulted in reductions of problem and change turn around by up to six months per incident. Probably still in use. Of course I didn't do this alone I just convinced them with examples of previous heartaches.
 
Boeing has word police? One is never surprised at anything anymore. What happens when somebody does not conform? Or are they recommend but not required?

I started out my career working on a project to create a kind of grammar checker that would help engineers writing aircraft maintenance documents to adhere to the international aerospace standard now called ASD Simplified Technical English (formerly AECMA Simplified English). You can get a copy of the standard on the web site, if you are interested. All aerospace manufacturers are supposed to comply with it in writing maintenance documentation, but it has become something of a more general standard across other kinds of documentation. Airbus, but not Boeing, actually uses it for aircraft operations manuals as well and uses that fact as a marketing tool when trying to sell to airlines (especially Asian) that are not in English-based countries. I've taught classes on the subject in a very wide range of industries with technical writing needs.

Is there a list of approved terms? I would think use of terms in a Boeing document cod have legal ramifications in a court case. There is a legal difference between shall do and will do in a document for example.

It's something known as a "controlled language". There is a core of basic vocabulary, but different companies are free to develop their own technical nomenclature and terminology as long as it conforms to certain guidelines in the ASD-STE100 specification.

What was the material results of your work?

There are standards for engineering terms.


The standard tries not to step on the toes of other existing standards, especially ASD standards. ASD Simplified Technical English has been widely regarded as the gold standard for industrial controlled English. As the chair of the US national committee, I was the US representative to the ASD STE100 committee in Europe for quite a few years.

But all this does not address the OP on convoluted science documents. To me that is for peer review to acess.

It does in the sense that controlled writing standards are designed to prevent convoluted language, but this is something of a diversion from the topic of the thread. For example, the STE standard does not allow sentences for procedures and instructions to be longer than 20 words, which forces writers to break them down into simpler steps. Sentences in descriptive text cannot exceed 25 words. Technical names, to the extent that the writer can control them, cannot be longer than 4 words--a big problem for engineers who like to create mile-long names for things. (But existing nomenclature can override the restriction.)

A Boeing process document is written for general usage. An engineering and in the case of the OP a science paper is written for peers, not general reading or undemandi outside of the community.

A Boeing manufacturing document has to be readable by customers, lawyers, and company personell. A paper on new materials does not.

Well, that all depends on what kind of section you are authoring in the document. Unfortunately, lawyers are not overly concerned with readability, and STE is designed to improve readability. So there is a little war going on between lawyers and those who promote plain English writing standards. One thing I can say with confidence is that lawyers should be bound by restraining orders that keep them away for the language in warnings and cautions. Those are exactly the kinds of text that you want engineers to read and understand, but lawyers do their best to make sure that the language is convoluted as hell. From a legal perspective, they are only interested in making sure that the company is not liable for damage, injuries, and deaths when the company is being sued. Procedural language should be written to minimize or prevent people from actually causing damage, injuries, and deaths.
My main problem with documents at MDC/Boeing was conformance with MilSpec standards out of Dayton. Government-ese at the time made corporate-ese look like child's play. Of course I wasn't writing corporate specs and procedures. I was writing funding requests from DoD sources. For that we got lots of help from professional writer teams within MDC and Boeing. Thank goodness for that.

My main gripe with corporate documentation was with the silo mentality, In the eighties and nineties each division had a funding arm so proprietary was reduced to this and that division. Artists groups had equipment from one vendor while design groups had vendors from another vendor and manufacturing had ... and retrofit and maintenance had .... and customer support had another .....

It ended up with drawing having to be translated from one format to another just to get the damn product to market. I made a fortune solving that little chestnut. BTW the problem cost MDC about two billion dollars in fines by DoD in 1991 on the C-17. Actually it was that MDC had no CAD design images because they were not willing to pay the price in personnel and equipment to keep schedule in phase four of acquisition process. They just had artist renditions at the time. Couldn't keep schedule.

Saved the company billions of dollars by just getting common or multiple format capable equipment throughout the company. We even had divisions within the corporation with incompatible CAD systems up until 2000.

Now that is dysfunctionality.

My greatest contribution was in driving integration of remote sites with common access and measurement embedding in video and remote CAD via internet to design, retrofit, and built systems with image and document processing, functions, and certification (electronic signature). This resulted in reductions of problem and change turn around by up to six months per incident. Probably still in use. Of course I didn't do this alone I just convinced them with examples of previous heartaches.
Keep those wheels greased. Hang in there.
 
Boeing has word police? One is never surprised at anything anymore. What happens when somebody does not conform? Or are they recommend but not required?

I started out my career working on a project to create a kind of grammar checker that would help engineers writing aircraft maintenance documents to adhere to the international aerospace standard now called ASD Simplified Technical English (formerly AECMA Simplified English). You can get a copy of the standard on the web site, if you are interested. All aerospace manufacturers are supposed to comply with it in writing maintenance documentation, but it has become something of a more general standard across other kinds of documentation. Airbus, but not Boeing, actually uses it for aircraft operations manuals as well and uses that fact as a marketing tool when trying to sell to airlines (especially Asian) that are not in English-based countries. I've taught classes on the subject in a very wide range of industries with technical writing needs.

Is there a list of approved terms? I would think use of terms in a Boeing document cod have legal ramifications in a court case. There is a legal difference between shall do and will do in a document for example.

It's something known as a "controlled language". There is a core of basic vocabulary, but different companies are free to develop their own technical nomenclature and terminology as long as it conforms to certain guidelines in the ASD-STE100 specification.

What was the material results of your work?

There are standards for engineering terms.


The standard tries not to step on the toes of other existing standards, especially ASD standards. ASD Simplified Technical English has been widely regarded as the gold standard for industrial controlled English. As the chair of the US national committee, I was the US representative to the ASD STE100 committee in Europe for quite a few years.

But all this does not address the OP on convoluted science documents. To me that is for peer review to acess.

It does in the sense that controlled writing standards are designed to prevent convoluted language, but this is something of a diversion from the topic of the thread. For example, the STE standard does not allow sentences for procedures and instructions to be longer than 20 words, which forces writers to break them down into simpler steps. Sentences in descriptive text cannot exceed 25 words. Technical names, to the extent that the writer can control them, cannot be longer than 4 words--a big problem for engineers who like to create mile-long names for things. (But existing nomenclature can override the restriction.)

A Boeing process document is written for general usage. An engineering and in the case of the OP a science paper is written for peers, not general reading or undemandi outside of the community.

A Boeing manufacturing document has to be readable by customers, lawyers, and company personell. A paper on new materials does not.

Well, that all depends on what kind of section you are authoring in the document. Unfortunately, lawyers are not overly concerned with readability, and STE is designed to improve readability. So there is a little war going on between lawyers and those who promote plain English writing standards. One thing I can say with confidence is that lawyers should be bound by restraining orders that keep them away for the language in warnings and cautions. Those are exactly the kinds of text that you want engineers to read and understand, but lawyers do their best to make sure that the language is convoluted as hell. From a legal perspective, they are only interested in making sure that the company is not liable for damage, injuries, and deaths when the company is being sued. Procedural language should be written to minimize or prevent people from actually causing damage, injuries, and deaths.
My main problem with documents at MDC/Boeing was conformance with MilSpec standards out of Dayton. Government-ese at the time made corporate-ese look like child's play. Of course I wasn't writing corporate specs and procedures. I was writing funding requests from DoD sources. For that we got lots of help from professional writer teams within MDC and Boeing. Thank goodness for that.

My main gripe with corporate documentation was with the silo mentality, In the eighties and nineties each division had a funding arm so proprietary was reduced to this and that division. Artists groups had equipment from one vendor while design groups had vendors from another vendor and manufacturing had ... and retrofit and maintenance had .... and customer support had another .....

It ended up with drawing having to be translated from one format to another just to get the damn product to market. I made a fortune solving that little chestnut. BTW the problem cost MDC about two billion dollars in fines by DoD in 1991 on the C-17. Actually it was that MDC had no CAD design images because they were not willing to pay the price in personnel and equipment to keep schedule in phase four of acquisition process. They just had artist renditions at the time. Couldn't keep schedule.

Saved the company billions of dollars by just getting common or multiple format capable equipment throughout the company. We even had divisions within the corporation with incompatible CAD systems up until 2000.

Now that is dysfunctionality.

My greatest contribution was in driving integration of remote sites with common access and measurement embedding in video and remote CAD via internet to design, retrofit, and built systems with image and document processing, functions, and certification (electronic signature). This resulted in reductions of problem and change turn around by up to six months per incident. Probably still in use. Of course I didn't do this alone I just convinced them with examples of previous heartaches.
Keep those wheels greased. Hang in there.
I don't think about Boeing unless you or another Boeing person rants. Been retired now for 20 years.

Keep on keeping on Steve Bank.
 
Back
Top Bottom