Originally Posted by
gtae07
The F-35 is a prime example of why people who know jack, shit, and fuck all about developing complex projects like modern aircraft do not need to have access to every development detail and report about “problems”. Because you see, every single program has problems. Every one. Apparently people seem to think that “well, now we have computers, and so everything ought to be perfect the first time around and if there’s any kind of issue at all it’s an indication that there are fundamental implementation problems with program-level implications and a sign that the designers are totally incompetent”. Yet, computer modeling is by no means a catch-all omniscient science.
For example, take cracks on a fatigue test article. They are going to be there, and if you aren’t finding them, that’s a problem because it means you either aren’t looking hard enough, you aren’t testing right, or you are way overbuilt. Every fatigue article ever tested had cracks. You test so you can learn where they’re likely to be and you figure out how to address them.
Avionics integration is similar. No matter how thorough you think you have been with your documentation and devvelopment, the first time you hook all your boxes up together to test them, it isn’t going to work. And then you’re going to find bugs and failure modes you never anticipated. That’s why you test.
The second problem is that people in the above-mentioned categories do not understand why the F-35 was designed the way it was. They read that the F-35 is supposed to replace the F-16, which was originally conceived as a super-simple lightweight visual-range day-VFR dogfighter that could outmaneuver everything else in the sky, and they then think the F-35 should thus be the super-duper-uber-dogfighter that can twist and turn and dodge and outmaneuver the F-16 for a visual-range guns kill, because we all “knnow” from Vietnam that missiles are useless and all air-to-air engagements in the future will be visual-range guns kills. But they forget that what made the F-16 so successful was not extreme maneuverability. Rather, it was adding all the “useless stuff” like a capable radar, improved avionics, targeting pods, radar missiles, guided bombs, etc. that made it so useful to the US and foreign air forces.
Basically, a lot of people look at the list of aircraft the F-35 is supposed to “replace” and expect it to do the original jobs of those airplanes the way they were originally conceived to do them—all at the same time. They thus expect a super-duper-uber dogfighter carrying a gigantic gun and stacks of armor that can hunt tanks in the weeds with a fixed gunsight, and simultaneously take off vertically with a Mudhen’s payload while keeping up with an F-22. It’s ridiculous. Frankly, it looks a lot more like someone sat down to rationally figure out “what jobs are all of these airplanes actually dooing, and how can we do them better”—and what you get is an airplane that can sneak around with loads of gas, a decent payload, God-mode situational awareness, and enough maneuverability to at least hold its own.
Third, it really points out the folly of “cost estimation”—or more accurately, the idea that somehow the budget and schedule forecasts of people who aren’t doing the work, regarding things that we haven’t done and don’t yet know how to do, somehow represent actual reality; and when the actual execution of doing those things doesn’t match the forecast, it’s reality that’s wrong. The accuracy of any cost estimate is inversely proportional to the maturity level of the thing being developed. The Super Hornet was on-schedule and on-budget because it wasn’t anything new—there wasn’t really any new technology challenge. The F-35 had a whole bunch of new stuff that hadn’t been done before, at least outside of a lab.
Finally, on the subject of “being put into production long before it should”. Frankly, the idea that you can build a handful of test airplanes, then shut the line down for years (or a decade) and test your handful of test planes, and then think that you’ve caught every bug and every problem and have a completely and totally ready airframe, then turn a key and start cranking out totally ready airplanes at full rate, is laughable. Hardware isn’t software. Starting production at a low rate, like the F-35 and pretty much every other modern military or commercial aircraft, provides you with several advantages. It allows you to work through your production processes (which have to be debugged just like the design itself) and start finding opportunities to optimize the process early, not to mention fixing small design issues at a low rate. It gets early models into the hands of your users where they can start trying it out under more real-world conditions, because no matter how thoroughly you think you’ve tested and how well you think you’ve thought of everything, the moment your users get their hands on the project they will find new and interesting ways to break it. From a budgetary standpoint, it likely costs less than making the facilities to build your prototypes and then letting the factory and the workers sit idle for years and losing institutional memory in the process.
The tradeoff of this “concurrency” process is, of course, that you’re going to have to go back and fix things on your early airplanes. In fact, they may never quite meet the full production standard. In the commercial world, you deal with this by selling those airframes at a discount to recoup most of your losses; on the military side, they become the trainer and operational test birds. In the case of the F-35, they’re aggressors.
Reply With Quote
