For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
I'll present my Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends January 20.
By Jack Ganssle
In "Knowledge Capture and Management for Space Flight Systems" (http://ston.jsc.nasa.gov/collections/TRS/_techrep/CR-2005-213692.pdf) author John Goodman argues that, particularly in aerospace projects, much vital project knowledge exists only in engineers' heads. Imperfect memories, career changes and retirement means this information goes missing, often to the detriment of a current program, or a future one that could have drawn on what might have been painfully-acquired experience.
Goodman relates that early space efforts took just a few years to complete; Project Mercury ran just over four years from contract award till final flight, Gemini ran 5 years. The Shuttle program, when finally grounded in 2010, will have spanned 38 years, an engineer's entire career. How many original engineers are still associated with that system?
Just two years after contract award the P-38 fighter had made its first flight, and was introduced to the service two years later. The F-4 flew three years after the contract. But the F-22, despite the contractor having built a flying prototype before winning the competition, required an additional six years for the first flight of the contracted aircraft, and a further 8 before the first production model made it to the Air Force. The F-35's schedule numbers are ten and (an anticipated) seven years. These are much more ambitions projects than the primitive, by today's standards, P-38 and F-4, so comparisons are not completely fair. But it's clear that both the complexity of the programs and the engineering duration means preserving design decisions is increasingly important.
In the commercial world the problems are little different. I've often wondered how the automotive companies preserve corporate knowledge. Ford learned at great expense how to position gas tanks due to the Pinto fiasco, but do young engineers who weren't even alive at the time know those lessons learned so painfully, so long ago?
Middle age readers who can't find their keys understand that even a single person's memory is pretty unreliable. I figure the brain is a FIFO queue and when it fills, around age 50, something has to go when one learns something new.
So how do we preserve knowledge? Traditional tools aren't up to snuff. Goodman suggests the use of "Brain Books," more or less engineering notebooks used by developers to record design decisions, test results, and the like. He cites a case where a Brain Book saved a project. But hardcopy is tough to search and poor penmanship hinders understanding.
I keep a notebook in my woodworking shop to record things I learn, that I'll surely forget. There's no computer in that room and the volume of data is very low, so that works well. A variety of pretty organized files on my PCs keep resource notes, interesting quotes, facts and the like. But perhaps a wiki is the ultimate Brain Book repository, and reading Goodman's article has given me motivation to set up a personal Brain Book on a wiki. We're drowning in information and, unless preserved and categorized, an excess of data is the same as no data.
How do you preserve your design notes and other important bits of information that exist outside of normal tool flow?