Message 03289 [Homepage] [Navigation]
Thread: oxenT03289 Message: 1/4 L0 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

[ox-en] walking over the pre-alpha bridge

Dear list,
a few months ago I stumbled upon "A Manifesto for High-Integrity Software" (I 
think it was on Slashdot). It calls for rather old-fashioned design 
methodologies when it comes to software which 'just _has_ to work' (nuclear 
power plants, missile control...). Their proposals resemble closely to what 
was coined the 'waterfall method' - a thinking which was and is very common 
in engineering. For example, the authors recomment a methodology which sticks 

sufficient precision at each step of the software development to enable
reasoning about the correctness of that step [...]. The aim is to
demonstrate or argue the software correctness in terms of the manner 
in which it has been produced (by construction) rather  than just by
observing operational behavior. 

I find that F/LOSS development is one of the clearest examples for the exact 
opposite of such waterfall approaches. Just think of "release early, release 
often" and the resulting development by trial and error which make F/LOSS 
possible in the first place. Being inherently iterative and incremental 
F/LOSS development definitely does not adhere to correctness on every 'step 
of software development' -- and that is exactly one of its strengths since 
this opens up for modularity, flexibility and adaptability. And - as we all 
know from daily experience - software produced in the F/LOSS way can very 
well be rock solid - in the long run.
Now here is my problem: Do the authors of this manifesto perhaps have a point? 
Do we need to stick to the good old waterfall method - maybe enhanced by even 
more rigid checks and controls - when it comes to things and structures which 
'just have to work'? Do we want to use a GPLed bridge which - no problem here 
- in a few months or years will be wonderfully stable, but which was 
'released early'? Or does this principle not apply to bridges and similar 
potentially dangerous things?
Working with the application of F/LOSS ideas and experiences in the building 
sector I found it hard to counter arguments of my colleagues (mostly
engineers and architects) which think of their buildings as things which 
'just have to work'. Release early and trial and error is no option for them: 
at least it makes grumpy occupants and may even harm them.
Could someone help me to convice them (and myself)? Is this really such a 
fundamental problem as it seems to me? After all, if we need to abandon some 
of the corner stones of F/LOSS development in exactly those sectors, which 
'just have to work', this would would render it a rather weak 'germ' for a new 
society, wouldn't it? 

Contact: projekt

Thread: oxenT03289 Message: 1/4 L0 [In index]
Message 03289 [Homepage] [Navigation]