Let me be the first to properly welcome you to the 21st century and the new millenium. Just one short year ago, it seemed as though lifeas we know it (or at least computing as we know it) might grind to a halt on the false millennial-eve because of short-sighted engineering decisions made decades earlier.

Having earned my stripes in the embedded trenches, I was quick to tell anyone who asked that there was nothing to fear on New Year's Eve 1999. "Embedded developers simply don't build unneeded functionality, like calendars, into their systems," I must have explained to a hundred friends and family. It seems I was right. The power stayed on; the water ran; no elevators stuck; no airplanes fell from the sky; traffic lights continued to control access to intersections; and Dick Clark remained on the air, the latter however unfortunately.

But these days I'm less confident in the embedded systems to which we entrust our lives and livelihoods. It seems that everywhere I go vendors are encouraging the inclusion of unneeded functionality, and far too many developers are taking them up on it. Consider embedded Linux. While not so unreasonable a choice in a few specific classes of systems-like set-top boxes or embedded PCsLinux is clearly overkill in the vast majority.

How do you even begin to test the safety and reliability of a system with so much complexity and so many authors? Can systems made from a mish-mash of off-the-shelf software components and rushed to the production floor be trusted? Who will certify that these systems are worthy of deployment or purchase? And who will ensure that they are safe and reliable?

Looking back now, I wonder how anyone even found time in 1999 to fix date-related bugs and/or certify systems as "Y2K compliant." The U.S. economy has been running at full speed for well-nigh a decade. The high-tech job market is hot and the amount of work for each engineer to do astounding. In such a climate, anyone halfway to a technical degree can find a job writing software for real products. Combine that with the pressures to get products to market quickly and you've got a clear recipe for disaster.

Surely, despite such horrible past disasters as Therac-25, the worst software-induced losses of life and limb lie ahead of us. We must, as an industry and to a person, insist on a higher standard of engineering. We must test our systems and design them to ensure their consistent behavior. Safety and reliability must be our first goals, not our last.

I implore all of you to raise the issues of safety and reliability within your own companies. Avoid unneeded functionality at all cost. After all, years or decades from now, human lives or livelihoods may still depend on the engineering decisions you make today.

Return to Table of Contents