Re: [ox-en] walking over the pre-alpha bridge
- From: Robin Green <greenrd greenrd.org>
- Date: Fri, 21 Apr 2006 16:19:07 +0100
I am a student of formal methods.
Formal methods can be used both with "waterfall" style development,
or with iterative development. Just because the requirements change
and develop midway through a project (which is normal and expected)
- and just because projects fork - doesn't mean you can't reason about
the requirements, and about the code, in a formal and rigorous way.
The real question is, when formal methods take off in the real world,
will open source projects bother to use them, given the apparently huge
upfront cost? I think they will, because, like statically typed
languages (which are also popular in the open source community), but
much more so, formal methods can provide benefits for debugging and
maintenance, which is a huge boon. Not all open source projects will use
it, of course, but I believe and hope that many will.
--
Robin Green
PhD student
Systems Research Group, Dept of Computer Science & Informatics, UCD
Dublin, Ireland
On Fri, 21 Apr 2006 16:55:44 [PHONE NUMBER REMOVED]
Thomas Berker <thomas.berker hf.ntnu.no> wrote:
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
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de