Kode Vicious - @kode_vicious
PDF
Pride and Prejudice (the Vasa)
A koder with attitude, KV answers your questions. Miss Manners he ain’t.
Dear KV,
I teach computer science to undergraduate students at a school in California, and one of my friends in the English department, of all places, made an interesting comment to me the other day. He wanted to know if my students had ever read Frankenstein and if I felt it would make them better engineers. I asked him why he thought I should assign this book, and he said he felt that a book could change the way in which people think about their relationship to the world, and in particular to technology. He wasn’t being condescending; he was dead serious. Given the number of Frankenstein-like projects that seem to get built with information technology, perhaps it’s not a bad idea to teach these lessons to computer science undergraduates, to give them some notion that they have a social responsibility. Do you agree?
CS Prof
Dear CS,
While I have to agree in general with the idea that telling and retelling stories is a good way to teach people, I have to say that the idea of using Mary Shelley’s novel for this is very much antiquated and unlikely to be effective in a computer science class. I, myself, was once forced through a “Computers and Society” course in college, and although we didn’t read Frankenstein, we were beaten over the head with a litany of how bad computers and technology were for society from a professor who was trivial to manipulate. All I had to do was agree with her every utterance and write technology-bashing essays for her class to get an A. Was this an effective use of time?
Of course not, it was a show. If you really want to reach an audience, you have to engage them with stories that you understand and can relate to their experience. When I think of the kind of story I want to tell to undergraduate students, I think of the Vasa, a ship and story that I think should be better known among engineers.
I first learned of the Vasa from a T-shirt at a conference in 1990. A company that a friend had started used the cross section of the ship to lampoon the ISO OSI effort on network protocols. “Another 7 Layer Model That Failed” read the caption. The connection was that ISO had seven layers and the Vasa had seven decks, but when I found out why the Vasa had tragically failed I became fascinated, because it was such a classic engineering failure story.
The Vasa was built between 1626 and 1628 for King Gustavus Adolphus of Sweden, who was, at that time, attempting to rule the Baltic Sea. In the 17th century, rulers were expected to be capable of more than just giving orders, so Adolphus not only organized wars, he also helped design the ships of his naval fleet. At the time Swedish warships had one deck of cannons on each side from which they fired fusillades at enemy ships, sometimes even hitting and damaging the other ships. When the Vasa was commissioned, this single row of cannons was considered state of the art.
Sometime during the construction of the ship Adolphus found out that the Poles had ships with two decks of guns, so he modified the design of the Vasa to have a second gun deck. This would have made it the most powerful naval vessel of the time, capable of delivering a broadside of devastating proportions. The men he had contracted to build his ships attempted to explain that the ship had too little ballast to support two gun decks, and that the resulting ship would likely be unsafe to sail. The king insisted—just like, say, many project managers—that his orders should be followed. On a software project you can quit, but if the king is your boss you might lose more than your job—you might, say, lose your head—so the project went forward.
In 1628 the ship was finally ready for QA (quality assurance) testing. Seventeenth-century QA of ships was a bit different from what might happen today. Thirty sailors were selected and asked to run back and forth, port to starboard, across the deck of the ship. If the ship didn’t tip over and sink, then the ship passed the test. You did not want to be on the QA team in 1628. After only three runs across the deck, the Vasa began to tilt wildly and the test was canceled. The test may have been canceled, but not the project. This was the king’s ship, after all, and she would sail. And sail she did.
On August 10, 1628, in a light breeze, the Vasa set sail. She was less than a mile from dock when a stiff breeze knocked her sideways. She took on water and sank in full view of thousands of onlookers. Approximately 30 to 50 sailors were killed when they were either trapped in the ship or unable to swim to shore.
In response to the catastrophe, the king wrote a letter insisting that incompetence had been the reason for the disaster. He was, of course, correct, but not in the way he might have envisioned. An inquest was held and the surviving members of the crew, the captain, and the shipbuilders were questioned as to the state of the crew and the ship at the time of the incident. The mostly unstated belief by the end of the inquest was that the design had been a failure and the designer had not listened to the builders about the shortcomings of the design. Of course, the king could not be held at fault, so the final verdict was an “act of God.” As a related aside, the disaster was also a huge economic loss for Sweden.
Now, this story may not be as well written as Frankenstein, but it’s a much more direct warning about engineering failures. I think the funniest, or saddest, part of this story is how modern it is. Nothing has changed since 1628. People still fail to communicate, leading to failures of disastrous proportions. Egos get in the way, and mysterious supernatural forces are blamed for human failings. It’s all kind of obvious in a really sad way.
In the 1960s the Vasa was raised from the bottom of the bay in which it had sunk and eventually placed in a museum in Stockholm. I visited the Vasa in 2000 as part of the SIGCOMM conference. The whole story is told there on plaques hanging on the walls. It’s a museum all engineers ought to visit at least once.
KV
KODE VICIOUS, known to mere mortals as George V. Neville-Neil, works on networking and operating system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are code spelunking, operating systems, and rewriting your bad code (OK, maybe not that last one). He earned his bachelor’s degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. He is an avid bicyclist and traveler who currently lives in New York City.
Originally published in Queue vol. 7, no. 1—
Comment on this article in the ACM Digital Library
More related articles:
Ellen Chisa - Evolution of the Product Manager
Software practitioners know that product management is a key piece of software development. Product managers talk to users to help figure out what to build, define requirements, and write functional specifications. They work closely with engineers throughout the process of building software. They serve as a sounding board for ideas, help balance the schedule when technical challenges occur - and push back to executive teams when technical revisions are needed. Product managers are involved from before the first code is written, until after it goes out the door.
Jon P. Daries, Justin Reich, Jim Waldo, Elise M. Young, Jonathan Whittinghill, Daniel Thomas Seaton, Andrew Dean Ho, Isaac Chuang - Privacy, Anonymity, and Big Data in the Social Sciences
Open data has tremendous potential for science, but, in human subjects research, there is a tension between privacy and releasing high-quality open data. Federal law governing student privacy and the release of student records suggests that anonymizing student data protects student privacy. Guided by this standard, we de-identified and released a data set from 16 MOOCs (massive open online courses) from MITx and HarvardX on the edX platform. In this article, we show that these and other de-identification procedures necessitate changes to data sets that threaten replication and extension of baseline analyses. To balance student privacy and the benefits of open data, we suggest focusing on protecting privacy without anonymizing data by instead expanding policies that compel researchers to uphold the privacy of the subjects in open data sets.
Michael J. Lutz, J. Fernando Naveda, James R. Vallino - Undergraduate Software Engineering: Addressing the Needs of Professional Software Development
In the fall semester of 1996 RIT (Rochester Institute of Technology) launched the first undergraduate software engineering program in the United States. The culmination of five years of planning, development, and review, the program was designed from the outset to prepare graduates for professional positions in commercial and industrial software development.
© ACM, Inc. All Rights Reserved.