Commentary

Patricia Keefe
 

Save Lives: Debug Code

We're so used to looking at programming these days as a throwaway, low-cost skill. We discourage students from pursuing it, we outsource the basic tasks, and we routinely struggle with balky applications. Regardless of how smart any of this might be, we know we can live with all that. But the tendency to ignore commonsense requests to thoroughly debug code? Very bad idea. In fact, it can be downright dangerous, according to panelists and attendees speaking at several sessions on topics such as "Lessons From Disasters," "Fantastic Failures," and "Top Problems In Real-Time Software Design" at the recent Embedded Software Conference in San Jose.

We're so used to looking at programming these days as a throwaway, low-cost skill. We discourage students from pursuing it, we outsource the basic tasks, and we routinely struggle with balky applications. Regardless of how smart any of this might be, we know we can live with all that.

But the tendency to ignore commonsense requests to thoroughly debug code? Very bad idea. In fact, it can be downright dangerous, according to panelists and attendees speaking at several sessions on topics such as "Lessons From Disasters," "Fantastic Failures," and "Top Problems In Real-Time Software Design" at the recent Embedded Software Conference in San Jose.The overall point of these sessions was both patently obvious and yet something we rarely think about: Buggy software can cost lives. It already has.


More Windows Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

One session leader, Jack Ganssle, a software expert and author, had a pocketful of perilous stories--both from a financial and human perspective. He pointed to the unmanned Ariane 5 rocket, which exploded in part, he said, due to leftover dead code from the Ariane 4 project. A $100,000 test platform would have caught the error. Instead, the rocket and its cargo--valued at $500 million--was destroyed on its first voyage after a decade of development costing a staggering $7 billion.

Want more examples?

* Inspections of software after the crash of a U.S. Army Chinook helicopter revealed 500 errors, including 50 critical ones, in just the first 17% of code tested. Your tax dollars not at work, I'd say. A court case is pending.

* The Therac 25 was supposed to save lives by zapping tumors with targeted blasts of radiation. Instead, the device delivered massive overdoses that killed three patients and injured several others due to software glitches in code that was never properly inspected and tested.

* In 2003, the pacemaker of a woman in Japan was accidentally reprogrammed by her rice cooker. Other pacemakers have been inadvertently reprogrammed after the patients walked through metal detectors. That hits close to home for me--my mom wears a pacemaker, and she travels a fair amount.

It's not hard to come up with other potential examples--computer software is embedded in everything these days, not just rocket ships and weaponry. Appliances, automobiles (2000 Explorer and 2004 Pontiac Grand Prix), medical devices and implants, and security devices--the list is endless. A malfunction anywhere can lead to significant financial loss or, worse, injury or death to the users, operators, and beneficiaries of those devices and tools.

Looked at in this light, "suddenly" coding and the time spent testing that code matter again. At the very least, software testing should take on a new level of urgency. "This is the only industry left where we can ship products with known defects and not get sued. How long do you think that will last?" asked Ganssle. Especially when, as Dave Stewart, CTO of Embedded Research Solutions, Inc., pointed out, "Spending $2,000 on tools might save you $100,000 in programming effort."

Debugging code has always been right down there on the priority list with project management--something many IT shops either ignore or cut corners on. Not surprisingly, the session leaders talked a lot about project failure, offering up various project management tips, such as writing documentation as you build the code, using version control software, insisting on a good requirements document, and fighting off compressed schedules and feature bloat.

Perhaps not so obvious was the finger pointing at C and C++. Apparently our most popular programming languages are also the most error-prone. Ganssle went so far as to call the use of C "criminal." The stats he reeled off to prove his point are sobering.

My space here is limited, but those stats and the tips and examples of what can and did go wrong, as detailed in the sessions linked to in this blog, are great reading.

Meanwhile, we all know that the reality of IT budget constraints will always mandate that we cut corners where we can, but you can be penny wise and pound foolish. We better start coding (and testing) as if someone's life depended on it, because in too many instances today it does. As Ganssle notes, "We aren't afraid of software, but we need to be because one wrong bit out of 100 million can cause people to die."


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links