Suppose you were developing software that would run about 50 to 60 operational tasks simultaneously, including the management of multiple mechanical and digital devices. That'd be reasonably complex. Now consider that any time a task stumbled, the software would have to correct itself. That would mean thinking ahead for every possible contingency that could affect all running tasks and designing in self-healing capabilities. That's much more complex.

And by the way, your application will be running on Mars, so on-site service is going to be a bit of a problem.

That's the situation the app dev team for the Phoenix Mars Lander project faced when creating the application set for the spacecraft's mission. And they succeeded in every way.

In case you missed it, over the Memorial Day weekend, NASA's Jet Propulsion Lab engineers and scientists celebrated the soft touchdown of Phoenix on the Red Planet after its 422 million-mile journey. Such landings used to be the norm, but after the Viking 2 Mars landing in 1976, NASA settled craft on our planetary neighbor using airbags, which let a lander roll to a stop. Airbags are less complex and cheaper than soft landings, but they're far less precise in putting your payload where you want it.

Precision was critical for this mission, because Phoenix is looking for the building blocks of life on Mars. Digging randomly in the Martian soil is not good science. Scientists wanted to analyze samples with high concentrations of hydrogen, which presumably could be found locked in water ice beneath the northern arctic plain's surface. Hence the need for the three-point landing.

One other burden that Phoenix's software team had to bear was legacy technology. Peter Gluck, software systems engineer on the Phoenix project, told me that the spacecraft uses a "last of its kind" microprocessor to execute the code -- a radiation-hardened PowerPC chip first used in the Mars Pathfinder launch 11 years ago. Imagine your boss stepping into your cubicle today and asking you to write a state-of-the-art application as complex as Gluck's -- just shy of a million lines of code, Gluck estimates -- and then demanding that the software run on a Pentium Pro microprocessor, the most common chip on the market in 1997. You'd probably quit.

Thank goodness that wasn't the response of Gluck and his team. They worked countless hours to ensure that the software aboard Phoenix would be as flawless as possible. It certainly was integral to the vehicle's pinpoint landing and the successful deployment of the solar panels and the craft's seven-foot retractable arm. It will also be critical to the subsequent data collection and analysis by onboard instruments.

But the real challenge for Gluck and his fellow Phoenix coders was to conceive of all the possible contingencies and how to recover from them. He says there were "thousands we had to plan for." That's hard enough to do on our planet, where you can actually check out the environment where your app will run firsthand. Sure, they had data from other missions to work with, but that's not the same as being there.

The Phoenix software team's ability to plan for things they couldn't witness with their senses strikes me as audaciously creative. It goes beyond implementing the design requirements of rocket scientists -- which they obviously did to perfection -- to imagining scenarios that could stress the code past expectations and still keep it running. To achieve this, the Phoenix's software not only runs the spacecraft and its instrumentation; it is doing double duty by constantly monitoring its own health. The code's not just rock solid; it rocks.

My hat goes off to the entire Phoenix Mars Lander team for their thrilling accomplishment. But I offer an extra tip of my chapeau to the software team that wrote a robust and creative application that, in the long run, will benefit the rest of us earthlings.

Mark Hall is Computerworld 's editor at large. Contact him at mark_hall@computerworld.com.