The Community for Technology Leaders

High-Tech Disasters


Pages: pp. 3-5

By the time this issue comes out, every reader will be familiar with the devastation inflicted by Hurricane Katrina on the Gulf Coast of the United States. Even though the victims' pain and suffering are certainly no worse than that borne by victims of any natural or man-made disaster, this particular disaster is notable for two reasons.

First, seldom has a major city anywhere in the world been destroyed, for all intents and purposes, over a couple days. It's rare enough that these events often become legends such as Pompeii and Atlantis. But second, this may well be the first "high-tech" disaster in history, and that makes it particularly relevant to IEEE Software readers. Computing is playing an unparalleled role in coping with the aftermath.

Getting aid

With almost two and a half million people in the areas most severely damaged by the storm, the number of people who need emergency assistance is overwhelming—so much so that the traditional way of doing business simply isn't tractable. Let's say 500,000 families need emergency financial assistance to get new places to live and start their lives over; these needs are time-critical. In 1995 (or even 2000, for that matter), these half million families would have either filled out paper applications or given their information to an agency representative by telephone. How long would it take to process half a million applications? It's hard to say, but "quite a while" would probably be a safe guess.

In 2005, the US Federal Emergency Management Agency is encouraging Katrina's victims to submit their applications for assistance online using its Web site ( Of course, as Jim Rapoza points out in the 9 Sept. 2005 issue of (,1895,1857300,00.asp), it's a Microsoft-only world. In fact, the FEMA Web site tells us, "Currently to complete your application online you must be using Microsoft's Internet Explorer 6.0 or above." This is a hard requirement—if you try to visit the site using another browser like Firefox, you get kicked out with a message reminding you that you need to use Internet Explorer. While FEMA thoughtfully provides a link to download IE 6.0, if you're using Linux or a Macintosh, you're (again) out of luck. Prepare to spend a while listening to Musak on FEMA's toll-free phone line. FEMA no longer accepts hard-copy applications for assistance, so it's either the computer or the phone.

Finding loved ones

While some displaced families are trying to get back on their feet, others are just trying to get back together. One tragic aspect of a large-scale evacuation is that family members often get separated. Mom goes off in one helicopter while Dad and the kids go off in a rescue boat. Where and when they'll see each other next is anyone's guess. As a parent, I can't imagine anything worse than being separated from my children under these circumstances and not knowing where they are.

Computing is playing a vital role in trying to get these families back together. With hundreds of thousands of displaced families, this job simply could not be done manually. The International Committee of the Red Cross's Family-Links Web site ( is a good example of such a service. People have used this site for years to reconnect family members separated by disasters and wars. Another service provided by volunteers from Microsoft is called KatrinaSafe ( The National Next of Kin Registry ( is another site that provides a similar service. At least 30 other Web sites also help survivors reconnect with loved ones.

Given many of these sites are individual efforts that were hastily put up specifically to support the victims of Katrina, it should not be surprising that there is little coordination between them. But the result of this is that victims may have to visit dozens of individual sites looking for their loved ones. To date, I haven't encountered any metaengines that facilitate searching all the sites with a single inquiry. But this does suggest a need that should be addressed before the next disaster strikes.

Getting access

Of course, with all these services online, it's just as important to get the client hardware on the ground so that victims can access them. One of the more novel solutions to this problem is Steve Hargadon's public Web Stations project ( His version of a Web station is a Linux-based computer that boots directly into the Firefox browser and a special homepage with links to services that evacuees might find useful, with the notable exception of the FEMA Registration system because of its Internet Explorer requirement. Because of a dedicated Web station's modest hardware requirements, otherwise obsolete Pentium II machines—just the kind that are taking up space in many people's closets and basements—can easily support them.

Imagine having mobile Web stations set up in the back of donated cargo trucks equipped with small generators and satellite Internet access that can visit shelters within hours, rather than delaying access to these resources for days or weeks.

The next one

I sincerely hope that by the time this issue goes to press (I'm writing this in September), Katrina's victims will no longer need these services. But somewhere in the world, sometime, we'll need these services again. Another hurricane, earthquake, or tsunami will bring suffering and heartache to hundreds, thousands, or millions—as they have before.

As with Katrina, the aftermath must be attacked with Internet connectivity as well as bulldozers.

It would certainly be nice if the infrastructure existed so that along with the bottled water, ready-to-eat military meals, and bulldozers, access to these sorts of services were quickly available to victims, instead of being hastily cobbled together in a catch-as-catch-can manner.

What you can do

Almost everyone in the software community can make a unique contribution to better prepare society to respond to such events. I challenge you to think of what types of services future victims of natural disasters like Katrina might need, and how you can help make sure those services are in place before they're needed. And then take the next step—actually build those services.

And once disaster does strike, computing services will play a special role in disaster recovery, now and in the future. There will be as great a need for docents to help victims use the technology as there will be for volunteers to hand out water and blankets. Public agencies will likely need help restoring infrastructure—everything from police services to road repair is computer dispatched—and things won't get back to normal until the computers are working and the data is recovered.

Just as it's important to have the technology before it's needed, prepare to volunteer before you're needed. Join with friends and colleagues to organize and train. Find out your employer's policies. Discuss these issues with your family. Find opportunities locally to keep your skills sharp. Make your capabilities known at the National Emergency Resource Registry ( or your country's equivalent.

Volunteer your time and your skills— you'll be glad you did. As Winston Churchill said, "We make a living by what we do, but we make a life by what we give."

Feedback welcome

I'd like to learn of volunteer initiatives involving hardware and software skills that our readers have been involved in. We would especially like to learn about reputable international organizations that are cognizant of the unique contributions that high-tech volunteers can make. Please write me at

A Heartfelt Farewell

This issue features the last Design column edited by Martin Fowler. After five years of being responsible for the column, Martin has decided to move on to other projects that he had put on hold. His first column appeared in the January 2001 issue of IEEE Software, and it's regularly been a favorite among readers. During this period, the column has appeared 28 times, including pieces from both outstanding guest columnists such as Craig Larman, Kent Beck, John Daniels, James Newkirk, Alexei Vorontsov, Rebecca Parsons, Luke Hohmann, Jim Shore, Dave Thomas, Robert Martin, Scott Meyers, Michael Feathers, and Gregor Hohpe, as well as Martin's own original content. Martin's contributions as editor of the Design column will be sorely missed. Thank you, Martin, for all you've done for the magazine and the profession.

However, the Design column won't be going away! Martin will hand the baton off to Rebecca Wirfs-Brock, who will begin editing the column in the January/February 2006 issue. Rebecca is a coauthor of Designing Object-Oriented Software (Prentice Hall, 1990) and Object Design: Roles, Responsibilities, and Collaborations (Addison-Wesley, 2003).

Goodbye, Martin; hello, Rebecca!

65 ms
(Ver 3.x)