By Jack Ganssle

The End of Days

Published 10/23/03

When will we get serious about writing great code? Crummy development techniques are the norm, resulting in far too many products that just don't work right.

I've collected embedded disaster stories for years, hoping that sharing them will scare developers into changing their practices. But each disaster is quickly forgotten. Sure, people die when an X-Ray machine goes bonkers or a plane crashes. In two or three days the story winds up relegated to page 5; a week later it fades from memory.

So it seems nothing will change till a truly horrify software-induced failure occurs. What would that be? Maybe a firmware bug that stalls ten million vehicles on the highways. Collapse of the banking system. A month-long nationwide power outage.

Or accidental sobriety.

According to this story (http://www.thejacksonchannel.com/news/2559382/detail.html) computer problems in Mississippi have shut down the entire state's booze distribution system. Liquor stores reportedly cannot replenish their supplies until the computer glitch gets resolved. which might take weeks.

Surely most Mississippians have at least a few extra bottles stashed away for emergencies, but as this tragedy continues to unfold those won't last long. Mississippians will sober up.

That can't be good news for the government. Suddenly citizens will realize their kids aren't being educated, taxes are too high (especially on liquor), and nattering politicians pepper the TV with promises of the impossible while pandering to anyone with lots of cash.

Count on a revolution. Locals will take to the streets in demonstrations while entrepreneurs set up stills to fulfill demand. Liquor tax revenues will plummet, endangering the government's stability.

The boys in Washington are no fools. They'll mobilize the National Guard to airlift in emergency supplies. Watch software consultants' fees skyrocket after the President declares a state of emergency; no price will be too high to get the state's computers - and booze supplies - back to normal.

It'll be the start of a software revolution as well. The anarchy engendered by the buggy software will find both Republicans and Democrats vying for more restrictive development techniques. That won't be enough to satisfy angry (and thirsty) voters. This catastrophe will be a catalyst for new political parties. The Agiles versus Big Up Fronts. XPers against Feature Driven Designers. A code inspection in every product and a 6 pack in each garage will be the new promise made to an electorate suddenly concerned about software engineering.

New parties need new candidates. Bill Gates (http://www.microsoft.com/billgates/default.asp) against Richard Stallman (http://www.stallman.org/). Bjarne Stroustrup (http://www.research.att.com/~bs/homepage.html) vs. Larry Constantine (http://www.foruse.com/).

I'm looking forward to televised debates. Forget tax and spend arguments. It'll be use-cases or design by contract. C# vs. Java. Managing legacy code instead of managed health care for seniors.

You can count on one thing: with all of these techies running, the vote count will be right.

On another topic, I recently wrote about my misgivings with the C language. That article swamped my inbox with email, some are posted with the piece itself (http://embedded.com/showArticle.jhtml?articleID=15306089).

I note three patterns in the replies. The first group wrote: "right on!"

A second consists of people who have used Ada. They were unanimous in praising the strengths of that language. Without exception, all who wrote felt Ada's onerous constraints gave them better code. Generally I expect range of opinions on anything to do with developing embedded systems (put two programmers in a room and you'll get three strong opinions). But the Ada contingent all same the same song. In all my years in this industry I've never seen so many people united about anything.

I have never used Ada on a real project, but this unified front should make us all think.

The third group disagrees - some vehemently -mostly making the point that the language itself is not at fault. Because C gives us flexibility that some - many - programmers abuse condemns the developers, not the language. Hey, I totally agree! There's no question that lousy code stems from shoddy work. But, fact is, few embedded developers are at all religious about employing any practice that results in safer C. Most don't even use Lint; an astonishing number avoid version control systems and practices. So to those who feel C is the ber-language, tell us what you do to ensure your firmware is correct. I'll post the interesting replies.