[kakwa_]

The Mark 14 ended-up being a really good torpedo by the end of WWII.

It even remained in service until the 80ies.

In truth, and going back to this subject, the Mark 14 debacle highlights the need for a good and unbiased QA.

This also holds true for software engineering.

[mrguyorama]

My understanding is the BeuOrd (or BeuShip? I don't remember which) "didn't want to waste money on testing it", so instead we wasted hundreds of them fired at japanese shipping that didn't even impact their target, or never had a hope of detonating.

Remember these kind of things next time someone pushes for move fast and break things in the name of efficiency and speed. Slow is fast.

[kakwa_]

Pre-war, it was more a case of "Penny wise and Pound foolish" partly due to budget limitation (they did things like testing only with foam warheads to recover test torpedoes).

But after Perl Harbor, a somewhat biased BuOrd was reluctant to admit the mark 14 flaws. It took a few "unauthorized" tests and 2 years to fix the issues.

In fairness, this sure makes for an entertaining story (ex Drachinifel video on yt), but I'm not completely sold on the depiction of BuOrd as some sort of arrogant bureaucrats. However, bias and pride (plus other issues like low production) certainly have played a role in the early mark 14 debacle.

Going back to software development, I'm always amazed how bugs immediately pop-up whenever I put a piece of software in the hands of users for the first time, and that's regardless how well I tested it. I try to be as thorough as possible, but being the developer I'm always bias, often tunnel visioning on one way to use the software I created. That's why, in my opinion you need some form of external QA/testing (like these "unauthorized" Mark 14 tests).

[jacquesm]

In NL folklore this is codified as 'the longest road is often the shortest'.