The Old Days

A refreshing concept for software design is being put forth at Praxis High Integrity Systems [Software Report, "The Exterminators," September], but it is nothing new. Years ago that was the way software was developed. Programmers actually designed their programs—remember flowcharts?—and wrote "pseudocode" before ever beginning to write code. Why has that changed?

For the last 20 years, the goal has been to make programming easier and easier by supplying ever more powerful tools—compilers, Visio, programming packages, workbenches, and so on—and by creating higher-level and more abstract languages. Theoretically, these tools should have made the output better, and, used correctly, they would have. Instead, the innovations made programming and coding so easy that literally anyone can write code. Not good code. Not well-structured code or bug-free code—just code.

The horror stories around the various IT projects mentioned in the issue are not surprising. Those projects have all sorts of organizational and logistical problems, but the most telling is that most "programmers" today aren't programmers at all. They are coders. There is a big difference. Praxis knows it, but not too many others do.

Joseph DeCarolis

IEEE Member

San Ramon, Calif.

Stopping the Buck

You list 12 causes of project failure in "Why Software Fails" [September]. In my view, the 10th reason—"poor project management"—is the single overriding reason that projects fail. All the other reasons are subordinate to this one.

For example, at the top of the list is "unrealistic or unarticulated project goals." If the project goals are not realistic or clear, the project manager should notice and have them reformulated. Besides, hasn't anyone heard of the expression, "the buck stops here"?

Several years ago I saw an ad on the Boeing Corp. Web site for a project manager for an airplane design project. Requirements for that position included 15 years of engineering experience, plus related experience in project management and project management training. How many software project managers have that kind of experience? No wonder so many software projects fizzle and so few airplane design projects fail.

Philip Lewis

IEEE Fellow

Stony Brook, N.Y.

Blackout Problem

In my view, "Software Hall of Shame" in "Why Software Fails" had a glaring omission: the 14 August 2003 blackout. The final report of the U.S.-Canada Power System Outage Task Force showed that multiple, independent software failures at both FirstEnergy Corp. and the Midwest Independent System Operator (MISO) played a major role in the blackout.

I was particularly amazed by the statement in that final report that: "In August, MISO considered its state estimator and real-time contingency-analysis tools to be still under development and not fully mature," even though MISO was using these tools to secure the power system in its role as the reliability coordinator for FirstEnergy.

Eric H. Allen

IEEE Member

Albany, N.Y.

Internet Reach

Thank you for highlighting the cabinas públicas, which provide access to the Internet in Peru ["Taking the Internet to the People," October]. It has proven a very useful way for Peruvians to break out of unemployment.

I found it humorous that the article's authors used the example of taxi deregulation ("so that any car could be a taxi") to illustrate the competition level of the cabinas. Lima is one of the few places where taxis are practically deregulated. This has led to very low rates and a poor, dangerous service. Any car can be a taxi, including the Daewoo Tico, which was intended only for transportation inside Daewoo's premises.

Maria Elena Kobayashi

Lima, Peru

All in the Neurons

"Fly Like a Fly" [November] was interesting, but the statement that the fly's "flight control commands originate from only a few hundred neurons in its brain, far less computational might than you'd find in your toaster" is inaccurate. The number of connections is the important variable, not the number of neurons. A neuron is not like a transistor, and the statement disregards that brains are not digital devices, but also rely on analog principles.

Kevin B. Austin

IEEE Member

Fitchburg, Mass.

Author Rafał Żbikowski responds: My point is that the fly hasn't enough computational power to solve the equations of flight. Hence, the fly's control system does not function by using digital calculations as conventional aircraft flight control does. Also, a misprint crept into the article. It should have said that a fly consumes 3 millijoules per second, not 3 joules.