aqua/scope
December 18, 1997
Norvin Leach
MSDN Online News Editor
If you see the new movie Titanic, don't think about software development.
Don't think about those colossal, time-draining projects that met their fate slamming against icy user responses.
Don't think about those beautiful, sleek applications that buckled and sank under the pressures of the real world.
Just enjoy the movie.
When you return to work, though, you might want to think about a couple of things.
Researchers are still trying to figure out exactly how and why the Titanic sank. We know that she hit an iceberg. We know that the plates buckled and the seawater rushed in. But that's about it.
One theory said that the iceberg tore a huge gash in the side of the ship. This has pretty much been disproved, but the actual type of damage is still in doubt. Recent soundings of the wreck suggested that the fractures were much thinner than historians and researchers theorized.
Another theory suggests that the steel was of poor quality because the owner wanted to cut costs. Not many people believe this, but it resonates with popular imagination. People love to hate Bruce Ismay, the managing director of the White Star Line, who just happened to be one of the survivors.
Some believe that the Titanic was improperly designed. Supposedly, the bulkheads were too low, and unable to keep out the water. After the disaster, sister ship Olympic (the Titanic was one of a set of triplets) was refitted with higher bulkheads, giving her effectively a double hull.
But the third sister, the Britannic, already had a double hull, and that didn't save her from sinking when she hit a mine in the Aegean in 1916.
The Americans and the British both held inquiries, but neither was conclusive. The British inquiry, the more thorough of the two, was more concerned with absolving the White Star Line of blame than of finding the truth. In that, it was successful. The villain of the inquiry turned out to be Stanley Lord, captain of the steamship Californian.
In a moment, I'll explain why Lord got branded. First, let's see if all this has any relevance to development.
You've probably gone through software failures before. Do you know why your project failed? I mean really know. Did you trace back all the steps and figure out what was flawed? And then, did you figure out how to correct it?
Perhaps you skipped an area in testing. How will you cover that area in the future?
Perhaps you overestimated the application's ease of use. Does that mean you need more usability testing?
Not enough companies go through thorough postmortems after failures. One large graphics software company won a horrible reputation for bad products when, time after time, their upgrades were plagued with bugs. They never seemed to learn. No, I'm not going to name the company, but you can probably figure it out.
In general, mistakes are unavoidable. The trick is to learn from them, and in order to do that, you need a good postmortem.
A good postmortem focuses on fact-finding, not finger-pointing. It's human nature to assign and shift blame, but that shouldn't be the purpose of your analysis. The purpose should be to correct the problem.
SOS
One of the unanswered questions in the aftermath of the Titanic disaster was whether a nearby ship that ignored the distress flares could have saved more passengers.
There was certainly a ship nearby. Several passengers saw its lights. In fact, the captain of the Titanic thought the other ship was so close that he ordered the lifeboats to row over to it, drop the passengers off, and then return to the Titanic to pick up more passengers.
But the other ship just steamed away, without stopping. The survivors drifted on the sea for hours until a rescue ship reached them.
That other ship, supposedly, was the Californian. In the inquiries, the night watch on the Californian said they saw rocket flares on a distant ship, but Captain Lord told them not to stop to investigate or even radio the other ship. The American and British inquiries both condemned Captain Lord, and the steamship line that owned the Californian forced Lord to resign.
Lord's defenders have long argued that the ship that he saw was not the Titanic. It was a smaller ship, perhaps even an illegal Norwegian sealer. And, for sure, some of the testimony in the inquiries supports this contention.
Nonetheless, Lord's failure to immediately address the problem at hand—going to help a ship that was clearly in distress—was enough to blacken his career.
(At the risk of ruining this nice metaphor, Lord was quickly snapped up by another steamship company and continued his career as a captain without further incident).
So, it's clear that the quality of your tech support can make or break your reputation.
Do you have a tech-support structure in place before your product goes out the door? Have you covered all the peripheral considerations, such as making sure that staffing and phone capacity are sufficient?
It's often better to overanticipate questions and complaints than to leave users hanging on the support line for hours. Do you test your support lines yourself, calling up blindly and asking questions?
Support technicians like to spread horror stories about ignorant users, but the reverse is often true, too. And while ignorant users won't hurt you if they're handled correctly, a rude support technician will.
In summary, it may be impossible to avoid a disaster, but you can buttress yourself against its ill effects, and you can always learn something from it.
Have you sunk anything big lately? Let me know.