You might be thinking, "Thanks for the history lesson, but what does this have to do with software?"

I know something about the sinking of the Vasa because I had the opportunity to visit the Vasa in her home, the Vasamuseet, last year. While there, I spent hours reading the plaques and playing with the computer simulation of her capsizing. That’s when I realized that the Vasa story is being relived today in organizations throughout the software industry.

The Vasa’s is a story of a project gone awry, taking the project team down with it. Some of the contributing factors that led to the Vasa sinking centuries ago will seem terribly familiar to software folks today.

It was an ambitious project. With 64 guns on two gundecks, the Vasa was to be the mightiest warship built to date. Thus it was especially inconvenient that…

The leadership changed mid-project. The original architect, Henrik Hybertsson, died before the project could be completed. His assistant, Hein Jacobsson, took over after his death. Not having the original ship builder see the project through to completion was an even bigger burden than you might imagine because…

There were no detailed plans. At the time the Vasa was built, experienced ship builders used their past experience along with key measurements to guide the ship building process. And then…

Upper management dictated the ship date (literally). King Gustavus Adolphus decreed that the ship must be finished by 21 July 1628 or the shipbuilders would face "His Royal Majesty’s disfavor." Displeasing the king was then, as it is today, a career-limiting move. The king also saw to it that…

There were late-breaking changes in the design. The hull of the mighty war ship was created from four segments of wood. Typical designs at the time involved only three segments of wood, so some archaeologists are guessing that the size of the ship was expanded during construction. Further, the king decreed that there would be two closed gundecks rather than the traditional one, thus allowing more, bigger guns on board. The added weight above the waterline resulted in an instability that was detected when…

The ship failed its acceptance test. One of the final tests that the team undertook was a stability test known as the heeling test. In this test, thirty sailors ran back and forth along the deck to make the ship rock. The test was halted after just three runs because the ship was rocking so badly. The ship builders and the king were not present for the test. Admiral Fleming, the admiral of the Vasa, was present, but seemed unconcerned by the test results. He approved sailing the ship despite her apparent instability. How could someone ignore such dramatic test results? It’s understandable if you consider that…

The cost of failure was too high. So much money had been poured into the Vasa project that failure was inconceivable. By the time the team ran the heeling test, there was little that could be done to change the ship. Having worked on a few software projects with the same characteristics as the Vasa, I can guess that it was easier for the project team to ignore the bad test results than to consider scrapping the entire project.

So what can we learn from this disaster that we can apply to our work in software?

Lesson #1: Break ambitious projects into smaller deliverables. Like many software projects today, the Vasa was a tremendously ambitious project. Although we can’t stop doing ambitious software projects, we can break them up into a series of less ambitious projects. That’s an advantage that software development has over ship building: you can build parts of the system that work independently, then bring them together into a cohesive whole.

Lesson #2: Share knowledge. Henrik Hybertsson was the visionary behind the Vasa. When he died, he left behind a team that was ill equipped to deal without him. We can’t prevent key project people from leaving, but we can mitigate the effects of their leaving by documenting plans and cross-training personnel.

Lesson #3: Manage upward. King Gustavus was accustomed to people doing what he told them to do. While we can’t prevent kings or executives from demanding more features and earlier "ship" dates, we have a responsibility to analyze the implications of their demands and educate them about risks.

Lesson #4: Publish test results, even the bad ones. Those present at the Vasa’s heeling test did not speak of it again until the inquisition following her capsizing. Even then, only the outspoken Captain Hansson had the temerity to bring up the test. No one on the Vasa project team informed King Gustavus of the results of the heeling test before the ship sailed. I wonder if King Gustavus would have allowed the ship to sail if he’d known how unstable she was?

Lesson #5: We can’t stop failure by ignoring risk. As I read the story of the Vasa, it seemed to me that the people on the project team could not admit to themselves that the ship might not be safe. Yet that unwillingness to admit the risks caused even greater loss—loss of life. Ships sink. Software fails. We can’t stop failure through sheer force of will, much as we might like to.

Building the Vasa was a large and complex undertaking, full of risk and challenges. Each decision that contributed to the final disaster no doubt made perfect sense at the time in light of the king’s demands and the political climate.

Ultimately, the story of the Vasa is a tale of human fallibility. The struggles we have with large software projects aren’t new—they’re extensions of the struggles people have had with complex, difficult projects involving new technologies through the centuries. It just happens that software is a ubiquitous new technology, touching every aspect of our lives.

If you would like to learn more about the Vasa, visit the Vasamuseet home page,

http://www.vasamuseet.se

or read

http://dossantos.cbpa.louisville.edu/courses/cis675/vasa/index.htm

a case study highlighting some of the communication and management problems.