The reefs here in the Exumas are treacherous and largely uncharted. We've been navigating these waters for a few weeks in our 32-foot sailboat. Navigation marks are non-existent, GPS coordinates suspect, and some of the charts are based on surveys 150 years old. Guidebooks compiled by experienced older Bahamas hands help us find our way, and we've learned to figure depths by reading the color of the water. But some channels are much too intricate and convoluted; safe passage requires hiring a pilot, generally a wizened older fellow who has spent a lifetime moving vessels through these reefs. The pilot's mental chart is precise, necessary, and yet utterly unquantifiable.
Sailors call this type of insight “local knowledge . It's far more useful and accurate than any combination of sophisticated charting, electronics or satellite imagery. My home port is on the Chesapeake Bay; all ships moving on that large body must, by law, employ a pilot during the transit. These folks are so highly trained and tuned to the Bay that their “final exam” before getting pilot qualifications is to draw a chart of the Bay, with all marks and beacons, shoals and channels, from memory. Yet their knowledge is more accurate than the chart they draw, since, as in Mark Twain's Mississippi days, channels change and shift. These experts watch the water every day and are tuned into current conditions, not those codified on a chart issued months or years in the past.
Centuries of experience have proven the value of local knowledge. I'm astonished that we techies don't understand how important local knowledge is to any viable organization.
Two of my recent Embedded.com articles (“The H1-B issue” and “Older, wiser and out to pasture”) brought floods of replies from readers. Both pieces had an underlying common theme — that dumping engineers in favor of younger/cheaper people is a bad idea. Readers' emails strongly — oh so strongly — agreed and disagreed with my views. (That's what makes writing these pieces so much fun). A lot of people made the reasonable, though I fear unsustainable, point that companies must find the cheapest labor they can, regardless of consequences. Cost management is, after all, central to making profits, and profit is the cornerstone of capitalism.
But dumping engineers for any reason leads to a critical loss of local knowledge. For better or worse, none of our work products is a “this is why I made this decision” document. A schematic, VHDL equations, and even a pretty well commented source file all give a how-it-works view of the system, never any insight into the blind alleys we wrestled with and eventually bested while developing the product.
I've asked automotive companies how they preserve their experience. A hundred years of engineering experience has disappeared as the workers leave in periodic mass layoffs or simply retire. I'm told there's no central book documenting design decisions. Remember the Pinto? A badly placed fuel tank led to tragic deaths and many costly lawsuits. That expensive lesson is preserved, apparently, only in the heads of the engineers. Assuming they still work for the company.
One outfit I know has a 75 year-old engineer on staff simply to answer customer questions about a product sold a quarter century ago that is still in use. He's hardly overworked, taking only a handful of calls per day. Cost effective? That's hard to say since the direct revenue traceable to his work is probably zero. But what a fantastic way to attract and keep customers! Once in a while developers working on current products hit him with a question; his knowledge of the products and the industry, his local knowledge, helps the younger crowd avoid expensive mistakes.
What's the answer? Is cost containment, often implemented by dumping older folks, ultimately a costly or even suicidal approach? What do you think?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at . His website is .