why the vasa sank: 10 problems and some antidotes for software

1 8 I E E E S O F T W A R E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y 0 7 4 0 - 7 4 5 9 / 0 3 / $ 1 7 . 0 0 © 2 0 0 3 I E E E

After initial salvage attempts, the shipwas largely forgotten until Anders Franzenlocated it in 1956.1 In 1961, 333 years af-ter it sank, the Vasa was raised; it was sowell preserved that it could float after thegun portals were sealed and water andmud were pumped from it. The shelteredharbor had protected the ship from storms,and the Baltic Sea’s low salinity preventedworms from infesting and destroying thewooden vessel. Today it is housed in theVasa Museum (www.vasamuseet.se), nearthe site where it foundered.2 Figures 1 and2 show the restored ship and a recreation ofits sinking.

Researchers have extensively analyzed theVasa and examined historical records con-cerning its construction. It sank, of course,because it was unstable. The reasons it wasunstable, and launched when known to be

unstable, are numerous and varied. Althoughwe may never know the exact details sur-rounding the Vasa, this article depicts our“most probable scenario” based on the ex-tensive and remarkably well-preserved docu-ments of the time, evidence collected duringvisits to the Vasa Museum, information fromthe referenced Web sites, and publications bythose who have investigated the circum-stances of the Vasa’s sinking. The problemsencountered are as relevant to our modern-day attempts to build large, complex soft-ware systems as they were to the 17th-cen-tury art and craft of building warships.

The Vasa storyThe story of the Vasa unfolds as follows.

Changing the shipbuilding ordersOn 16 January 1625, Sweden’s King Gus-

focusWhy the Vasa Sank:10 Problems and Some Antidotesfor Software Projects

Richard E. Fairley, Oregon Health and Sciences University

Mary Jane Willshire, University of Portland

In 1628, the RoyalSwedish Navylaunched the Vasa.After sailing onlyabout 1,300 meters,it sank. The authorsreview the project’sproblems, includingwhy the ship wasunstable and why itwas still launched.They interpret thecase in terms oftoday’s large,complex softwareprojects and presentsome antidotes.

On 10 August 1628, the Royal Swedish Navy’s newest ship set sailon its maiden voyage. The Vasa sailed about 1,300 meters andthen, in a light gust of wind, capsized in Stockholm’s harbor, los-ing 53 lives. The ship was Sweden’s most expensive project ever,

and a total loss. This was a major national disaster—Sweden was at war withPoland and needed the ship for the war effort. A formal hearing the follow-ing month did not determine why the ship sank, and no one was blamed.

process

Authorized licensed use limited to: IEEE Xplore. Downloaded on February 4, 2009 at 16:38 from IEEE Xplore. Restrictions apply.

tav II Adolf directed Admiral Fleming tosign a contract with the Stockholm shipbuilders Henrik and Arend Hybertsson todesign and oversee construction of four ships.Henrik was the master shipwright, Arendthe business manager. They subcontractedwith shipbuilder Johan Isbrandsson to buildthe ships under their direction over a periodof four years. Two smaller ships were tohave about 108-foot keels; the two largerones, about 135-foot keels.

Based on a series of ongoing and confusingchanges the King ordered during the springand summer of 1625, Henrik requested oaktimbers be cut from the King’s forest for two108-foot ships and one 135-foot ship. On 20September, the Swedish Navy lost 10 ships ina devastating storm. The king then orderedthat the two smaller ships be built first on anaccelerated schedule to replace two of the lostships. Construction of the Vasa began in early1626 as a small, traditional ship; it was com-pleted two and a half years later as a large, in-novative ship, after undergoing numerouschanges in requirements.

On 30 November 1625, the King changedhis order, requiring the two smaller ships tobe 120 feet long so that they could carrymore armament: 32 24-pound guns in a tra-ditional enclosed-deck configuration.1 (“24pounds” refers to the weight of the shotfired by the cannon. A 24-pounder weighedapproximately 3,000 pounds.) Henrik inven-toried materials and found that he hadenough timber to build one 111-foot shipand one 135-foot ship. Under the King’s di-rection, as conveyed by Admiral Fleming,Henrik laid the keel for a 111-foot ship be-cause it could be completed more quicklythan the larger one. The records are unclearas to whether the keel was initially laid forthis size or initially for a 108-foot ship andthen extended to 111 feet.

No specifications for the modified keelAfter the Vasa’s 111-foot keel had been

laid, King Gustav learned that Denmarkwas building a large ship with two gundecks. The King then ordered the Vasa to beenlarged to 135 feet and include two en-closed gun decks (see Figure 3). No one inSweden, including Henrik Hybertsson, hadever built a ship with two enclosed gundecks. Because of schedule pressure, theshipbuilders thought that scaling up the

111-foot keel using materials planned forthe bigger ship would be more expeditiousthan laying a new 135-foot keel.

The evolution of warship architecturefrom one to two enclosed gun decks in theearly 1600s marked a change in warfare tac-tics that became commonplace in the late1600s and 1700s. The objective became tofire broadside volleys and sink the oppo-nent. Before that, warships fired initial can-non volleys to cripple their opponent’s shipso that they could board and seize it. To thisend, earlier warships carried large numbersof soldiers (as many as 300).

Although the contract with the Hy-bertssons was revised (and has been pre-served), no one has ever found specificationsor crude sketches for either the 111-foot or135-foot Vasa, and none of the related(and well-preserved) documents mentionssuch drawings. It is unlikely that anyonespent time preparing specifications, giventhe circumstances and schedule pressure un-der which the Vasa was constructed. Theyprobably would not have been prepared for

M a r c h / A p r i l 2 0 0 3 I E E E S O F T W A R E 1 9

Figure 1. The restoredVasa, housed inStockholm’s VasaMuseum (model inforeground, Vasa inbackground).


the original 108-foot ship, because thesetypes of ships had been routinely built formany years and Hybertsson was an experi-enced shipwright, working with an experi-enced shipbuilder. Henrik Hybertsson prob-ably “scaled up” the dimensions of theoriginal 108-foot ship to meet the length andbreadth requirements of the 111-foot shipand then scaled those up for the 135-footversion of the Vasa.

How he scaled up the 111-foot Vasa to

135 feet was constrained by its existingkeel, which contained the traditional threescarfs. He added a fourth scarf to lengthenthe keel, but the resulting keel is thin in re-lation to its length, and its depth is quiteshallow for a ship of this size.

Hybertsson’s assistant, Hein Jacobsson,later said that the Vasa was built one foot,five inches wider than originally planned toaccommodate the two gun decks. However,the keel was already laid, so they couldmake that change in width only in the upperparts of the ship. This raised the center ofgravity and contributed to the Vasa’s insta-bility (sailing ships are extremely sensitiveto the location of the center of gravity; a fewcentimeters can make a large difference).Also, those outfitting the ship for its firstvoyage found that the shallow keel did notprovide enough space in the hold for theamount of ballast needed to stabilize a 135-foot ship. The keel’s thinness required extrabracing timbers in the hold, further restrict-ing the space available for ballast.

Shifting armaments requirementsThe numbers and types of armaments to

be carried by the scaled-up Vasa went througha number of revisions. Initially, the 111-footship was to carry 32 24-pound guns. Then,the 135-foot version was to carry 36 24-pound guns, 24 12-pound guns, eight 48-pound mortars, and 10 smaller guns. Aftera series of further revisions, the Vasa was tocarry 30 24-pounders on the lower deckand 30 12-pounders on the upper deck. Fi-nally, the King ordered that the Vasa carry64 24-pound guns—32 on each deck—plusseveral smaller guns (some documents statethe required number as 60 24-poundguns).

Mounting only 24-pound guns had the ad-vantage of providing more firepower and al-lowed standardization on one kind of ammu-nition, gun carriage, powder charge, andother fittings. However, the upper deck had tocarry the added weight of the 24-pound gunsin cramped space that had been built for 12-pound guns, further raising the ship’s centerof gravity. In the end, the Vasa was launchedwith 48 24-pound guns (half on each deck),because the gun supplier’s manufacturingproblems prevented delivery of more guns onschedule. Waiting for the additional gunswould have interfered with the requirement

2 0 I E E E S O F T W A R E h t t p : / / c o m p u t e r. o r g / s o f t w a r e

Figure 2. A recreation of theVasa disaster. (photo by Hans Hammarskiöld)

Figure 3. The Vasa’stwo gun decks.


to launch the ship as soon as possible. An-other indication of excessive schedule pres-sure is that the gun castings were of poorquality. They might well have malfunctioned(exploded) during a naval battle.

Artisan shipbuilders constructed theVasa’s rigging and outfitting without ex-plicit specifications or plans, in the tradi-tional manner that had evolved over manyyears. The King ordered that the ship beoutfitted with hundreds of ornate, gilded,and painted carvings depicting Biblical,mythical, and historical themes (see Figure4). The Vasa was meant to impress by out-doing the Danish ship being built; no costwas spared, making the Vasa the most ex-pensive ship of its time. However, the heavyoak carvings raised the center of gravity andfurther increased instability.

The shipwright’s deathHenrik Hybertsson became seriously ill

in 1626 and died in 1627, one year beforethe Vasa was completed. During the year ofhis illness, he shared project supervisionwith Jacobsson and Isbrandsson, but ac-cording to historical records, project man-agement was weak. Division of responsibil-ity was not clear and communication waspoor; because there were no detailed speci-fications, schedule milestones, or work plans,it was difficult for Jacobsson to understandand implement Hybertsson’s undocumentedplans. Communication among Hybertsson,Jacobsson, and Isbrandsson was poor. Thisresulted in further delays in completing theship.

Admiral Fleming made Jacobsson (Hy-bertsson’s assistant) responsible for complet-ing the project after Hybertsson’s death. Atthis time and during the subsequent year, 400people in five different groups worked on thehull, carvings, rigging, armaments, and bal-lasting—apparently with little, if any, com-munication or coordination among them.This was the largest work force ever engagedin a single project in Sweden up to that time.There is no evidence that Jacobsson preparedany documented plans after becoming re-sponsible for completing the ship.

No way to calculate stability, stiffness, orsailing characteristics

Methods for calculating the center ofgravity, heeling characteristics, and stability

factors for sailing ships were unknown, soships’ captains had to learn their vessels’operational characteristics by trial-and-error testing. The Vasa was the most spec-tacular, but certainly not the only, ship tocapsize during the 17th and 18th centuries.

Measurements taken and calculations per-formed since 1961 indicate that the Vasa wasso unstable that it would have capsized at aheeling over of 10 degrees; it could not havewithstood the estimated wind gust of 8 knots(9 miles per hour) that caused the ship to cap-size.3 Recent calculations indicate the shipwould have capsized in a breeze of 4 knots.

That the wind was so light during the Vasa’sinitial (and final) cruise is verified by thefact that the crew had to extend the sailsby hand upon launch. Lieutenant PetterGierdsson testified at the formal inquiryheld in September 1628: “The weather wasnot strong enough to pull out the sheets, al-though the blocks were well lubricated.Therefore, they had to push the sheets out,and one man was enough to hold a sheet.”4

During the formal inquiry, several wit-nesses commented that the Vasa was “heav-ier above than below,” but no one pursuedthe questions of how and why the Vasa hadbecome top-heavy. No one mentioned theweight of the second deck, the guns, thecarvings, or other equipment. In those days,most people (including the experts) thoughtthat the higher and more impressive a war-ship, and the more and bigger the guns itcarried, the more indestructible it would be.


Figure 4. The ship’sornate, gilded carvings.


The failed prelaunch stability testCaptain Hannson (the ship’s captain) and

a skeleton crew conducted a stability test inthe presence of Admiral Fleming during out-fitting of the Vasa. The “lurch” test con-sisted of having 30 men run from side toside amidship. After three traversals by themen, the test was halted because the shipwas rocking so violently it was obvious itwould capsize if the test were not halted.The ship could not be stabilized becausethere was no room to add ballast under thehold’s floorboards (see Figure 5). In anycase, the additional weight would haveplaced the lower-deck gun portals near orbelow the ship’s waterline. The Vasa was es-timated to be carrying about 120 tons ofballast; it would have needed more thantwice that amount to stabilize.

That the Vasa was launched with knownstability problems was the result of poor com-

munication, pressure from King Gustav tolaunch the ship as soon as possible, the factthat the King was in Poland conducting a warcampaign (and thus unavailable for consulta-tion), and the fact that no one had any sug-gestions for making the ship more stable.

Testimony at the formal hearing indi-cated that Jacobsson, the shipwright, and Is-brandsson, the shipbuilder, were not presentduring the stability test and were unawareof the outcome. The boatswain, Matsson,testified that Admiral Fleming had accusedhim of carrying too much ballast, notingthat “the gunports are too close to the wa-ter!” Mattson then claimed to have an-swered, “God grant that the ship will standupright on her keel.” To which the Admiralreplied, “The shipbuilder has built ships be-fore and you should not be worried.”4

Whether Admiral Fleming and CaptainHannson intentionally withheld the stabil-ity test results is a matter for speculation.The King had ordered that the Vasa beready by 25 July and “if not, those respon-sible would be subject to His Majesty’s dis-grace.” The Vasa’s maiden voyage on 10 Au-gust was more than two weeks later. It wasreported that after the failed stability test,Admiral Fleming lamented, “If only the Kingwere here.”5

Ten problem areas and theirantidotes

Many of the Vasa project’s problemssound familiar to those who have grappledwith large software projects. Table 1 pres-ents 10 problems from the Vasa project thatare also common to software projects, alongwith some antidotes for software projects.

1. Excessive schedule pressureMany software projects, like the Vasa proj-

ect, are under excessive schedule pressure tomeet a real or imagined need. According toFred Brooks, more software projects havefailed (“gone awry”) for lack of adequatecalendar time than for all other reasonscombined.6 Excessive schedule pressure insoftware projects is caused by

� Truly pressing needs� Perceived needs that are not truly pressing� Changing of requirements without ad-

justing the schedule or the resources (seeProblem 2)


Table 1Ten software project problems and some antidotesProblem area Antidotes

1. Excessive schedule pressure Objective estimatesMore resourcesBetter resourcesPrioritized requirementsDescoped requirementsPhased releases

2. Changing needs Iterative developmentChange control/baseline management

3. Lack of technical specifications Development of initial specificationsEvent-driven updating of specificationsBaseline management of specificationsA designated software architect

4. Lack of a documented project plan Development of an initial planPeriodic and event-driven updatingBaseline management of the project planA designated project manager

5. & 6. Excessive and secondary innovations Baseline controlImpact analysisContinuous risk managementA designated software architect

7. Requirements creep Initial requirements baselineBaseline managementRisk management A designated software architect

8. Lack of scientific methods PrototypingIncremental developmentTechnical performance measurement

9. Ignoring the obvious Back-of-the-envelope calculationsAssimilation of lessons learned

10. Unethical behavior Ethical work environments and work culturesPersonal adherence to a code of ethics


� Unrealistic schedules imposed on projectsby outside forces

� Lack of realistic estimates based on ob-jective data

When schedule estimates are not based onobjective data, software engineers have nobasis for defending their estimates or for re-sisting imposed schedules. You can sometimesmeet schedule requirements by increasingproject resources, applying superior re-sources, descoping the (prioritized) require-ments, phasing releases, or some combina-tion of these antidotes.

2. Changing needsSome common reasons for changes to

software requirements include competitiveforces (as in the case of the Vasa), user needsthat evolve over time, changes in platformand target technologies, and new insightsgained during a project. There are two tech-niques for coping with changing softwarerequirements:

� Pursuing an iterative development strat-egy (for example, incremental, evolu-tionary, agile, or spiral)

� Practicing baseline management

You can use these techniques alone or to-gether. In the case of iterative development,you can accommodate requirements changesbased on priority within the constraints oftime, resources, and technology—any ofwhich you can adjust as the project evolves.When using baseline management, you ini-tially place the requirements under versioncontrol. Approved changes result in a newversion of the requirements (a new base-line), which is accompanied by adjustmentsto schedule, resources, technology, andother factors as appropriate. The goal ofboth approaches is to maintain, at all times,a balance among requirements, schedule,resources, technology, and other factorsthat might pose risks to successful deliveryof an acceptable product within the projectconstraints.

3. Lack of technical specificationsSoftware projects, like the Vasa project,

sometimes start as small, familiar activitiesfor which technical specifications aredeemed unnecessary. These projects often

grow to become large, innovative ones. Inthe Vasa’s case, verbal communicationmight have compensated somewhat for thelack of written specifications and a writtenproject plan. In the case of software proj-ects, initially developing and baselining re-quirements, even for a small, simple proj-ect, is much easier (and less risky) thantrying to “reverse-engineer” requirementslater, when the project has crossed a com-plexity threshold that warrants developingtechnical specifications.

4. Lack of a documented project planBecause its designers saw the Vasa as a

small, familiar ship and because the projectteam was experienced in building thesetypes of ships, they might have thought sys-tematic planning was an unnecessary use oftime and resources. Software projects oftenstart under similar circumstances. As in thecase of requirements, evolving a baselinedproject plan for an initially small project ismuch easier than trying to construct a proj-ect plan later (when there is no time to doso). A software project plan must include

� Decomposition of the work to be done(that is, a work breakdown structure)

� Allocation of requirements to the workelements of the WBS

� An allocated schedule (for example, amilestone chart)

� Allocation of resources to each scheduleincrement

� Deliverable work products for eachschedule increment


Figure 5. A cross section of the Vasashowing its shallowkeel and its multipledecks, including thetwo gun decks.


� Plans for acquiring software from ven-dors and open sources

� Plans for managing subcontractors� A risk management plan� A clear statement of authorities and

responsibilities7

You can document the project plan for asmall software project in a few pages andthen expand it as the project grows.

5. Excessive innovationIn To Engineer Is Human, Henry Pet-

roski observes that engineering projectsoften fail when people attempt innova-tions beyond the state of the art.8 Softwareprojects are always innovative to some ex-tent because replicating existing software,unlike replicating physical artifacts, is a triv-ial process. Software projects are conductedto develop new systems “from scratch” andto produce new versions of existing systems,but not to replicate software. To control ex-cessive innovation in software projects, youcan apply the following techniques:

� Baseline control of working documents(for instance, requirements, project plans,design documents, test plans, andsource code)

� Impact analysis of proposed changes� Continuous risk management

6. Secondary innovationsReasons for secondary innovations in

software projects include the need to ac-commodate the constraints of the technolo-gies used, the addition of derived require-ments to support primary requirements andchanges to them, and innovations based onthe developers’ creative impulses. As in theVasa’s case, these secondary requirementscan overwhelm a software project. In addi-tion to the techniques mentioned for con-trolling Problem 5, you should assign re-sponsibility and give authority to a designatedsoftware architect to maintain the softwareproduct’s vision and integrity, which is an ad-ditional antidote for many other problems.7

7. Requirements creepIt seems that no one was aware of the

overall impact of the changes made to theVasa during the two and a half years of con-struction. This can (and does) easily happen

to software projects. Fundamental techniquesfor maintaining control of software projectsare developing initial documentation andconsistently updating requirements andplans to maintain an acceptable balanceamong requirements, schedule, and resourcesas the project evolves. Often-heard excusesfor failure to establish initial project docu-mentation are lack of sufficient knowledgeto do so and the belief that “everything willchange anyway, so why plan?” You shoulddevelop initial requirements and plans tothe extent possible in the face of imperfectknowledge, with the expectation that theywill change and with procedures in place toevolve them systematically. Failure to updateinitial requirements and plans periodically, andas events require, is often the result of a per-ception that there is not enough time to doso (“never enough time to do it right, but al-ways time to redo it”). This perception, inturn, comes from insufficient procedures formanaging requirements and plans on a con-tinuing basis and a lack of appreciation forthe risks thus created.

8. Lack of scientific methodsBecause software has no physical proper-

ties, you cannot calculate many traditionalengineering parameters for software (atleast, at this time). Unlike physical artifactssuch as the Vasa, however, you can build asoftware system in small, incremental stepsand monitor the evolution of technical pa-rameters such as memory usage, perform-ance, safety, security, and reliability as thesystem evolves.

9. Ignoring the obviousIn the case of the Vasa, the lurch test

demonstrated that the ship was dangerouslyunstable. There was no room for additionalballast. If there had been room, the addedweight would have placed the lower gunportals below the waterline. Although welack scientific methods in many software en-gineering areas, we can often avoid foresee-able disasters by performing a few, oftenquite simple, “back of the envelope” calcu-lations. If, for example, a certain transac-tion processing system must process 1,000transactions per second and if each transac-tion requires four complex queries, the sys-tem must process 4,000 complex queries persecond, including the time required for con-

In modernsociety, the roleof engineeringis to providesystems andproducts thatenhance the

materialaspects of

human life, thusmaking life

easier, safer,more secure,

and moreenjoyable.



text switching among transactions (that is,250 microseconds per context switch andtransaction). Accounting for system laten-cies might show the envisioned system to beinfeasible.

10. Unethical behaviorIn modern society, the role of engineering

is to provide systems and products that en-hance the material aspects of human life,thus making life easier, safer, more secure,and more enjoyable. Technological innova-tion often involves ethical considerations. Inthe Vasa’s case, the goal was to make Swe-den more secure for its citizens and to bringglory to the country. At the last moment,when it became obvious the ship was notseaworthy, those with authority to stop thelaunch did not do so.

In our time, software engineers shouldfirst serve the public; second, be advocatesfor the customers and users of their prod-ucts; and third, act in the interest of theiremployers, in a manner that is consistentwith the public interest. Software engineersshould “accept full responsibility for theirwork” and “approve software only if theyhave a well-founded belief that it is safe,meets specifications, passes appropriatetests, and does not diminish quality of life,diminish privacy, or harm the environment.The ultimate effect of the work should be tothe public good.”9 Every software engineershould be familiar with and adhere to acode of ethics.

T able 1 presents only some of themany possible antidotes for soft-ware projects. Some antidotes listed

in one problem area apply equally to otherproblem areas. For the sake of brevity, weleave elaboration of Table 1 to readers.

According to the formal Vasa hearing’stranscript, no one asked how or why theship had become unstable or why it waslaunched with known stability problems.The failure of this line of inquiry is perhapsthe most compelling problem from the Vasacase study, as is our often-observed, present-day failure to learn from our mistakes insoftware engineering.

On a positive note, large, two-deck war-ships were subsequently built and sailedduring the latter 17th and the 18th and 19thcenturies. In the same way, we can now,with reasonable confidence of success, buildlarger and more complex software-intensivesystems than in the past.

AcknowledgmentThe reviewers and editor offered many valuable

recommendations for improvements to this article’sinitial draft. Photos by permission of the Vasa Museum.

References1. A. Franzen, The Warship Vasa: Deep Diving and Ma-

rine Archaeology, 6th ed., Norstedt & Soners Forlag,Stockholm, 1974.

2. The Royal Ship Vasa, http://home.swipnet.se/~w-70853/WASAe.htm.

3. C. Borgenstam and A. Sandstrom, Why Vasa Capsized,AB Grafisk Press, Stockholm, Sweden, 1995.

4. The Story of the Royal Swedish Man-of-War Vasa, multi-media documentary, VyKett AB, Stockholm, Sweden,1999; available (in English) on floppy disk by email in-quiry to the Vasa Museum at [email protected].

5. A. Wahlgren, The Warship Vasa, a documentary film,Vasa Museum, Stockholm, Sweden, 1996; available (inEnglish) on a VCR tape by email inquiry to the VasaMuseum at [email protected].

6. F. Brooks, The Mythical Man-Month, Addison-Wesley,Boston, 1995.

7. IEEE Std. 1058-1998, Standard for Software ProjectManagement Plans, IEEE, Piscataway, N.J., 1998.

8. Henry Petroski, To Engineer Is Human: The Role ofFailure in Successful Design, Vintage Books, New York,71992.

9. Software Engineering Code of Ethics and ProfessionalPractice, IEEE Computer Society and ACM Joint TaskForce on Software Engineering Ethics and ProfessionalPractices, 1999, http://computer.org/tab/code11.htm.

For more information on this or any other computing topic, please visit our Digital Library at http://computer.org/publications/dlib.


About the Authors

Richard E. Fairley is a professor of computer science and associate dean of the OGISchool of Science & Engineering of the Oregon Health & Science University. He also participatesin the Oregon Master of Software Engineering program, which is offered collaboratively byfour Oregon universities. His research interests include requirements engineering, software ar-chitecture, software process engineering, estimation, measurement and control of softwareprojects, risk management, and software engineering education. He is a member of the IEEEComputer Society and ACM. Contact him at the OGI School of Science and Eng., 20000 NWWalker Rd., Beaverton, OR 97006; [email protected].

Mary Jane Willshire is an associate professor of computer science in the ElectricalEngineering and Computer Science Department at the University of Portland, where sheteaches courses and conducts research in software engineering, human-computer interfaces,and database technology. She is a member of the IEEE, ACM, Association for Women in Sci-ence, and Society of Women Engineers. Contact her at the School of Engineering, Univ. of Port-land, 5000 N. Willamette Blvd., Portland, OR 97203-5798; [email protected].


why the vasa sank: 10 problems and some antidotes for software

Documents