Applying Lessons from the Vasa to Software
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 at www.vasamuseet.se