A horrific shipwreck nearly 400 years ago has lessons for software development teams and leaders today.
Sweden was rising in power and prestige during the reign of King Gustavus Adolphus. He was successful in war, fighting and winning across Northern Europe and Scandinavia. He invaded the Polish-Lithuanian confederacy, driving their armies from the field and forcing them into strongholds which, one by one, he was besieging and capturing.
His navy, however, had problems. He needed to be able to supply his far-flung armies and to do that, he needed to be able to transport arms, food and equipment safely by sea. While he was successful by land, the pesky, defiant enemies kept thwarting him at sea.
In 1625, ten Swedish warships were wrecked in a storm in the Bay of Riga. This was a significant blow as his fleet was already stretched to capacity. He ordered four warships to be built, two large, massive ships and two smaller ones. The greatest of these would be a magnificent warship bearing his family name, Vasa.
She and the other ships would combine to crush all opposition.
The King turned to Sweden’s foremost shipbuilder, Henrik Hybertsson. Hybertsson was born in the Netherlands but had been hired by Karl XI in 1603. He had designed and built many of Sweden’s ships. He was a natural choice.
Designs were prepared, put forth and reviewed. They were tweaked, as designs always are. The greater ships were to be magnificent. They would be the largest and most powerful ships afloat, save for one massive French ship.
To accommodate the number of cannons the King wanted, this would require a radical new design. Notably, it was something never built by anyone outside of France.
There would be two decks carrying the great guns instead of the usual one deck. The Vasa, in particular, would be ornately decorated, with large additions on the front and back of the ship. These “fore” and “stern castles” were commonly used for musketeers and archers to shoot at the crew of enemy ships. That way they could kill or injure as many crew members as possible before coming alongside the enemy and storming from their ship to the enemy ship. Boarding and hand-to-hand combat was still the common way of winning sea battles.
Vasa would be tall. Taller than any ship in Northern Europe. Her “castles” would tower over any ship she might encounter in battle. They would not stand a chance.
Timber was ordered and acquired. The keel, the single massive timber the rest of the ship would be built around, was ready by early 1626. Construction began in March of that year.
With the keel in place in the shipyard, the rest of the ship could get built on it in succeeding layers. Shortly after construction began, the King ordered a total of 72 cannon for her, each capable of firing a 24-pound iron cannonball.
The design was altered slightly to accommodate this. Based on archeological evidence, the lower gun deck was originally intended to handle these large guns. The upper gun deck was intended to handle smaller 12-pound guns. The gun ports, the openings in the side of the ship that opened to allow cannon to fire out of them, were expanded to handle the larger 24-pound guns.
Because of the extra weight, the ship was built slightly wider than intended. It seems the builders believed this would be adequate for the heavier cannon on the upper gun deck.
Even though this was a radically new type of ship, the builders were confident they could successfully deliver the powerful warship.
Scalable build and release management
Because of the disaster in the Bay of Riga, mentioned above, the builders needed to speed construction. They employed two teams working on different sides of the ship. The teams used different measuring systems. One team used Swedish feet of 12 inches, the other team used Amsterdam feet of 11 inches. (Archeologists recovered four measuring sticks from the Vasa, two were in Swedish feet, two were Amsterdam’s feet.)
While this would not become clear until after the ship was launched, it contributed to a growing series of problems and potential problems.
A far greater problem was Master Builder Henrik Hybertsson becoming sick in late 1625. By the summer of 1626, he was unable to work and handed control over to Henrik Jacobsson, another Dutch Master shipbuilder. Hybertsson would not recover and eventually died in the spring of 1627.
While Jacobsson was an able builder, the core of the plans and design were Hybertsson’s. When he took over, Jacobsson oversaw building the ship wider than originally planned (mentioned above.) The ship was widened a total of 1 foot, 5 inches. This was as much as he dared to go as construction was already underway and any greater change would slow it down and cause significant rework.
Vasa was launched in March of 1627. As was usual at the time, and indeed usual for sailing ships until steam power became more common, there was still work to do on her. The main portion of the hull was complete. Still, she did not have masts, rope rigging to support the masts or control the sails, cannon nor the large “castles.” These were all added while she was tied up alongside the pier.
All this would take time. Sails were ordered from abroad. The rope for the rigging came from Riga, Latvia. The cannons were specially made for Vasa at the Royal foundry using new techniques that would reduce the weight of the guns.
In time, the work continued until by early 1628 the King visited the shipyard and went aboard Vasa for the first and likely only time. By the summer of 1628, most of the work was completed. Most, but not all, the cannons were onboard. Some 48 of the massive 24-pound cannons were in place, along with several smaller pieces.
The supplies needed for a sailing ship were stored in the hold and the officers and crew had their possessions on board. She was as close to ready for sea as she could be. One final test remained.
While she was tied up at the pier, 30 members of her crew ran from one side to the other and back to see how much the ship rolled, to test stability. The ship was rocking so much that the test was stopped after they had made only three trips.
Finally, on March 10, 1628, Vasa was moved away from the pier where her “fitting out” was completed. She had some sails set to catch the light winds. Her gun ports were open and the cannons were out. She was to fire a salute as she left Stockholm on her way to the naval base at Alvsnabben.
As she was leaving, a light gust filled her sails and she “heeled” (slight rolling in the direction the wind was blowing) to her port or left, side. The ropes controlling the sails were released. The ship righted herself and came back level.
A short time later, a stronger gust again heeled her to port. This time, she rolled farther than she had the first time. Seawater rushed into the open gun ports flooding the lower gun deck and areas below that deck. The ship sank in 100 feet of water, slightly less than 400 feet from shore.
Survivors clung to debris that floated from the ship while others scrambled up the masts, which were still above the water. Of the 445 officers and crew, 30 died.
The first attempt to raise the Vasa shortly after she sank failed. The technology was not yet advanced to make that a reality. Most of the expensive cannons were recovered through salvage operations in the mid-1660s.
It wasn’t until 1961 that Vasa was raised from the harbor bed where she sank. It was then that archeologists recovered the remains of the last 15 crewmembers in and around the ship.
What similarities are there between Vasa and Software projects? What lessons can we learn even after 400 years?
Be careful when presuming the new technology is something you’re familiar with. A vague resemblance to what you are familiar with might be OK. There can be all sorts of lessons you’ve already learned that can be applied to the new work. The danger is presuming it will be “just like” the old project, only different. Vasa was the largest ship any of the builders involved had ever worked on. They did not know that the second gun deck, even if it was empty of guns, likely would have shifted the center of gravity too high for safety.
Model everything. Wireframes and visual representations can help. Then build a prototype. See if your idea holds up. In the case of Vasa, a scale model, weighted appropriately, might have shown the problems and could have prevented the disaster. Her “sister ship” was built wider than Vasa, after Vasa sank. A model might have shown that the center of gravity was too high. It might also have shown that the ship needed more “bottom.” That is a larger portion of the ship under the waterline.
Vasa had some of the most advanced features of any ship of her age. Presumptions were made that the experts building her were aware of the risks involved. They were not. None of the ideas or beliefs were tested in such a way as to send early warnings. Modeling is a form of early testing.
When you DO test, let all the stakeholders know the results. Particularly if the test goes horribly wrong. The “stability” test showed precisely what would likely happen to Vasa when she was “released to production.” Push the word up, no matter how powerful the stakeholder is. Even at this point in her construction, steps could have been taken to prevent or at least mitigate the disaster that overtook Vasa. Replacing the stone used as ballast at the very bottom of the ship with something heavier would have increased her stability. This was not done.
Delivering hard messages is part of what we do as software development professionals. Always be willing to err on the side of accuracy and fact, not emotion.
These things may not save your next project. Bosses and managers will always be sensitive creatures and not like the message that their favorite project is in danger. Delivering that message is hard and needed. There may be other lessons to draw from this. These are the ones I could easily see. You may find others when you think about this.
Cross-Technology | Cross-Device | Cross-Platform
There are more and more Android testing tools available for mobile app developers. These are our favorites for performance, accessibility, and security.
Regression testing and retesting are essential methodologies testers employ to ensure software quality. If you’re new to both or aren’t sure when to use which technique, this article should help. We’ll discuss the importance of regression testing in software testing. ...
DevOps test automation enables teams to work faster and create better products. These best practices and tools make it easier to implement test automation.
