Ospreys and Complexity

The radio is full of talk about the Osprey that came down the other day.

Yesterday, the US military told us that the refueling hose got caught in the blades. Blown into the blades by turbulence.

It was over the ocean, at least, not over populated areas. Of course, the wounded bird needs a place to land, and Okinawa doesn't have any non-populated places to land a wounded bird.

What were they doing practicing refueling in bad weather? Hmm. Practicing refueling in bad weather, I suppose. You can't guarantee good weather for military operations, you see.

My wife's radio talk show host points out this morning that, even though the crash was operator error rather than machine malfunction, the Osprey has more than its share of crashes.

The Osprey is an example of designing beyond the edge of the envelope. We think we need a machine like the Osprey (to maintain our military advantage, I suppose), so we accept that part of its operational profile includes stuff that is not safe. (Look at the Osprey taking off or landing, then ask yourself whether you want to practice refueling that bird in good weather. Heh.)

If you accept the logic of military activity in self-defense, eventually you have to accept the logic of using dangerous machines in military activity.

(While I was listening to the radio, I was thinking about the tendency we have, these days, of accepting dangerous behavior as commonplace, thinking about poorly designed embedded controls programs, and the ascendance of the x86 CPU.

Thinking about a LISP programmer who re-wrote a Forth interpreter in LISP for the space program because he didn't understand how Forth works, and couldn't read 6809 assembly language. And the irony of this was that he was lamenting the move from LISP to C.

Trading a Forth controller on 6809 for a LISP controller on 80x86. For the space program. And not understanding that the reason that C gets the new designs is precisely that Forth and LISP are too easy to customize, and that the programmers fail to be able to communicate their customizations in standard jargon.

[Woops. Having just posted this, I decided to try find the anecdote again.]

He couldn't read the Forth because learning Forth was not in his priorities. [Actually, he really did not have time.] -- Forth is not hard, you just have to re-think things. -- He would have had to recognize that there are other ways to process lists than the LISP way. [Specious conjecture on my part, there.]

The next engineer to read that programmer's LISP is going to have an even worse time, unless he is someone like me, interested in both Forth and LISP, in addition to C and the C standard run-time, etc.

[I didn't find the anecdote I had read, but I found a related one. (Link here. Some of the links in that post might take you to the anecdote I am thinking about. I need to do some real work, today.) It wasn't NASA, it was JPL. And some other irrelevant details, including that the engineer I am referring to did, too, understand the larger problems. He just couldn't figure out a way to communicate them to management. Mea culpa. I was wrong in the details, but it doesn't change my conclusions, whatever they are.]

Thinking about how scary it would be to fly a rocket being controlled by x86 CPUs. :-<

Thinking about how everybody is a slave to the arbitrary deadline, how we give up things of real value because of that deadline.

There is a lesson in here somewhere, but it got lost in the details. And the Osprey example is a good example, but not strictly because of the hardware in the controls circuitry. We must quit teaching engineers in every field, including economics, that engineering is a field where morality can safely be ignored.

Yes the problem is not the Osprey itself. It's the mindset that requires it.

The arbitrary deadline.

Who is going to be the first to back down when brinksmanship puts other people's jobs and lives in danger?)