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.
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.
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.
Having "unsafe" is necessary for making useful software and, in fact, it is also present in most other safe languages: Python, Java, Haskell, etc.
However it is disingenuous to claim unsafe is necessary for making any useful software.
For instance, if I want to download/parse an html webpage or make some sort of web crawler or bot, why would I need unsafe?
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.
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
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.
The lack of this is the #1 problem with professional software engineering.
IMO, service based cloud services are forcing infrastructure people to adopt an engineering thought process. Not quite as pervasive for software development.
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.
Supervisor is the right word to use.
any examples out there?
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_." 
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. 
 p272-273, Skunk Works by Ben Rich
 p278, Skunk Works by Ben Rich
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 ....
See: Ferdinand Foch
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.
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).
"He was all things to all men... it was hell in there."
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."
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.
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...
My comment about a secret project was referring to a hypothetical aircraft that is in operation but isn't publicly known.
That or we got stupid since Kelly died. One of the two.
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.
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.
As to your "point", it's trivial to say "we can't do something" when we haven't tried.
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.
And I don't know why it would be remotely remarkable that a group of nerds finds that stuff interesting.
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.