Communicating with Style

I've developed a preoccupation with grammar and literary style recently, which is a little weird for an engineer. I've thoroughly enjoyed reading things like Orwell's Politics and the English Language, I've been trying my hand at writing a bit, and I've nurtured a deep revulsion of business-world statements like

"we will create go-forward action items offline"

that replace direct statements like

"we will assign responsibilities after the meeting".

which I suppose people find uncomfortably committal.



Sensing a need, a friend recommended I read Strunk & White's Elements of Style, which is 52 pages of awesome. With headings like "Express co-ordinate ideas in similar form" and "Place the emphatic words of a sentence at the end", it's so succinct that you honestly can improve your writing just by reading the table of contents. The book is filled with ways of choosing words, phrasings, and structures of sentences and paragraphs that inherently keep a reader interested and convey your meaning. It isn't just about writing correctly; it's about writing to most economically get what's in your head into somebody else's.

Partway through I realized that I was reading the programmer's guide for the English language; it ought to have a woodcut of an obscure mammal on the front.

Following the rules in Elements of Style takes work, but the book implicitly makes the argument that if you're not following these rules, you're wasting your reader's time and trying his patience. That is, if you don't decode your ideas into writing that is easily parsed, the reader has to decode it and that extra effort is what drives him away. Your goal as a writer should be to convey your intent as economically and elegantly as possible. This realization tickled something familiar in my brain.

It put me in mind of what I've heard from Google employees about their approach to writing code; a process for which the goal is also to convey (functional) intent economically and elegantly. As I understand it, they use a single language throughout the company and have an extremely fixed and structured style guide that is layered atop correct programming practice for the language, much like the rules in Elements are layered atop correct English usage. At Google, it's very possible to write good code that compiles and works, but violates their style guide. Conversely, it's possible to write bad code within the style guide that behaves poorly, but I get the impression that it's both more difficult to write bad code and easier to see bad code when it's writtten within the guide. In essence, you have to fully understand the intent of your code because the guide makes it harder to convey poorly-defined intention within poorly-formed code.

I think that same kind of focusing of intent applies to written (or spoken) English, and is the reason Elements is so powerful. Of course some writing is meant to be more expressive than functional, like a sketch of a nude has a different meaning than an engineering drawing, but to the extent that your words are meant to convey ideas, forcing yourself to write with good style isn't just a social convention; it forces you to put your ideas in order such that you can encode them in effective writing. The structure of conveyance improves the intention itself.



Closer to my own experience, I'll give another example that I think splits the difference between English and computer code: CAD modelling. This too is a process of conveying intent, where my intent here is a widget in my head that I want to make real, conveyed in a CAD model that can be used to manufacture it. It's a creative process in that I have a lot of freedom to define what form I want for my widget, but a rigorous syntactical process in that I must precisely define curves, surfaces, and manufacturing details.

But what are the Elements of CAD Style? First, let me start with simple grammar:

The software I use, Pro/Engineer, is primarily an engineering-oriented program because every feature of a model must be defined precisely and parametrically -- meaning that if I modify a feature, the software cascades the change through the subsequent features that reference the first, attempting to modify them to fit. The sequence of features forms a chain, with each feature dependent on a previous feature like the arguments of a logical proof where at each step one can say "certainly it is true, Socrates". Let's see how this works.

The basic unit used to define almost any feature is a "drawing", which looks something like this:



This drawing is "fully defined", meaning the various dimensions shown leave no room for ambiguity. Two lengths, an angle and a radius set basic dimensions, and the final constraints such as the V (vertical line), H (horizontal line), and T's (tangencies) remove the final degrees of freedom. A machinist could cut that shape out of a piece of metal from the dimensions and constraints alone, with confidence that the result would match my expectations. A drawing such as this is like a grammatically correct sentence.

This drawing can now be used to create a feature, such as an "extrude" which simply adds a height to the drawing to create a solid, like this:



At any time I can go back and change any of the dimensions in the original drawing (or indeed the height value for the extrude) and my model will automatically update, sliding and moving around to adjust. This is extremely powerful if I'm, say, designing an engine block and I can do things like turn a 6-cylinder engine into an 8-cylinder version just be changing one number.

I can get myself into trouble however. Here I have modified my original drawing a bit:



I have increased the radius of the curve from 4 to 7, and the drawing adjusts accordingly. But notice I have taken the size of this curve near to a critical point where the angled line has nearly disappeared. I can't show you the drawing with the radius set to 8 because if I try, Pro/Engineer becomes very upset that I asked it do something impossible; the feature "fails" and Pro/E will either put it back the way it was, or simply remove it. In more extreme cases, a whole cascade of drawings and features may cease to exist if I try to make a change like this -- a process Pro/E users usually refer to as the model "blowing up". This is a severe Pro/Engineer grammatical error, causing a whole paragraph or chapter to no longer make sense in its wake, to stretch the metaphor a bit.

This kind of fragile precision can feel painfully limiting when you're in the creative process of trying to design the look of a product. For this reason, many industrial design companies will only use Pro/Engineer in the last phase of a design, when the look has been defined in a more free-form CAD program and creating a manufacturable engineering model is all that remains.

I always hate doing that because it means small mechanical changes require a cycle of exporting data between programs to update my design, so instead I do both creative and engineering design in Pro/E. As I've done more and more complex projects, I've started to feel like I was approaching the limits of my single-software approach, but on a recent project, I had something of a Strunk & White experience; the constraints of the engineering-oriented software forced me to improve my intent, even though I wasn't committing any "grammar" errors. The project was to design a TV involving a lot of complex curves.

Before doing any CAD, I created a simple 2D illustration of the basic form I had in mind, based on the functional constraints I knew I had, such as the screen size and the required curve of a back face. It looked like this:



Fine: I began to model. I created the major surfaces of the TV's back and seamed them into a shell that did what I had in mind. I got to the point where I needed to create the base of the TV, at which point my CAD model looked like this:



Pro/Engineer has a tool that allows me to select 2 curves and the software calculates a surface "stretched" between them. I thought I would use this tool to create a simple, smooth blended surface in the bottom corner of the TV as in my original illustration, and started like so:



Clearly not my intention, but this same tool also allows me to define 2 edges which run between the endpoints of my 2 original curves, to completely define the outer perimeter of the surface I want, like this:



"Cool, that was easy!" I clicked "Done" to commit the new feature.



"That looks a little funny, " I thought. "Stupid software."

But wait, what exactly did I expect that surface to look like? Pro/E did what I asked, admirably trying to blend between pretty different curves with no hint what to do in the expanse between them. Sure, I could have tweaked and smoothed things, but in 3D it was still a pretty lumpy, boring-looking feature, even though it looked essentially like my 2D illustration in side and back views. Even though it had created the requested feature, Pro/E's engineering-oriented brain needed a clearer phrasing of intent grounded in engineering reality, not just vague outline.

After pondering a bit, I decided that what I really cared about was the smooth surface running down the side of the TV, and the shape of the curve at the front. So I took a new approach to modeling my newly-found intent, starting by extruding that front curve directly backward, ...



... then creating a tangential extension to the side surface that flowed smoothly downward, ...



... and finally trimming the excess outside the intersection of the two new surfaces:



"Much better!" I thought. After some more work, I ended up with a TV back like this:



And for comparison's sake, here are the initial and final 4-view drawings:



Rather than serving as an "intuitive", flexible tool to get my initial thought into 3D with the least effort, the software had forced me to consider my true intention more completely by forcing me to phrase that intention in precise engineering-oriented terms. Using precisely extruded and referenced surfaces, I was much happier with the result. Like a clearly written paragraph from Elements of Style or a clever bit of well-formed Google code, putting in the extra effort to address proper form had paid off in a better conveyance of intention, intention I hadn't even decided on until forced to do so.

Of course not all sets of constraints on style work this way, but I'm learning to respect the good ones. Since we all have to write from time to time, I can recommmend Elements of Style as an excellent place for anyone to begin, even if I'm still a lot better at Pro/Engineer than I am at written English.