原创 Don't assume anything (Part 1)

Here's a quote from Robert Stephenson:

"You will say that I am always conjuring up awful difficulties & consequences—my answer to this is it is an important part of the duty of an engineer."

He was the brains behind the Britannia Bridge, which opened in 1850 between Wales and the island of Anglesey. It is quite a novel design, it stood for 120 years before being structurally compromised by a fire.

Take my kids, please
Raising children is a humbling experience. The young parent, full of zeal, is excited by all that he can teach that formative mind. But the experience also shapes the much less malleable adult's brain. For one finds that deeply held beliefs and assumptions crumble when the tough choices of reality intervene. Very good reasons arise why that core belief is simply, in a particular case, wrong.

Here's just one of many examples: I was convinced that the high school kids shouldn't own cars. Like the Amish, I felt this would disrupt family life and create even more of a barrier to communication. Then my son presented a plan to buy—with his money—two 30-year-old VW microbuses with seized engines and a plethora of other problems, and build one working vehicle from the pair of wrecks.

The result was exactly the opposite of what I expected. We spent our free time working together companionably for most of a year, rebuilding an engine, swapping transmissions, fixing the brakes and all of the other issues. He learned auto mechanics and a pride in ownership of the phoenix that was the product of his vision and our shared experience. We established a new, special bond despite the afflictions of teenagerhood that lasts to this day, many years later.

Parents tack and jibe, slowly learning the meta-lesson: all of our assumptions are wrong.

Brilliant but brittle
Building embedded systems is, too, a humbling experience. Young engineers charge into the development battle armed with intelligence and hubris, often cranking out systems that may work but are brittle. Unfettered by bitter experience, they make assumptions about the system and the environment it works within that, while perfectly natural in an academic cloister, don't hold up in the gritty real world. Inputs are noisy. Crud gets into contacts. Mains power is hardly pristine. Users do crazy and illogical things.

The root cause of brittle systems is making incorrect assumptions—assumptions that may be so banal and so obvious no one questions them. But question them we must.

For instance, what is the likelihood the sun will rise tomorrow? Dumb question; for four billion years the probability has been 1.0. Surely it's safe for an engineer to think that the sun will indeed appear tomorrow as it always has. Five or six eons from now it will be a burned-out cinder, but our systems will be long landfilled by then.

Recently a developer told me about a product he worked on that changed the display's color scheme depending on whether it's night or day. It does a very accurate calculation of sunrise or sunset using location data. Turns out, a customer took one of the units above the Arctic Circle where it crashed, the algorithm unable to deal with a sun that wouldn't rise for months.

The sun may not rise tomorrow. Don't count on anything.

Hardware fails, too
An instrument I worked on used a large hunk of radioactive cesium-137 to measure the thickness of steel. Elaborate safety precautions included a hardware interlock to close a shutter, blocking off the beam, if the software went nuts. But at one point a defect in the hardware design caused the shutter to cycle open and closed, over and over, even though the software was correctly issuing commands to close the radiation source. It's hard to know where the invisible beam impinged, but I'm pretty sure that the VP looking down into the unit was getting a dose to his forehead. I saw him a couple of years later, his hair now snowy white. Was the gray from the radiation or his kids with their shiny new drivers' licenses?

Hardware interlocks can fail or suffer from hard-to-diagnose design flaws.

1 + 1 is not equal to 2
Some scientists believe the Ishango bone demonstrates an understanding of arithmetic back in the Upper Paleolithic era. That suggests that for 20 millennia Homo sapiens has known that 1+1=2.

But only a very green developer succumbs to the utter fiction that, in the computer world, one and another one, too, sum to two. Sure, that's what we were taught in grade school, because young children aren't equipped to deal with the exigencies of adult life. In a perfect world, a utopia that doesn't exist, that summation is indeed correct. In an embedded system, if variables a and b are each one, a+b==2 only on a good day. It could also be 0x1ab32, or any other value, if any of a number of problems arise, such as one variable being clobbered by a reentrancy problem, or a stack getting blown.

Complexity buried in our systems, even so deeply as to be invisible in the code we're examining (such as some other task running concurrently), can corrupt even seemingly obvious truths.

[To be continued on Don't assume anything (Part 2)]