How to Save Your Software Project


The software project gone awry is a familiar theme in columns and articles on this site. In this column, Elisabeth Hendrickson uses her knack for observation to draw relevant lessons from seventeenth-century naval history. Read her advice on how to save your project from sinking.

In 1628, the grand warship Vasa launched for her maiden voyage. What started as a ceremonial trot around the harbor ended in disaster. Ten minutes out, the Vasa sank, taking many of those aboard with her.

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.

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 and can be found on Twitter as @testobsessed.

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

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