I can't pretend that I have any good methods for capturing and maintaining documentation, but I do love the file management system an engineering friend of mine has: I was leaning over his shoulder recently while he was working on his laptop and I noticed he had three folders on his desktop: crap, more crap, and even more crap. He told me that was where he stored the "important" content!
The challenge of documentation is that it is usually intended for retrieval in the future. This means that the effort of documentation has little immediate reward and the future retrieval depends upon maintaining access integrity through time. Three ring binders are bulky and hard to search but admirable in their accessible user interface through time, changing computer software, and operating system. Computer files must be created in a format for which future access is assured and the files must be rolled ahead to each new generation of the storage system. They must also be preserved in a way that is obvious to others. Most computers are reused or retired when their owners retire or pass away. Few files are effectively captured and mined for the corporate benefit. Lab books are visible which at least forces somebody to consciously decide whether to preserve or discard them. Someday, our ability to create data will be matched by our ability to mine it. In the meantime, most recollections of previous solutions depend upon the memory of the inventor; the documentation merely fills in the fine details. The next generation has little hope of mining the digital records of their predecessors.
I use a lot of 3-ring binders, so many it's hard to store them all. I don't use them for everything. For day-to-day notes and planning, I far prefer college-ruled composition books with "granite" covers. They're a nice size, light, and easy to take on public transportation. I carry them everywhere.
I'm also a strong believer in documentation -- the earlier the better. When I'm working on something new and don't know what I'm doing yet, the notebook is excellent. However, once I can start to describe it I find that writing it up using a document editor is a great way to get the ideas filled in, and it becomes the first draft of the eventual documentation. The hard copy goes in binders.
I find it very hard to proof-read on a screen. I always find errors after printing out on paper.
IMO everyone should print hard copy listings of their software and technical references. If doing so creates so much paper that you can't manage, then your design approach clearly needs to be reconsidered.
The days of bound engineering lab notebooks (for patent purposes) that would no longer close due to being stuffed full of Polaroid scope photos are long gone, binders do help solve this.
These days keep all your design notes and measurements on a computer. This way you can search for some long-forgotten entry based on a vaguely remembered keyword, and disseminate your notes through email instead of a photocopier. (Patent lawyers might not agree with this philosophy, makes it too easy to fake the dates.)
The main thing is to write everything down. You never know what you may need at some future time.
My Mom the Radio Star Max MaxfieldPost a comment I've said it before and I'll say it again -- it's a funny old world when you come to think about it. Last Friday lunchtime, for example, I received an email from Tim Levell, the editor for ...
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...