Is Your Project a Shipwreck Waiting to Happen?

The Wikipedia article tells it all already, but I will tell you a true story I recently heard from a friend.  This story is about a king, a shipbuilder, and their boat.

Once upon a time King Gustavus Aldophus wanted a boat that would be be the flagship of the Swedish navy, the envy of his fellow kings, and the fear of the 1680s' sea.  Being a king, he issued an order that the ship be built by one Henrik Hybertsson.  Being a micro-manager, Gustavus sent measurements for the ship - after Henrik had already cut the wood.  Being absolutely corrupted by absolute power, he also insisted on heavy Baroque sculptures, two levels of 24-pounder cannons, eight 3-pounder cannons, six howitzers, and ammo for them all.  Extant letters show Henrik objected to the dimensions, but in the end bowed to the government's demands.  We'll never know if the cause was job-related stress, but poor Henrik passed away a year before the ship set sail, leaving the remaining work to his brother.  Work on the ship continued, including tests such as the "run back and forth on the deck to see if we can tump this sucker" test, which only passed 3 laps before worrying the captain enough to stop testing.  Over budget and past the deadlines, King Gustavus sent letter after letter demanding the ship be put to sea, despite the misgivings of the now deceased Henrik and the captain.  The ship set sail, went less than a mile, and at the slightest gust of wind, sank.  

Thus ended the Vasa's military career and began the finger-pointing and blame game, in which the king charged the engineers with "imprudence and negligence" and demanded punishment.  The crew's sobriety and professionalism were questioned in court, and the crew and contractors called to testify. Legend has it that the engineers lost their necks, but history records that the matter fizzled out when the official inquest established that the vessel was built according to the kings' rigid specifications.  Clearly the king could not be implicated, and the official explanation was that the sinking was "an act of God". 

   There are so many ways to look at this, it's hard to know where to start.  The cheapest shots can be aimed at the king - micro-managing and overloading a ship to the point that it was not only useless, but detrimental to the original cause.  How often in software development are features added that ultimately make the application worse than what came before?  Often these feature requests come from pointy-haired ones eager to see their baby endowed with the latest buzzword from their Managers Magazine.  To be fair, developers may also add "cool" features seeking to play with the latest toys or get kudos.  In the end, if communication breaks down, and any one actor insists on their unjustified features, the project may well head to the fishes.

While we're picking on the king, it's worth noting he violated the iron triangle.  It's well established you can have any two sides of the three: Features, Cost, and Time.  By dictating the time and features and cost (the wood was already cut and paid for), something was bound to fail.  In this case, as in most, all three failed.  Had he let one side go - giving more time for tests and adjustments or doling out more cash for extra labor and supplies - the Vasa may have made it further.

Then there's the testability angle.  From the wikipedia article:

In the 17th century, the design requirements and calculations for building a ship only existed in the head of the shipwright. Scientific theories on vessel design or stability had not yet been developed, so important factors like the ship's center of gravity had to be estimated from the builder's experience.

Only in the head of the shipwright, indeed.  Even the most experienced developer can't hold in their head all of the factors that go into designing good software.  In many cases, they can't even know what to start looking for.  Great strides are being made in static analysis engines such as FxCop and ReSharper that let the computer check some code quality for you.  But in the end, the only way to objectively establish that code is Good Code (tm) is to test - unit test, integration test, and acceptance test.  Even with no scientific knowledge of stability, shipwrights through testing did in fact build amazing, large, and stable boats.  Interestingly, the Vasa's captain did run a test, but inexplicably continued on when it failed.  If a project has no tests, or if the tests fail and are ignored, get your life vests ready.

Finally, the blame game.  Funny how some things never change.  Statistics consistently show around a 70% failure rate for IT projects.  Developers blame lack of requirements and micro-managing managers.  Managers blame poor developers who, unlike other engineers, can get a job with little or no certification or licensure (read: "imprudence and negligence").  Both, of course, are right.  There's plenty of blame to go around, and I seriously doubt anybody in the industry is not guilty of contributing to the failure rate.  I have yet, though, to hear of a software bug that I would blame on God, though maybe this would qualify.

In the end, there is plenty for project managers and developers to learn from Gustavus's sinking ship.  After writing this, I ran across Elisabeth Hendrickson's Going Down With the Ship,  which pulls some more interesting insight from the story.  I hope you've enjoyed this naval project management history lesson, and until next time- Trevlig Resa!