Tag Archives: testing

Early Problems with Mark 14 Torpedoes

By Kim Smiley

The problems with Mark 14 torpedoes at the start of World War II are a classic example that illustrates the important of robust testing.  The Mark 14 design included brand new, carefully guarded technology and was developed during a time of economic austerity following the Great Depression.  The desire to minimize costs and to protect the new exploder design led to such a limited test program that not a single live-fire test with a production model was done prior to deploying the Mark 14.

The Mark 14 torpedo design was a step change in torpedo technology. The new Mark VI exploder was a magnetic exploder designed to detonate under a ship where there was little to no armor and where the damage would be greatest.  The new exploder was tested using specially instrumented test torpedoes, but never a standard torpedo. Not particularly shocking given the lack of testing, the torpedoes routinely failed to function as designed once deployed.

The Mark 14 torpedoes tended to run too deep and often failed to detonate near the target. One of the problems was that the live torpedoes were heavier than the test torpedoes so they behaved differently. There were also issues with the torpedo’s depth sensor.  The pressure tap for the sensor was in the rear cone section where the measured pressure was substantially less than the hydrostatic pressure when the torpedo was traveling through the water.  This meant that the depth sensor read too shallow and resulted in the torpedo running at deeper depths than its set point.  Eventually the design of the torpedo was changed to move the depth sensor tap to the mid-body of the torpedo where the readings were more accurate.

The Mark 14 design also had issues with premature explosions.  The magnetic exploder was intended to explode near a ship without actually contacting it.  It used small changes in the magnetic field to identify the location of a target. The magnetic exploder had been designed and tested at higher latitudes and it wasn’t as accurate closer to the equator where the earth’s magnetic field is slightly different.

In desperation, many crews disabled the magnetic exploder on Mark 14 torpedoes even before official orders to do so came in July 1943.  Use of the traditional contact exploder revealed yet another design flaw in the Mark 14 torpedoes.  A significant number of torpedoes failed to explode even during a direct hit on a target.  The conventional contact exploder that was initially used on the Mark 14 torpedo had been designed for earlier, slower torpedoes.  The firing pin sometimes missed the exploder cap in the faster Mark 14 design.

The early technical issues of the Mark 14 torpedoes were eventually fixed and the torpedo went on to play a major role in World War II.  Mark 14 torpedoes were used by the US Navy for nearly 40 years despite the early issues.  But there is no doubt that it would have been far more effective and less painful to identify the technical issues during testing rather than in the field during war time.  There are times when thorough testing may seem too expensive and time consuming, but having to fix a problem later is generally much more difficult.  No one wants to waste effort on unnecessary tests, but a reasonable test program that verifies performance under realistic conditions is almost always worth the investment.

To view a high level Cause Map of the early issues of the Mark 14 torpedoes, click “Download PDF”.

You can also learn more about the torpedoes by clicking here and here.

Trading Glitch Loses Goldman Sachs Millions

By Kim Smiley

A Goldman Sachs trading glitch on August 20, 2013 caused a large number of erroneous single stock and ETF options trades.  About 80 percent of the errant trades were cancelled, but the financial damage is still speculated to be as much as one hundred million dollars. The company also finds itself once again in the uncomfortable position of making headlines for negative reasons which is never good for business.

The glitch occurred during an update to an internal computer system that is used to determine where to price options.  The update changed the software so that the system began inadvertently misinterpreted non-binding indications of interest as actual bids and offers.  The system acted on these bids and executed a large volume of trades at errant prices that were out of touch with actual market prices.

This issue can be built into a Cause Map, an intuitive method for performing a root cause analysis.  One of the advantages of a Cause Map is that it visually lays out all the causes and the cause-and-effect relationships between them. Seeing all the causes can broaden the solutions that are considered.

In this example, a Cause Map can help illustrate the fact that the software glitch itself isn’t the only thing worth focusing on.  The lack of an effective test program also contributed to the problem and testing may be the easiest place to implement an effective solution.  If the problem would have been caught in testing, the only cost would have been the time and effort needed to fix the software.  The importance of a robust test program for software is difficult to overstate.  If the software is vital to whatever your company’s mission is, develop a way to test it.

To view a high level Cause Map of this issue, click on “Download PDF” above.  Click here to read about the loss of the Mars Climate Orbiter, another excellent example of a software error with huge consequences.