Re: [ox-en] walking over the pre-alpha bridge
- From: Stefan Merten <smerten oekonux.de>
- Date: Fri, 30 Jun 2006 08:30:51 +0200
Hi Thomas, Per, all!
2 months (70 days) ago Thomas Berker wrote:
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.
Well, these topics all belong to the field of software engineering.
Indeed in this field there is a long debate whether waterfall models
are useful or not. (The watefall model basically claims that you can
plan a piece of software and then implement it step by step without
any need for iteration.)
The very reason for the waterfall model is that it works well in many
other fields of engineering. That's why some 40 years ago some people
thought that it should also apply to software.
During the last years there is a trend in software engineering heavily
questioning the waterfall model. Iterative models are developed such
as Extreme Programming or Scrum. They pick up the common wisdom that
developing software *never* is a straight line from A to B which you
can plan in advance. In the contrary they embrace change by developing
software step by step in a highly iterative manner.
Indeed I think this is the case. Software development is inherently
something different than building a bridge. For instance there are
unlimited degrees of freedom in both the goal of a software
development process as well as the ways to accomplish that goal. This
is different when you build bridges - for instance laws of nature set
hard constraints here. In addition each piece of software is something
completely new and IMHO people are simply not able to imagine
something completely new well enough to plan it in advance (applies
both to software development as well as to the GPL society ;-) ).
Personally I'm now developing software for some 25 years. I learned
that iteration is the only way to go. It is what is done in practice
anyway - regardless of how much the waterfall model is wanted. But
please don't confuse iterative models with chaos. You can have a
defined process with iterative models and indeed for example Scrum is
a nice recipe how to implement a iterative model.
Indeed I think that the Free Software development process(es) are very
interesting for software engineering *because* they lead to working
products - something every engineer strives for. Indeed AFAICS models
used in Free Software are more and more looked at in software
engineering research.
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 don't think that Free Software development excludes any useful
method per se. I agree with Robin that formal methods will be useful
for Free Software development then Free Software developers will pick
it up. Don't forget that many Free Software developers also are payed
for work in the same fields and why should they not move their
experiences from payed labor to Free Software?
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.
Hmm... I don't know whether this is real trial and error in the narrow
sense. Development tries to solve a certain, given problem and is not
a simple trial like throwing a coin. Indeed when I look at proprietary
software (I'm just strating to work with a complex proprietary
software in my job - sigh...) then to me it looks much more like trial
and (never corrected) error than most Free Software products I'm
using...
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.
I'd say that incremental processes also can be correct on every step.
I don't think there is a contradiction.
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'?
Definitely not.
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?
No. There are fundamental differences between building bridges and
building software. These differences are the reason why different
things work here and there.
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.
But even architects talk to their customers - don't they.
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?
Hope this helps.
2 months (70 days) ago Per I Mathisen wrote:
The paper you refer to seems stuck in the ISO9000 mindset of development
which is focused laser-like on process and almost zero on content. It is
the idea that quality control first and foremost must exist in the
production stage. Correct process leads to correct result.
This kind of thinking is crucial for example in empirical science, where
how you conduct your studies is more important than your results, because
if your process is flawed (eg test results are contaminated), your results
are irrelevant, even if in the end the conclusion turns out to be true.
However, open source software and open design is more like theoretical
science, where process is irrelevant and ability to indepedently verify or
falsify the final result is everything. When a fault is discovered or
thought likely, one does not question the process that created the
program, but one reads its source code. This is even more the case when
functional approaches are used, which more resemble theoretical work than
iterative languages do.
Well, I think you need to distinguish different types of faults. The
approach you describe is useful for accidents. An accident is
something which may happen but in principle can be prevented. This is
what a waterfall model tries to accomplish. And indeed I'd think if
you have the same type of accident all the time it makes pretty much
sense to think about how to avoid them - i.e. try to improve your
process.
The type of problems I tried to outline above, however, are not
accidents. They are inherent to the problem *as such* and therefore no
process can remove them.
Mit Freien Grüßen
Stefan
--
Please note this message is written on an offline laptop
and send out in the evening of the day it is written. It
does not take any information into account which may have
reached my mailbox since yesterday evening.
_________________________________
Web-Site: http://www.oekonux.org/
Organization: http://www.oekonux.de/projekt/
Contact: projekt oekonux.de