|For novel ideas about building embedded systems (both hardware and firmware), join the 40,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.
By Jack Ganssle
Published September 2, 2010 in Embedded Systems Design
Memory is a Fragile Thing
I remember being able to remember, well, pretty much everything. A flood of facts and anecdotes were daily stashed in the seemingly infinite non-volatile sections of my brain.
But age takes its toll. In the 40s an increasing percentage of grey matter moves from flash to DRAM, whose refresh logic periodically fails for no apparent reason. So early-middle-agers develop a stable of jokes about their memory hiccups. Time passes and those Alzheimer chuckles aren't so funny anymore as we become caregivers for failing parents. Our future becomes shockingly apparent. Thankfully, we soon forget those fears.
But at any age we all share some forgetfulness so I've always carried some sort of memory-jogger, even when just puttering around the house. I've tried pretty much everything with mixed success: a PDA for a while (too bulky). A voice recorder. But I never remembered to play the messages back. A wallet-sized notebook from Daytimer. That worked for decades. But with the advent of smart phones all of my contact info, previously stored in the Daytimer, is now in e-form. Why carry two somewhat duplicative thingies? I did try storing notes in the phone (and do keep some lists there) but for that quick jotting of a random thought the phone is simply too slow and cumbersome, and is impossible while driving.
Today my preferred note-keeping device is a slip of paper whose contents I read at least every morning. Some of the notations get dismissed as useless errant thoughts from a wandering mind. Others go into various computer files, such as ideas for articles or algorithms to play with as time permits. Some are to-dos that either go into my time manager (currently Time and Chaos from chaossoftware.com, though I'm looking for a more integrated solution) or that get taken care of immediately. But that little piece of paper is the metaphorical string around the finger that keeps me on-track.
When asked for advice by young engineers I offer several thoughts, one of which is to take notes. You will forget. It's best to log too much, as recreating a lost thought is often very costly if not impossible. That new cool idea that's worth a mega-startup could flitter away by the time you step out of the shower.
An important corollary is to be outrageously organized. That's merely an extension of the old proverb "if you have to do something once, do it. If you have to do something twice, write a program to do it." There's no excuse for flipping through stacks of paper to find things or digging around a hard disk trying to locate a file.
Bitter experience has taught me the value of discipline even when engaged in hobbies. For instance, I can never remember how to set up a glue-line router bit. No problem: my workshop has its own dedicated notebook where I record all of these hard-to-remember bits of information. It has tool setup information, notes on sharpening procedures, a log of every knife-change on the jointer and planer, and much more. The information is easy to find and cannot get lost. Memory may be unreliable, but that engineering notebook is probably my most-used woodshop tool.
A low-tech non-volatile memory system.
My sailboat has its own set of notebooks. They record every bit of work done on the engine, part numbers of replacement items, and all of those things one may want to know. A friend maintains his sailing notebook on-line, an effort that requires a discipline I simply cannot muster.
Is all of this anal-retentive? Maybe, but who cares? I'm a systems guy, and when a system has a problem - like imperfect memory - I try to create a solution. (Another bit of advice to young engineers: Don't apply systems thinking to your marriage).
What does this have to do with engineering? Uncertain memory plagues the projects we work on, projects that are so complex there's an ocean worth of information too often maintained in the developer's brain-RAM. Forgetfulness or the proverbial bus can lead to the loss of critical ideas.
Do you back up your hard drives? Most of us have extensive procedures in place to insure we don't lose electronic data, despite hardware failures or natural disasters. Logically, we should be equally careful to preserve our hard-won but often ad hoc ideas and thoughts.
Once upon a time every engineer had an engineering notebook, a bound volume of numbered pages of graph paper. One would see all sorts of odd notations in these books: girlfriends' phone numbers (plural only to cater to nerdish dreams), carryout orders and, yes, lots of jottings about the problem at hand. The books were kept forever (I came across some of my dad's from the 1950s). Company legal departments liked them as they were evidence useful in pursuing patent applications. Managers liked them as their people were less likely to utter the damning phrase "I forget." And engineers liked them as the notebooks preserved a chain of reasoning they could use when trying to recreate an idea.
Engineering notebooks aren't so common today. One might hope they'd been supplanted by computer-hosted documents, but I have doubts. We're under so much pressure to get a product out immediately that any activity that is unrelated to writing code or drawing schematics gets dismissed. But organizational techniques of any sort always incur some cost today. We know there are benefits, though, that will be accrued tomorrow.
You won't remember. Write stuff down.
I prefer, probably out of habit, notebooks from Ampad such as this model: http://www.amazon.com/AMP22156-Computation-Book-Stitch-Bound/dp/B000R80QCW/ref=sr_1_4?ie=UTF8&s=office-products&qid=1283448950&sr=8-4 . At 25 bucks they're not cheap, but the 150 pages takes quite some time to fill. Some folks prefer unlined pages; me, I need the graph rulings to help in making drawings and to prevent my notes from inevitably imitating the parabolic arc of a projectile.
Some like to keep their notes on the computer. While that has the huge advantage of being searchable, it's hard to create a drawing on-screen. Sure, there are plenty of programs that let you make and save sketches, bit I find these slow and cumbersome. Often times the files are incompatible with one's preferred word processor. The engineering notebook, electronic or otherwise, is there to help one play with and ultimately record ideas. If the tool gets in the way of being quickly creative it is not doing its job. This e-age has yet to produce a tool that is as versatile and as fast as a pen on paper.
Write down everything that is project-related. The notebook is your brain's permanent store. Especially log your ideas as they can be so important and so fleeting. Put manufacturer part numbers and contact information in the book as you're researching components. Draw design diagrams, especially in the early stages when you're still playing with structure. Include reference information; for instance, if you're working on the early stages of a design document include a link to the final version. Feel free to staple in pages from other sources, be they algorithms or datasheets. In the sidebar I discuss logging bugs; Grace Hopper even taped her first bug - the insect itself - in her engineering notebook in 1947. That notebook has been preserved at the Smithsonian.
Yours may not be so famous, but it will be every bit as useful.
Do discuss the engineering notebook with your boss. Some groups tell me any record-keeping is verboten due to the potential of litigation. If your company is sued in a way that boomerangs to the engineering department (say, patent disputes or for alleged bad designs that resulted in damages) the rules of discovery may mean the notebook will have to be produced to the other side. Not only will your secrets be revealed, but the inevitable false starts we all encounter - recorded in black and white for the other side to use or twist - may make for an argument that the developers were incompetent.