Earthdate: October 15, 1997, and the Cassini spacecraft is launched. Mission: to boldly go and explore the planet Saturn.

Saturn is about 10 times farther away from the Sun than the Earth, and to get there required two orbits of the inner solar system, receiving gravitational kicks from Venus and Earth before doing a flyby of Jupiter to get a final assist toward Saturn.

Piggy-backed to Cassini was the Huygens probe that would be dropped onto Saturn's moon, Titan. Unlike most other moons in the solar system that are barren, cratered rocky places, Titan has an atmosphere covering it. The purpose of the probe was to parachute through this, capturing data as it descended onto the planet's surface. The data would be transmitted from the probe up to the Cassini craft, which would act as a relay and transmit back to earth where the experiments' results would be analyzed.

On January 14, 2005, Huygens successfully landed on Titan's surface and provided some fantastic pictures of the moon (www.esa.int/SPECIALS/Cassini-Huygens/index.html). Despite this, there were two major problems on the mission.

The first is that one of the radio channels that the Huygens craft was going to use to transmit data to Cassini failed. The remaining channel was used successfully, although due to this problem only half of Huygen's pictures have come back and some experiments have had all their data lost. The reason for the problem is described as a "software commanding error." The reality is the receiver on Cassini was never programmed to switch on.

The second problem is related to the premise that Huygens transmits its collected data to the Cassini orbiter, which then relays it back to earth. Three years after the launch one of the space agency's employees became uneasy about the fact that this feature hadn't been tested enough in realistic conditions. The story is described in detail at www.spectrum.ieee.org/WEBONLY/publicfeature/oct04/1004titan.html and provides a sobering lesson in the importance of testing. This employee worked hard to convince colleagues and superiors of the importance of testing the link in real conditions, so a simulation was done by sending data from earth to Cassini mid-mission while it hurtled toward Saturn. This mimicked the separation conditions that would be encountered between the craft and Titan and the raw data sent was echoed back to earth by Cassini and analyzed. It showed a fundamental flaw.

Because of the difference in the relative speeds at which Cassini was traveling in space relative to Huygens, there was a Doppler shift. A Doppler shift is when waves are effectively compressed if the receiver and source are moving toward each other and expanded if moving apart. As the wavelength decreases, the frequency increases, meaning that Cassini would have to adjust its listening frequencies to account for its velocity relative to the Huygens transmitter. In addition, the decoding would be affected. Digital data is split into ones and zeros and compared against a base signal to decipher; however, the Doppler shift would stretch and compress the lengths of the payload actual bits in the wave, meaning the digital signal couldn't be analyzed correctly. A fix was required to rescue the $3.26 billion project.

Despite the fact that Cassini's hardware allows its receiver to receive over a range of shifted frequencies, the firmware program was unable to be modified after launch, even though a small fix would have sufficed. The solution they used was to alter the trajectory of Cassini's orbits of Titan so that the craft's approach allowed the radio transmissions to travel perpendicular to its direction of motion, thereby reducing the Doppler shift.

The cost of the two Cassini bugs is huge. Coming down to earth it provokes questions about testing in general. A trait I've encountered at times in my career is for a program to be released knowing it is flawed because the programmer hopes to release the working version in a subsequent fixpack, hopefully before the user has encountered the errant feature. Upgrading releases is easy for developers, but for a user who has to migrate data and schedule business downtime it's frustrating and must contribute to the perception that the latest release is not a set of fully baked features but a rollup of the previous version's fixes bundled with new features that perpetually introduce their own set of bugs.

Good testing is about attitude, where a developer takes pride not just in the elegance or volume of his or her code, but in whether it meets the user's requirements and performs reliably in its first incarnation. I once heard a developer say that releasing buggy code was part of agile programming to allow you to have more cycles of code/release//fix/code. Apart from not grasping the methodology maturely, it showed a basic lack of pride in their work that they were trying to justify. The same excuses can also lead to bloatware, where code is thrown upon code without any tight design or following the basic principles of software engineering. Is the problem that some developers are incapable of taking pride in the complete quality of their work, or that education and teaching, or marketing pressures in a commercial environment still mean that buggy software is released. Next time you release code without proper testing, keep in mind the Cassini programmers who had to physically alter their craft's passage to find a solution. While we might have the next fixpack or release available to us, in space no one can hear your excuses.