[ox-en] walking over the pre-alpha bridge
- From: Thomas Berker <thomas.berker hf.ntnu.no>
- Date: Fri, 21 Apr 2006 16:55:44 +0200
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
to
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.
(http://www.stsc.hill.af.mil/crosstalk/2005/12/0512CroxfordChapman.html)
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?
Best,
Thomas
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de