How to Save Your Software Project

[article]

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

About the author

Elisabeth Hendrickson's picture Elisabeth Hendrickson

The founder and president of Quality Tree Software, Inc., Elisabeth Hendrickson wrote her first line of code in 1980. Moments later, she found her first bug. Since then Elisabeth has held positions as a tester, developer, manager, and quality engineering director in companies ranging from small startups to multi-national enterprises. A member of the agile community since 2003, Elisabeth has served on the board of directors of the Agile Alliance and is a co-organizer of the Agile Alliance Functional Testing Tools program. She now splits her time between teaching, speaking, writing, and working on agile teams with test-infected programmers who value her obsession with testing. Elisabeth blogs at testobsessed.com and can be found on Twitter as @testobsessed.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09