The biggest difference between now and then…what makes this impossible today is not that our engineers are less capable, is not that we are more bureaucratic and is not that we’re less motivated.
The difference is that back then, we were indifferent to failure that cost lives.
And not just in development/testing. Once planes were deployed, if a plane didn’t come back from a mission it was “lost in action” independent if the wing just broke off in flight over some stretch of water. Read this excerpt from <a href="http://en.wikipedia.org/wiki/Lockheed_P-80_Shooting_Star#Des...:
<blockquote>The P-80 testing program proved very dangerous. Burcham was killed on 20 October 1944 while flying the third YP-80A produced, 44-83025. The “Gray Ghost” was lost on a test flight on 20 March 1945, although pilot Tony LeVier escaped. Newly promoted to chief engineering test pilot to replace Burcham, LeVier bailed out when one of the engine’s turbine blades broke, causing structural failure in the airplane’s tail. LeVier landed hard and broke his back, but returned to the test program after six months of recovery. Noted ace Major Richard Bong was also killed on an acceptance flight of a production P-80 in the United States on 6 August 1945. Both Burcham and Bong crashed as a result of main fuel pump failure. Burcham’s death was the result of a failure to brief him on a newly installed emergency fuel pump backup system, but the investigation of Bong’s crash found he had apparently forgotten to switch on the emergency fuel pump that could have prevented the accident. He bailed out when the aircraft rolled inverted but was too close to the ground for his parachute to deploy.</blockquote>
So this “no bureaucracy” craze makes no sense for modern aviation design but makes a lot of sense where lives are not at risk (as is the case with a lot of software development, but not all).
The introductory chapter to the Right Stuff (Tom Wolfe) describes this well. The sheer cost of lives among test pilots in the 40s and 50s is shocking by today's standards, but this was a generation that went through Normandy and Bataan.
That said, that doesn't explain why the aircraft of WW2 and the early Cold War took just a few years to go from drawing board to combat, in the days before advanced computer modelling, yet it took 20 years to build the Eurofighter. I suspect the lack of accountability of military contractors coupled with government collusion (jobs programs over national security) has more than a bit to do with it.
I am a fighter jet fanatic, but let's be honest: What the hell is a Eurofighter, Raptor, or Lightening going to do that can't also be done by an Eagle, Falcon or Hornet to more or less the same degree?
Let's be clear: The US and NATO established air dominance over the skies in Gulf War I in days, the Balkans in hours, and Afghanistan and Iraq in minutes with aircraft designed in the 70's. There is really no credible threat to western air forces that makes a new generation of fighter jet a priority.
Or at least, there wasn't. Now that Russia and possibly China are building realistic opponents that will challenge the dominance of F-15s/F-16s and F-18s, there is pressure to upgrade.
wow, Russia and China have started building realistic opponents for F-15s/F-16s and F-18s just now? I'm not sure whether I should laugh, cry, or tear my eyes out...
To be fair, the Russians did have that massive collapse of society to deal with a few years back. It slowed them down a little.
The Chinese still aren't big players in this space, and they mostly take their lead from the Russians.
The Russian's haven't exactly been twiddling their thumbs, but while they make great aircraft, their radar and weapon systems are just now starting to eclipse western fourth generation standards, and the Raptor is still posting 20-1 kill ratios in simulated combat.
That will probably change as the PAK-FA and J-XX come online (the Sukkoi being the greater threat, realistically, since nobody really knows what the J-XX actually is).
Keep in mind that many of the opinions around Soviet technology were overly optimistic. Until the Mig-29 and Su-27 entered service in the 80's, they had nothing that could match the F-14/F-15/F16 and F-18.
The kill ratios of the F-15 and F-16 speak for themselves.
I develop software for a drive-by-wire system for impaired people. Drive-by-wire is not a complex thing (specially compared to a jet) and for impaired people the safety regulations are a little bit lower. The first non-secure prototype with no safety features was done in some months.
After that it needed several years of talking with the regulatory body and making prototypes until we were able to sell the first device.
So I think that a lot of this 20 years are needed for a this regulatory stuff.
Well, in the WW2 there was actually a war going on, so producing deadlier and deadlier types of weapons was a more urgent matter for all parties involved. Probably true of the early Cold War times too.
> Johnson deplores the trend toward specialization with the lament of a designer who also knows how to handle machine tools. “Some of the fellows in the Skunk Works never had any cutting oil splashed on them.”
There are plenty of programmers that have never held a soldering iron either.
I'm not even sure if that's 'good' or 'bad', it seems there are advantages to knowing what goes on under the hood but at the same time that knowledge comes in to play less and less every day.
It is always good to learn the abstraction layer below when creating something. For designing physical objects that will one day be physical products, it makes a lot of sense to understand the manufacturing process and materials involved.
To use your example of software... I've encountered one too many people who are billed as an Enterprise software "architects" who have never coded a single line production software in their life <cringe>. Needless to say, these projects almost always end up a disaster.
I think you misunderstand the purpose of that kind of architect - their job is to wear a suit, give good PowerPoint and disappear in a puff of UML when it comes to actually building software.
I am aware that it is common practice for a guy with a title architect be the "smoke and mirrors" guy during the sales phase.
I am referring to so called architects who have the role of leading a group of programmer during the building of software. Unfortunately many times their understanding of software does not go beyond the Visio and Powerpoints but it is falsely assumed they can still lead due to pointy-hair-boss soft skills. What ends up happening is crapware due to a lack of understanding of fundamental software design and process.
I don't understand this logic. Yes, in a start-up, having multiple skillsets and job overlap comes in handy.
In the corporate world, however, that MechE will likely never do anything but CAD up parts. They will have a machinist on staff to make his creations. Just like how corporate programmers don't need to build their own computers or run the company's IT.
A better analogy might be a story of a friend of mine from graduate school, Chuck. He, and another grad student we'll call Mike, got their first year of graduate funding through a professor with very little grant money. It was very important that Mike had machine shop skills and could build some of their research equipment for the lab. Mike made a name for himself -- he wasn't a very good machinist compared to the guys on staff -- but he was building the needed equipment, even if it was very time consuming.
Using this humble lab, Chuck and Mike worked hard for their professor and eventually got lots of funding. It got to the point where the funding was so much, that time was more a concern. Chuck could then overnight parts from electronics catalogs and conduct research faster/better than Mike, who despite having this funding, continued the frugal habit of machining all his own parts. Mike eventually got disciplined (for not moving fast enough in his research) and frustrated (he fixated on the fact that his skills helped them get the funding in the first place).
TL;DR: When Time becomes greater than money, I'd rather have the CAD guy CAD it up, and the machinist make it.
Because without the ability to machine it, you have far less of an insight into how hard it will be to do so, or how long it will take, or how much wastage there will be. That can have an orders-of-magnitude effect on the cost. In your story, Chuck is ordering parts sure, but the guy who designed those parts was a specialist in designing parts...
In my first year of Mech Eng they sent us all off to a machine shop to learn to weld, use a lathe, etc, I couldn't give an example to you now, but it really does make a difference, you start to think as well as "how will this work" but also "how will this be made", "how can this be repaired", "how will someone get at this part to replace it", etc etc.
Exactly. I can't tell you how many times I've heard my dad (a lifelong precision machinist) complain about the quality of drawings from CAD jockeys that have no clue about machining processes.
This is like saying that Apache is a bad web server because IT people complain to the System Architects over how hard it is to harden it for PKI and use in Top Secret Environments. Odds are the IT monkey doesn't know what he is talking about anymore than the lathe monkey. Both have a false sense of expertise because they see their field as "equal".
are we talking about integrated circuit chips? Because everyone in the EE/SOC world mocks the VLSI monkeys. Its a $120/hour CAD jockey job. It's an entirely different skillset and mindset to adapt an ISA to hardware than is to make sure there's no overlap.
>In your story, Chuck is ordering parts sure, but the guy who designed those parts was a specialist in designing parts...
Exactly. In the long run, re-inventing the wheel is costly. Costly enough that Chuck graduates with his PhD, while the other ends up failing out and working at a machine shop.
Also, a constant criticism of Chuck's counterpart, Mike, was that everything he built was constantly over-engineered, and took to damn long. If anything, his machine shop experience hampered his ability to design or refine his design skills past an undergraduate level.
A semester of welding, lathing, and whatnot will likely not help a professional MechE, as easily half their CAD designs will be fabricated completely by machine. Understanding a precision machinist's complaints will not come into the field.
Nothing is "fabricated completely by machine" like an ink jet prints on paper. I work in 3D printing, the closest to this fire-and-forget model, and there are still a lot of design contraints and optimizations that any engineer needs to know to be truly good at making parts.
If you're designing shaping, molding, machining, etc. parts having an idea of manufacturing processes is essential to elegant solutions at low cost.
The other way would be like an artist who instructed someone to paint his masterpiece from his initial sketch. A lot is lost in translation.
The problem is that it is entirely too easy to "CAD up" a design that is almost unmanufacturable, or that is ridiculously difficult or expensive to manufacture. Having experience actually building or fixing things is a hedge against this. Years ago, young engineers fresh out of school were put to work on the production floor for a few months to learn these lessons. When I graduated as an EE, the small company I went to work for wouldn't let me do anything other than documentation and repair for a year for the same reason.
Makes you wonder what the Spanish pilots did right that went wrong elsewhere.
of course they didn't fly nearly as many F104s as the other airforces but still, a '0' where elsewhere the percentages of losses are some of the largest of all fighter jets ever recorded should at least make for an interesting investigation. Not that it matters anymore with the F104 being retired from service but there might be something to be learned from that.
I haven't had a chance to do more than skim the article yet, but if you get a chance, read Skunk Works by Ben Rich. The book is about the shop Kelly Johnson (the subject of the article) ran that gave us all kinds of great flying toys. It's a neat story about a legendary engineer/leader.
I can't even tell how many years the design of the F-22 has taken, but that timeline lists 13 planes delivered in 2003. 13 per year versus 28 a day.
Now, obviously modern planes are much more complex than they were in 1943, and they should take longer to design and build. But how much longer? How much is the bureacracy actually hurting?
From what I've read, there was a huge amount of politics involved in the F-22. Plus, we're not in WWII, so there's less demand on pumping out high volumes of good-enough planes and more focus on building something that really pushes the limits of technology, which the F-22 does.
Yeah. I remember reading that the F-22 or the JSF has contracts in 48 states. They really spread around the contracts to ensure smooth sailing in Congress. Everyone got a piece of the action (jobs to bring home) so to speak.
The problem is, it's also insanely easy to disrupt manufacturing that distributed. If it ever came to a war where bombs/rockets/cruise missiles were hitting our soil, it would be nearly impossible to ramp up production of this jet, much less protect the facilities involved in designing/making it.
If it came to war then speed of production of fighter aircraft would have a pretty minimal impact on the US ability to achieve air superiority. The days when Britain survived WWII by manufacturing >14000 Hurricanes are long gone
You're right, but it depends on the length of the conflict. Each Apache Helicopter is built by hand. They have individual names. We only produce 60 of them a year.
I don't know the loss rate we've encountered in Iraq and Afganistan (I know its much lower than the Blackhawks) but even if you're losing 61/year for a long enough timeline....
Check out the Eurofighter Typhoon. By most accounts, while it's no F22, it's not a bad plane (if you need air superiority over central Europe against a numerically superior enemy... Not much use as a bomber).
But the goal of the project was propping up the European aerospace industry...
As far as I can see the goals of most large military procurement projects, at least in the UK, are primarily political and then as status symbols for the relevant branch of the military.
What the people we put in harms way actually need to get their jobs done seems to be of relatively little importance.
Doesn't matter what they're designing. Meetings of 15 people waste at least 10 peoples' time. People don't change just because the problem gets harder; they can't collaborate in large groups as well as small ones. And 15 is not small.
Good comment and I agree with you, except maybe in this case they would have 2 pilots, 2 mechanics, 2 people from the war department, 2 people from the treasury, the core engineering team, and a secretary - when you need approvals, it might be easier to have a meeting also be a presentation where people put their stamp on the document immediately afterwards instead of running the meeting two or three different times.
The difference is that back then, we were indifferent to failure that cost lives.
And not just in development/testing. Once planes were deployed, if a plane didn’t come back from a mission it was “lost in action” independent if the wing just broke off in flight over some stretch of water. Read this excerpt from <a href="http://en.wikipedia.org/wiki/Lockheed_P-80_Shooting_Star#Des...:
<blockquote>The P-80 testing program proved very dangerous. Burcham was killed on 20 October 1944 while flying the third YP-80A produced, 44-83025. The “Gray Ghost” was lost on a test flight on 20 March 1945, although pilot Tony LeVier escaped. Newly promoted to chief engineering test pilot to replace Burcham, LeVier bailed out when one of the engine’s turbine blades broke, causing structural failure in the airplane’s tail. LeVier landed hard and broke his back, but returned to the test program after six months of recovery. Noted ace Major Richard Bong was also killed on an acceptance flight of a production P-80 in the United States on 6 August 1945. Both Burcham and Bong crashed as a result of main fuel pump failure. Burcham’s death was the result of a failure to brief him on a newly installed emergency fuel pump backup system, but the investigation of Bong’s crash found he had apparently forgotten to switch on the emergency fuel pump that could have prevented the accident. He bailed out when the aircraft rolled inverted but was too close to the ground for his parachute to deploy.</blockquote>
So this “no bureaucracy” craze makes no sense for modern aviation design but makes a lot of sense where lives are not at risk (as is the case with a lot of software development, but not all).
That’s my $0.02.