Lately, I've been re-reading an old book,
Japanese Aircraft of the Pacific War, by Rene J Francillon. It's about the aircraft the Japanese made during WW2. It's been a number of years since I've read the book, and I find now in it, familiar failure modes that I've encountered while doing software development.
No Plan B
Production of Japanese aircraft dropped steeply between 1944 and 1945. The reasons for this drop were many, including Allied bombing, earthquakes, and other factors. A plan was underway to disperse production away from large centralized plants (easy to hit with bombers) to a more distributed manufacturing basis.
Both the Army and the Navy had decisive battles to win. The Imperial Japanese Navy considered the decisive battle to be coming in June 1944 north of New Guinea; the Imperial Japanese Army thought their decisive battle would be in August 1944 in the Philippines. Until this was accomplished, dispersion [of production] was secondary. The Japanese disregarded all plans for the year and shoved everything towards production. After the peak was achieved (and battles not won), the employees required rest, the machinery was worn out and had to be repaired, parts and supplies were exhausted, and readjustments had to be made. (Francillon, p. 16)
There was no Plan B. When Plan A (win the decisive battles) didn't work out, aircraft production sagged. In software development, we've all experienced what happens after "crunch mode" - whether or not people physically go to work, they are definitely in "not working very hard" mode. People get worn out.
One Size Fits All - the Tachikawa Ki-9
In 1934, the Japanese Army Air Headquarters (Koku Hombu) asked Tachikawa (a manufacturer) to build a single aircraft to serve in two distinct roles - a primary trainer that students would use to get their first flight experience in, and an intermediate trainer that would help a student transition to combat aircraft. The idea is that you build one airframe, put a 150hp engine in to get a primary trainer, or put a 350hp engine in to get the intermediate trainer. Tachikawa was not in favor of this dual-use design, but Koku Hombu noted that various European aircraft designers had solved the problems with the dual-use requirement, so the Tachikawa effort went ahead.
The result? As a primary trainer, the prototype 150hp Ki-9 didn't work well, so it wasn't put into production.
As an intermediate trainer, the 350hp Ki-9 performed a bit better, so Koku Hombu had Tachikawa produce some 2,000 over the 1934-1944 period. The problem was that the center of gravity was too far aft in the 150hp model (engine not heavy enough), and center of gravity was too far forward in the 350hp model (engine too heavy). In a way, Tachikawa was fortunate to get even one of the two models to fly acceptably well - it's clear the design was a compromise that had to span a large range of weights, and probably flew reasonably well in the 350hp model, and poorly in the 150hp model.
As a software person, there are a number of wrong conclusions one could draw from the Ki-9 story: (a) don't compromise (b) "the customer is always right". Sometimes compromise is needed - and sometimes the customer isn't right. In the case of the Ki-9, was the problem that the base requirements were too broad? Was the problem that Tachikawa couldn't solve the dual-use problem (but someone else could)? After all these years, it's hard to say. Part of the difficulty for the Ki-9 was that Koku Hombu could (and often did) select a particular manufacturer to design and build a particular plane, without the use of competitive bids from other manufacturers. A result of this acquisition process is that Koku Hombu got whatever the manufacturer built, even if it wasn't fit for purpose. The 150hp model of Ki-9 was an example where this process failed to yield a good product.
[end of text]
