Bill,
Thanks for the Shuttle code development methodology info.
I suspect (but can't easily prove) that cultural shift is also a factor
in the difference between Shuttle FBW code running to hundreds of
thousands of lines while modern aircraft take millions. Back then,
coding compactly and elegantly was still widely seen as a virtue. Now,
apparently not so much. Faster processors and more storage seem to be
generally considered cheaper to throw at a problem than elegant
programming.
Possibly they also want more specialized operating-mode subprograms
these days, mind. I don't have a good feel for how complex the Shuttle
FBW task definition was, but at a guess F-35 or 787 software have a
wider range of operating conditions and more special cases to allow for.
Henry
On 6/1/2019 6:39 AM, William Claybaugh wrote:
Henry:
WRT the Shuttle flight code only—which was Class 1—what demonstrably worked was to use two teams of programmers, one to write and the other to break the code. They switched roles periodically to keep fresh and they were forbidden to work more than eight hours per day.
After a dozen or so flights the flight code dropped to 2-3 detected errors per load, by the end of the program zero detected errors was common. However, this model applies only to repeat software builds; other but similar methods are used for Class 1 single build software, for nuclear projects, for example.
Bill
On Sat, 1 Jun 2019 at 07:12, Henry Vanderbilt <hvanderbilt@xxxxxxxxxxxxxx <mailto:hvanderbilt@xxxxxxxxxxxxxx>> wrote:
On 6/1/2019 12:07 AM, Uwe Klein wrote:
> Am 01.06.2019 um 01:44 schrieb rebel without a job:
>
>> or you can pay more programmers so you can have tighter, more
efficient
>> code.
>>
>
> That is an interesting theory.
> ( Killed on a regular basis by reality.)
>
> i.e. when ever the internals of commercial large scale software
> gets public exposure it comes out as an even tighter wick of
spaghetti
> in an opaque "proprietary<foot stamp>" shell.
>
Put it as "pay more to [the right] fewer programmers so you can have
tighter more efficient code" and it makes a bit more sense.
Only who is reliably competent to select then manage the right fewer
programmers?
Henry
