Click Here to Print Select Font Size: A A A
Sponsored By
Forum: Our Readers Write
ARTWORK: BRYAN CHRISTIE
"With runaway technological innovation and rapidly changing missions, we need more effective experimental, iterative, and evolutionary [software] practices" —Rick Hayes-Roth

Software Awry

Bravo for a gripping and brutally frank anatomy of a murder ["Who Killed the Virtual Case File?" September Most complex system initiatives fail for myriad reasons. The critical success factors, meanwhile, keep evolving as an organization's aspirations, the available technology, and the rate of innovation change. When faced with runaway technological innovation and rapidly changing missions, we need more effective experimental, iterative, and evolutionary practices.

Across the defense and homeland security landscape today, efforts that normally take years of committee work and documentation to get requirements or models "right" fall at least two generations of technology behind before implementation even begins. Thus, only systems that enter operation incrementally in about a year are likely to prove fit. Because engineering and management methods effective in simpler times are slow and cumbersome, we will witness many more "killings" before effective adaptive approaches become commonplace.

Rick Hayes-Roth

IEEE Senior Member

Atherton, Calif.

I'm sure you will be inundated with suggested additions to your "Software Hall of Shame" ["The Exterminators," September I can't resist a crowd, so I will suggest the following:

  • Therac 25, a therapeutic radiation device that administered fatal radiation overdoses to several patients before its user control interface was corrected.

  • The recent Mars probe that missed Mars because of a misunderstanding as to whether degrees or radians were being used in navigational computations.

Donald Zalkin

IEEE Life Member

Yonkers, N.Y.

While I enjoyed the article on software bugs ["Why Software Fails," September], I would like to note that two critical human aspects of failure are only mentioned once, and therefore not emphasized enough:

  • The system is generally thought of only as components. No (or little) thought is given to its action as a whole.

  • Software is thought of as the system rather than as part of the system. This delusion really needs to be stamped out before effective software design can take place.

This is why the following are critical for a project's success:

  • A person or entity who determines system behavior (not requirements), and thus controls the system's quality and scope.

  • A person or entity who determines system function and reports the cost and time required to make it work.

I would compare many of the failed software approaches to designing an aircraft by starting with some liquid-fuel rockets, a delta wing, and a car, and then designing parts to hook them together. While the individual components may exhibit some desired behavior, the implementation easily becomes impractical because the aircraft was not designed as a system.

Michael J. Lewchuk

IEEE Member

Edmonton, Alta., Canada

Earthly Problems

I appreciate the fascination and enthusiasm for space exploration and exploitation ["A Hoist to the Heavens," August I wish, though, that the study and preservation of Earth's environment could be made equally fascinating and glamorous, so as to induce more people to work on the many problems urgently awaiting solution.

Three of these problems are managing global warming, slowing sea level rise, and providing fresh water. We might consider extracting energy from warm, fast-moving ocean currents to provide electricity to shore grids and floating desalination plants. Power extracted from these warm currents will slow them down and reduce the heat transport to the polar regions. This will help preserve the ice sheets, which reflect solar radiation, and slow the melting that contributes to the rise in sea level. And I hope we will find economical ways to deliver desalinated sea water to where it is needed.

Richard LaRosa

South Hempstead, N.Y.

Fine Lines in Law

In "New Legal Code" [Invention, August], Ben Klemens neglects to note a truly fundamental legal distinction between software and traditionally patentable inventions: since software exists in the realm of information rather than physical reality, software patents encroach on freedom of the press. Examples of this are the Web site designed by Klemens himself, which allegedly infringed software patents, and the hypothetical Word document whose distribution constitutes infringement. There is a clear distinction between describing the production of a drug and actually producing it, but a sufficiently detailed description of an algorithm is indistinguishable from its implementation. We may one day find ourselves in a situation where the mere publication of a software patent in fact infringes that same patent.

Wm. Douglas Withers

IEEE Member

Annapolis, Md.

Readers are invited to comment on material published in IEEE Spectrum and on matters of interest to engineering and technology professionals. Letters do not represent the opinions of the IEEE. Short, concise letters are preferred. The Editor reserves the right to edit letters and limit debate. Contact: Forum, IEEE Spectrum, 3 Park Ave., 17th floor, New York, N.Y. 10016, U.S.A.; fax, +1 212 419 7570; e-mail, n.hantman@ieee.org.