Standards Orgs

This week, I participated in ASME's Technology Advisory Panel on Additive Manufacturing. This is the third standards body that I've gotten involved with in the past year or so (I also sit on ASTM F42, and represent nTopology at the 3MF Consortium), and I wanted to post a few thoughts about standards development for anyone who's curious about them or interested in being involved in similar work.

• Most standards bodies were formed out of some deep-seeded industry need: A spate of high profile product failures, a growing sense of frustration amongst customers, etc. Standards are the industry's way of improving their overall product quality, or their public image, or their relationship with key customers (the US military especially).
• Standards orgs make money partly by selling standards and partly by enforcing them and certifying products/companies that comply. As an independent product developer, that can be frustrating (I wrote about this years ago); spending a few hundred dollars to find out how your part will be tested can often seem like a shitty alternative to more... open approaches. On the other hand, most standards orgs are all-volunteer and nonprofit. 
• The fun thing about standards development is that if you care, they'll (for the most part) take you seriously. It doesn't particularly matter if you're officially "in the industry," and you certainly don't need to work at a huge company or have any specific set of interests in the matter at hand. When I joined F42 (ASTM's subcommittee on additive manufacturing), I was working at a consultancy whose primary clients were in marketing and HR. I was working on AM in my free time, and like any intelligent person had developed thoughts on issues the industry was facing; ASTM took me in like any other.
• As something of an outsider myself (in a strict sense, I am not an engineer per se), the experience of being on a more or less level playing field with folks who have spent their careers at global engineering & manufacturing companies is really something. I get a lot out of hearing their takes on the industry, and am glad that someone (me) is there to provide the perspective of a generalist working across disciplines. Standards orgs tend to be places with a high degree of empathy, and it's a pleasure to talk openly - from competitor to competitor, supplier to customer - about how to push an industry in a better direction.

thoughts on standards, revisited

late last year, i posted some thoughts on technical drawing standards on my now mothballed business' blog.  they were an attempt to clarify some things i had been thinking of over the past year or so, and they remain a useful starting point for my own style guide.

i'm now in the position of revisiting many of these items, and will be writing more of my thoughts in the coming weeks.  in the meantime, i'm reposting my initial thoughts here.  some of them are now more fully developed, and some have been partially discarded.  regardless, i continue to welcome any comments. 

I've been spending some time organizing myself and my designs, and am working on creating standards for myself.  A few ideas I've had are below, in no particular order.

• When producing documentation, adopt and use standards that are optimized for digital, not physical, reproduction. 
• Minimize printing whenever possible. When choosing paper sizes, prefer ISO to Architectural, and Architectural to ANSI. (Do so in spite the fact that, at least in North America, this ranking is... inconvenient.)
• Prefer decimal inch or metric dimensions to fractional inches, which round inaccurately, produce inconvenient decimals at small resolutions, and encourage draftsmen to use decimal equivalents with unnecessarily high precision standards.
• Use single spaces between sentences. (This will take some getting used to; the double slap of the spacebar has been drilled into me from years of practice.)
• Track revisions.
• Name all dimensions. Name key features.
• Produce and maintain job books which refer directly to named features and dimensions and explain fit and function of all important design elements.
• Choose cross-platform standards, assuming they don't hurt too much.
• Have fun, etc.

As always, your feedback is encouraged.  I'd be interested in hearing other peoples' experience with and philosophies on standards and documentation aesthetics.

Spencer