Re: I hate Word!

From: Guy Macon (http://www.guymacon.com)
Date: 06/18/04 

Date: Thu, 17 Jun 2004 17:10:28 -0700

John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> says...
>
>Guy Macon <http://www.guymacon.com> wrote:
>
>>John Larkin <jjlarkin@highlandSNIPtechTHISnologyPLEASE.com> says...
>>
>>>Most engineering stuff (source code, command parsers, netlists, parts
>>>lists, real-working things like that) need them. Word files can be
>>>read by people, but that's all: they are a dead-end, and they don't do
>>>real work.
>>
>>I have written a web page on this:
>>
>>http://WWW.GUYMACON.COM/ENGINEER/DOCSTD/INDEX.HTM
>
>A longer-term problem is the media itself. Hardly anybody can read 5"
>floppies any more, and almost nobody can read 8" flops, or Dectapes,
>or SyQuests, or whatever. Even CDs will be obsolete some day. Whenever
>we are about to junk an old PC, or a tape backup or something, we copy
>the data onto a more modern medium and burn a few CDs for luck.

...which is why I put in the following sections:

 7.1.2
 Store the document on as many media as possible. An ASCII file on
 an 8 inch disk formatted for Kaypro CP/M is hard to read on a PC
 with CD-ROM and 3.5" floppy. Be sure to store copies on as many
 servers as possible, as server data tends to be backed up and to
 get transferred as new computers and media formats are added to the
 organization.

 7.1.3
 Make nine hard copies on acid free paper (vellum or Mylar preferred) with
 archive quality ink and store three copies in each of three different
 locations. Make microfilm copies if you can.

>I'm not wild about your use of file date as a version control method.
>We formally release everything to the company library as an
>engineering document, with a drawing number and revision letter, just
>like in the olden days of paper drawings. None of this v 4.2.1b stuff!
>This discourages high-rate (as daily, or even hourly) revisions.
>Releasing a document around here is a big, formal deal.
>
>Without serious version control, too many backups can be as bad as too
>few.

That's a different philosophy, and one which I have worked with for
many years (and still use when my employer wants to do it that way).
For projects where I decide on the revision control system, I have
come to the conclusion that there is a better way:

 Revision Control:

 6.1
 All engineering documents shall be archived on a network file server
 in such a way that no single or double failure will make the document
 permanently unavailable. The electronic file on the file server shall
 be considered to be the current version. All paper copies are to be
 considered to be out of date and obsolete at the moment of printing.
 The best that you say about the paper copy is that it was the latest
 version several seconds ago.

 6.2
 All printed copies shall contain automatically computer generated time
 stamps. Any changes to a document will automatically result in a new
 time stamp. Updating of revision numbers is at the discretion of the
 author - readers shall consider the time stamp authoritative and the
 revision level to be advisory only.

Note that it's perfectly workable to use both systems at once; all
you have to do is to copy documents with revision letter and signoff
into my system, and remove the revision letter and signoffs for any
derivative versions. It's the same as if I got an official document
at your company, crossed out the rev letter and signoffs, and edited
it with a pen and some whiteout. Many companies make this even easier
by adding a big red "reference only" stamp when they give an engineer
a copy.

In a company that has a good release system, I would reverse the above
language and make the released version authoritative and all documents
under my system advisory only. In fact, I am going to make that clear
in my documentation standards - you make a very good point. 

-- 
Guy Macon, Electronics Engineer & Project Manager for hire. 
Remember Doc Brown from the _Back to the Future_ movies? Do you 
have an "impossible" engineering project that only someone like 
Doc Brown can solve?  My resume is at http://www.guymacon.com/
Quantcast