I resent calling Kelly Johnson merely the inventor of SR-71. He was the father, the project manager and the organizational hustler who found Skunk Works and defined it's working culture. He was a legendary aviation engineer but also really understood how to get a team of experts to produce results and to co-operate with the manufacturing and operations to create feats of engineering.
He found and ran a lean organization on grit and triftiness when toyota production system was taking it's baby steps in japan.
I heartily suggest Ben Rich's 'Skunk works' to anyone who gets a kick out of a true story what it actually means in terms of output when an innovative engineering team actually works lean... in hardware.
Kelly had a few other rules. One was that the engineers, the machinists, and the airframe must be physically close, preferably in the same building. That way, if a part wasn't working, the assembler, machinist, and designer could all get together at the airframe and figure out what to do about it. HP also had that approach to work in their glory days.
Another Kelly saying was "Kill problems, don't wound them". If some part is causing problems, don't make one that has fewer problems, redesign it so the problem goes away completely.
The "kill problems, don't wound them" idea reminds me of the idea in programming to make invalid states unrepresentable. It's not always possible to redesign problems away entirely, but if it is possible, it is a good thing to do.
Absolutely. A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.
For example, the JSF C++ guidelines say not to use 'l' suffixes on numeric literals, because they look like a 1. D simply makes the 'l' suffix illegal, use 'L' instead.
A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.
Exactly. That's why I'm bothered by Rust being almost protected against memory errors, and Go being almost protected against race conditions. Even if you give up some performance, it's a big win to eliminate entire classes of errors.
(Still, both are way ahead of C/C++ in this area. So far, I don't think there's been a CERT advisory for a Go program. Rust is too new to be attacked yet.)
It has been (7) days since the last CERT security advisory for a buffer overflow in a C/C++ program.
A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.
Depends on what you want. Give me a powertool and I'll give a powerful result. Give me safety scissors and I'll take much longer, and the result will probably be inferior. And I can say with some certainty that both products will be roughly equal in terms of safety, because I pay careful attention to safety when designing and implementing systems. But the products will differ greatly in terms of feature set, extensibility, and robustness.
It's difficult to add safety without subtracting power.
Both of their autobiographies are worth the read for any engineer, or aspiring engineer. I found Johnson's biography especially inspiring, as he is a man who grew up in a poor family, and worked very hard to become a highly respected aeronautical engineer, responsible for more innovative projects than any of his peers (before or since). Some of the stories that stuck with me from his book were how his father (a bricklayer in the midwest) used to have to light a fire in a barrel to heat up bricks so that the mortar would adhere to them in the winter. He also mentions that when he was a child (during the depression), he and his sister used to walk to the curves on the railroad tracks with their wagon, to pick up the coal that fell off trains so that they could heat their house. The man worked his way through college in the kitchen of one of the fraternities, soon after contributed to the design of the Electra, and then the first American jet fighter to enter service (the P-80).
Seconded. I'd note that while Johnson's memoir (/Kelly/) is more inspiring, I recall there being more meat in Rich's memoir (/Skunk Works/)---more discussion of the technology, organizational dynamics, and interpersonal politics. Both are, as you say, very much worth reading.
For more of this kind of thing, see "Sidewinder: Creative Missile Design at China Lake" by Ron Westrum. China Lake had an even more radically free-wheeling approach.
This is all really close to hacker culture, to the extent that there's a risk of "inscription errors" (where you mistakenly think you have found corroboration for your ideas but are just looking at your own culture). Fred Turner traces a lot of the current philosophy of the Internet to post WWII research cultures: http://c-lab.columbia.edu/0188.html
Another Stewart Brand fan. I had a WELL account. I used to go to the Hacker's Conference. No, computer technology did not come out of the hippie movement. It came out of the people who wore white shirts in the 1960s.
The Sidewinder story is interesting. I used to work for Ford Aerospace, which made the things at another location. The China Lake crowd developed proximity fuzes, designed to turn a near miss into a hit by detonating the warhead close to the target on a near miss. If they could do some steering correction, they could turn even more near misses into hits. The pilot using an early Sidewinder still has to get on the tail of the target, but they don't have to get as close. Sidewinders usually either get a direct hit or a complete miss, because the heat-seeker gets more accurate as it gets closer.
The competing radar-guided missiles of the era were trying to lock on at much longer ranges and hit the target on their own, like surface-to-air missiles. That's a much harder problem, and the electronics of the era wasn't up to the job.
The "China Lake culture" was simply that there wasn't anything else to do out there but work (it's in the middle of the Mojave Desert), visits from the top brass were rare, and they had all the facilities to build and test weapons without having to outsource fabrication. Plus they had planes, pilots, an airfield, and a bombing range. So a lot of work got done. China Lake was also a joint Navy-university setup with Caltech. (JPL, as a Caltech/NASA operation, is similar.) So they had access to theoreticians when necessary.
"Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised."
The lack of this is the #1 problem with professional software engineering.
What passes for software engineering is usually nothing of the sort. Shoot from the hip, google/cut/paste and instinctual decision making is still very common.
IMO, service based cloud services are forcing infrastructure people to adopt an engineering thought process. Not quite as pervasive for software development.
Supervised! Yes, that's exactly the right word to use!
Instead of 'leader', 'manager', 'director', 'president' and all those pointless buzzwords. If all you are really going to do is forward emails and approve leaves.
From the link: According to the book "Skunk Works" the 15th rule is: "Starve before doing business with the damned Navy. They don't know what the hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy."
In Ben Rich's book, he gives a couple of examples. First, one with a proposal for a design of a stealth submarine, and then second, another example of an actual prototype of a stealth ship that underwent a year of testing (in which it performed admirably) before being rejected.
Here's a telling excerpt from the submarine adventure:
> That submarine captain epitomized the hidebound Navy at its worst. He frowned at my drawing and backhanded my concept. "We don't build submarines that look like that." He admitted that our test results were "interesting" but added, "Your design would probably cost us two or three knots in speed." I countered, "But why care about losing three knots, when you are invisible to your enemy?"
>
> He ignored me. "This looks more like the _Monitor_ or the _Merrimac_ from the Civil War," he said. "We'd never build a modern submarine that looked like _that_." [1]
Then there was the full-scale testing of a stealth ship in which nightly tests were made with the Navy trying to detect the prototype with radar, and virtually always failing. Eventually the Navy decided not to go ahead, on the grounds that they couldn't keep it secret. Rich also speculated on motivations:
> A future commander resented having only a four-man crew to boss around on a ship that was so secret that the Navy could not even admit it existed. Our stealth ship might be able to blast out of the sky a sizeable Soviet attack force, but in terms of an officer's future status and promotion prospects, it was about as glamorous as commanding a tugboat. [2]
> He ignored me. "This looks more like the _Monitor_ or the _Merrimac_ from the Civil War," he said. "We'd never build a modern submarine that looked like _that_."
it is beyond ironic, giving how revolutionary the Monitor and the Merrimack/Virginia were, how one battle between them has changed the naval warfare for the whole world ....
In a more recent example, the F35 Jet is having delay and cost overrun problems. I hear that one of the reasons is that there is 3 different version of the same jet and it may have been cheaper to design 3 completely different planes oriented toward each niche.
The 3 configurations are:
A) Conventional takeoff and landing (CTOL). A normal fighter jet, intended to replace the F16.
B) Short takeoff and vertical landing (STOVL). This model essentially has a big fan in it to allow it to hover and land on aircraft carriers.
C) Similar to A, but with larger, foldable wings and a stronger tailhook for landing with a carrier arrestor cable.
Model B is intended for the Marine Corp, and C is intended for the Navy.
Now I admit that I am fairly uninformed about military hardware and design, but I think something can be concluded from the F35 program issues.
And the exact same thing happened with the TFX in the '60, except it was proposed to also fill the air superiority role that the F-22 was designed for, and not the V/STOL one. The F-111, in the deep interdiction role, was the only surviving model.
Not clear the Navy or Marines had anything to do with this Charlie Foxtrot, at least prior to the decision to save money by having only one basic plane.
This is a common peacetime "savings" measure. Same thing happened with the M14 rifle, which had about the shortest time as a combat rifle in US history (although part of that was due to the utterly corrupt Army institution that procured it when pretty much every other contemporary battle rifle design was better, except for trigger pull).
If I remember correctly, the Marines use amphibious assault ships that don't have conventional runways (such as on Navy aircraft carriers) to take off/land on thus the need for a VTOL aircraft. A VTOL wouldn't be necessary for a Navy aircraft carrier (example: F18 Super Hornet). Another example of this is why the Marines wanted to keep the Harrier around for so long before it became too problematic and expensive hence why they wanted VTOL capabilities on the F35 JSF (also another factor in the cost/time overruns).
Ever wanted to kill your project manager for changing specs during a project?
That but your project manager is the US Navy. I meant for these to be more generalized as most are pretty applicable to tech, as Skunk Works airplanes was high science on a budget.
Relevant portion: "Lockheed and the Joint Strike Fighter program office ultimately traced the problem back to the shape of the hook and a faulty wire dynamics model supplied by the Naval Air Systems Command. The solution was to reshape the hook point and adjust the system’s hold-down damper, which helps prevent the hook from bouncing around upon touchdown."
Point 6, "Don't surprise the customer", is the foundation of all good project management. To manage that requires knowledge and communication in all aspects of what you're doing. It's not a guarantee of success, but its definitely something to aim for.
It is telling that the SR-71 has not been replaced with a better and faster plane.
It appears that without Kelly and his organization, the government/contractor world is simply incapable of the task. In spite of material sciences advances, computing and CAD advances, etc., not only can today's system not produce an improved version, it would not even be able to match the specs of the SR-71 in a new design today.
Of course some may say that the successor may exist but is so secret no one knows of it, but that is extremely unlikely. If it existed whoever created it wouldn't be able to resist taking credit.
The use case for the Blackbird has (mostly) gone away - iow, we don't have MAD and a burning need to spy using airplanes. The defense procurement industry ( aka the Military Industrial Complex ) is a major... victim of Baumol Cost Disease, and those two taken together...
no indictment of the practitioners there; it's just all but inarguable. If you work in a defense company, you'll either adapt to "do" contracts/procurement or you'll be gently pushed out...
Yes, it remains to be seen if the SR-72 will ever become a reality. As an engineer I believe it is possible to make such an aircraft a reality, but I have no knowledge of the program beyond what was stated in its announcement. As for the possibility of an already extant replacement, anyone who revealed information on such an aircraft without authorization would be risking their freedom (and possibly their life).
Or...hyper-velocity, fly-over, manned surveillance platforms have been replaced by increasingly sophisticated surveillance satellites, non-fly-over surveillance technology (e.g. SLAR) and unmanned drones, making an undoubtedly immensely expensive, manned SR-71 follow-on superfluous.
That or we got stupid since Kelly died. One of the two.
The original studies of Baumol Cost Disease were based on the idea that the production of symphonic performance has had no productivity increase since ... well, ever.
When asked why there are no "variety" shows on television, Glen Campbell ( of the "Glen Campbell Goodtime Hour" ) stated that they were verging on economically infeasible while his show was on, and you certainly couldn't do that today. My understanding is that "The Carol Burnett Show" had this problem and it only ran as long as it did because it was CBS' flagship program. "Carol Burnett" was not a classic variety show using ... a dozen artists per program so it was probably less expensive than Campbell's.
I'd expect the same has happened in aviation. Now, is that the same thing as "we got stupider"? I can't say.
No doubt, satellites can perform the role of the SR-71.
My point is that the system we have in the US could not create a new SR-71 class airplane right now, in my view. It would run over budget, miss the performance targets, and be cancelled.
Actually, satellites alone can't do what an SR-71 can. Satellites aren't an ad hoc intelligence solution, since they are periodic in their orbit and can't image something they aren't on-station to see. But combined with other tech, they replace the SR-71 nicely.
As to your "point", it's trivial to say "we can't do something" when we haven't tried.
I find HN's infatuation with SR-71 kind of amusing. I think the site should have a logo that's the SR-71 flying over a globe or something similar. If you think about it the Y logo kind of looks like an SR-71... :)
Well, for me personally, SR-71 is one of those childhood geek objects of idolation that grows in stature inverse to the rest of the things one finds interesting when they are in their pre-teens and how they look like 25 years later. Most of the things one finds fun and insipirational then end up looking quite silly now.
Unlike the Blackbird. The more one understands about how engineering projects go, how work is organized and how hard it's to do anything novel ones appreciation of the plane and the organization that built it and operated it grows enormously.
It's not just the SR-71 as it is almost any example of exceptional and unusual engineering. You'll also see semi-frequent posts about Concorde, gigantic cargo ships, space launch rockets, iconic high-end cars, etc.
And I don't know why it would be remotely remarkable that a group of nerds finds that stuff interesting.
The SR-71 was an impressive engineering feat because it successfully brought together a bunch of really crazy tech and got it to work. All of this with a relatively small team and stone-age (by modern standards) computational ability.
The A-10 was an impressive engineering feat because it perfectly executed a very boring and conservative design. It did one thing, did it very well, and was so reliable it arguably put its producer out of business.
If I had to draw a comparison to software, I'd compare the SR71 with Erlang, and the A-10 with Postgres.
They were both such impressive pieces of engineering execution that they completely changed their respective games. They may be old now, but they are engineering success stories worth admiring.
He found and ran a lean organization on grit and triftiness when toyota production system was taking it's baby steps in japan.
I heartily suggest Ben Rich's 'Skunk works' to anyone who gets a kick out of a true story what it actually means in terms of output when an innovative engineering team actually works lean... in hardware.