"To be honest, I did not think of the waves, because my specialty is earthquakes." --Duty officer, Thai Earthquake Bureau
Disaster management is an unforgiving business. In 1998, Smith Thammasaroj, chief of the Thai Meteorological Department and an electrical engineer by training, publicly predicted that Thailand, which hadn't seen a tsunami in several hundred years, would soon be assaulted by one. When the deluge didn't materialize soon enough for Thammasaroj's superiors, he was fired.
He was replaced by his deputy, Suparerk Tansriratanawong, who was in turn fired some weeks ago for failing to act on information indicating that Thailand, which still hadn't seen a tsunami in several hundred years, might be hit with one as a result of a catastrophic 9.0 quake off the coast of the Indonesian island of Sumatra. Thammasaroj now has his old job back.
Within days of the Indian Ocean tsunami, one of the worst natural disasters in recorded human history, the calls began for the creation of a global tsunami warning system. It would use satellites and computers to cull and analyze data transmitted in real time from thousands of buoys scattered throughout the world's oceans. But little has been said about the most complex and least dependable element of such a system--the human one. After all, no matter how good the electronics are, people will have to make decisions about what to do when the buoys start bobbing. And once they've classified an event as the real thing and not a false positive, they'll have to communicate that information to everyone at risk, from those with a smart cellphone in every pocket to those who have never even seen a phone.
In the tsunami-ravaged resort town of Khao Lak, Thailand, volunteers are using computers with image scanners to create a central database to assist survivors searching for missing family members.
The creation of a deep, well-organized, and responsive human infrastructure to run and maintain any kind of warning system of this complexity is probably the most important and least glamorous part of such a project. With events that occur decades, or centuries, apart, it is difficult to maintain a sense of urgency. And yet without such seriousness of purpose, the entire enterprise is undermined: tidal-wave alerts won't get read while the crisis is unfolding; phone lists and instant-messaging contacts will lapse; and government pressures to keep tourists calm and happy will trump efforts to take looming disasters seriously.
Ways to Help
Though it's not obvious whether we'll ever rely on large-scale technical systems to mitigate future natural disasters, it is clear technology and technical companies and their employees helped make a difference after the tsunami. Microsoft, Dell, and HP were among the first to make large donations. Cisco and BT, among others, sent engineers and communications equipment. Technology professionals will continue to play a central role in the years of recovery that lie ahead. To volunteer your time or expertise, see ReliefWeb�U.N. Office for the Coordination of Humanitarian Affairs (http://www.reliefweb.int).
To mark this month's National Engineers Week (EWeek, 20 to 26 February), IEEE Spectrum is again profiling technologists who have fun at work [see "Dream Jobs 2005"].
Finding 10 engineers with jobs that almost everybody would agree are fun is harder than it looks. Dreams are personal, as Tekla Perry, our dream jobs editor, points out in her introduction to this year's group. Take Craig Nance, for instance: he built telescopes as a child and eventually parlayed his MSEE degree into a job as facilities engineer at an observatory on the Big Island of Hawaii. Victor Zagorodnov, on the other hand, took his MSEE degree and a passion for earth sciences to faraway glaciers and polar ice fields. Would they trade jobs? Probably not.
Given the range of experience represented by our 10 profilees this year, there's bound to be something that strikes your fancy. Or maybe you're already living your dream. If you are, tell us about it--e-mail us at
The editorial content of IEEE Spectrum does not represent official positions of the IEEE or its organizational units. Please address comments to Forum at