vintage computers in active use

[Alan Perry]

> On May 27, 2016, at 08:41, Swift Griggs <swiftgriggs at gmail.com> wrote:
> 
>> On Thu, 26 May 2016, Toby Thain wrote:
>> We're pretty much already there.
> 
> Agreed. You should hear one of my buddies talk about the air traffic 
> control software he wrote which was replaced with some horror.
> 
>> Audits of the F35 software found:
>> * single points of failure (grounding global fleet)
>> * security issues
>> * that software is the single biggest risk to the project
> 
> One of the principles of Unix: KISS, has been nearly completely lost. 
> Nobody calls a meeting anymore to say "What can we get rid of? How can we 
> simplify this? What is the *right* thing to do here?" It's more like "how 
> big of a kickback will I get if I put in this nasty thing this vendor 
> wants to sell?" or "Does the new system have buzz?"

I worked on F35 software 13 years ago. I am not an aviation systems guy, but I was an expert in a technology being used, which is why I was on the project.

I am both shocked and not surprised that development of the plane has taken so long. The software guys there experienced with military contract work said that the project was typical at that point. I left being amazed that anything that comes through the process ever flies.

The biggest problem that I saw then was technical choices made without considering the implications of the choices, followed by kludge after kludge to get around yet something else they hadn't considered. I see that all of the time on other projects, but the prime contractor and sub-contractor (and sub-sub-contractor) arrangement that stuff like the F-35 is designed and built make it hard to change a poor technical choice made before the work is subcontracted out.

BTW, the primary poor technical choice that I saw was made to reduce costs, not for lock-in or to give some preferred company business.

alan