Is the analogy with bridge building and civil engineers valid? I would
venture a guess that the majority of the work in building a bridge is done
by the construction workers who do not know or understand the principles of
physics fully. It may not even be necessary for the construction foreman
who reads the blue prints to fully understand the physics. It is the civil
engineers who must understand the physics. Or do they? People have been
building bridges and cathedrals that do not fall down since well before
Newton articulated the laws which you say are so important.
Are we programmers the engineers or just the construction workers? The
electronic computer is not as old as I am. Maybe we are asking a lot of
such a young technology. Maybe we could make a better analogy with medieval
cathedral builders whose work has withstood the test of time. At that time
the distinction between the expert builder and the laborors was not as great
as that between the civil engineer who designs a bridge and the construction
workers. Who are we and what do we really need to know that will help make
software better?
Jim Gray
----- Original Message -----
From: "Gregory Woodhouse" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, November 12, 2005 5:52 PM
Subject: [Hardhats-members] Goedelian malaise
This does have anything specifically to do with medical information
systems in general or VistA in particular, so feel free to stop reading
now, if you wish. But it does have to do with the quality of software in
general, and so is related (albeit indirectly) to healthcare informatics,
and to VistA.
A well known statistic in the computer industry is that 75% of projects
fail -- and that's only the beginning of the story when it comes to
issues of software cost and quality. Why is this? No doubt, we have all
been involved in failed projects, and we can easily think of problems
leading to the failure of specific projects. It is tempting to look at
specific issues (poor specifications, not enough management support,
inadequate testing, tight timelines, etc.) and imagine that these are the
core issues. But is this really true? It's hard to imagine how these
issues, alone or in combination, could lead to anything so stunning as a
75% failure rate. It is certainly not a matter of not trying hard
enough -- cost overruns in software development are also legendary.
So, what is to be done? The accepted approach today seems to be a two
pronged approach based on process and testing. Though we pay lip service
to the idea that testing can never show an implementation to be correct,
only incorrect, we continue to rely on testing as one of the two
principle mechanisms for ensuring software quality. The other, is of
course process, which in practice usually means trying to find the right
set of artifacts, documents to which interested parties must affix their
signatures, thereby becoming accountable for their own commitments. But
as we continue to wrestle with quality problems, the process simply
becomes more and more burdensome, without any significant benefit in the
end. To be sure, there are reactionary movements like agile development
methodologies and open source that may rightly be viewed as alternative
processes. But ultimately, there are basic problems that no one has been
able to successfully address. At best, one approach may prove more
successful than another within a given organization and at a given time.
Ultimately, I think the problem that we do not try to address the issue
of software quality more systematically from an engineering perspective
is that we do not even try. Undoubtedly, one of the most famous (and
least understood) results in theoretical computer science is Goedel's
incompleteness theorem, which roughly states that in any formal system
rich enough to describe integer arithmetic it is possible to make
statements that cannot be refuted but also cannot be proven to be true.
Closely associated with this is the somewhat less familiar concept of
decidability. Virtually any freshman computer science student will learn
that the "halting problem" is unsolvable: that it is theoretically
impossible to write a computer program that can determine if any program
provided to it as input halts (i.e., does not go into an infinite loop).
(If you're curious as to why this is true, you might ponder what it would
mean to run such a program when it is fed to itself as input.)
So, ultimately we throw up our hands and enter a kind of "Goedelian
malaise". It has been proven that we can't mechanically determine whether
an arbitrary program is correct, so why even try? We *can* test, and it's
our only realistic alternative, right? Not so! Though there is no general
method for showing that an arbitrary program meets or does not meat a set
of specifications, it is certainly possible to show that *particular*
programs do conform to a set of specifications. In fact, we do this all
the time, often without realizing that this is what we are doing. But,
some will object, *real* programs are far too complex to be treated
formally. If you believe this to be the case, you might consider looking
into the methods compilers use to optimize code, such as loop
optimizations, or eliminating unnecessary writes; e.g., replacing
SET X=1
SET X=2
SET X=3
SET Y=X
SET X=4
...
SET X=10
with
SET X=10
SET Y=3
Reasoning about programs is a lot more doable than you may realize.
Even so, we know there are problems out there we either can't solve, or
can't solve in a reasonable amount of time, so isn't this all a little
presumptuous? When I as in college studying mathematics, chaos was all
the rage. "Chaos" is another familiar term that is often misunderstood:
it has nothing to do with randomness or non- determinism. Rather, a
chaotic system is one in which arbitrarily small changes in the initial
configuration of the system can have "large" effects (I put this in
quotes because it needs to be formalized mathematically, and is a little
more subtle than it may initially appear). One of the most familiar
examples of chaos is undoubtedly turbulence in fluid flow. In a gentle
flowing brook, sticking your finger (or a boat) in the water has
predictable results, but white water rapids are quite another matter.
Chaos is simply part of the reality of the natural world we all have to
deal with, and can manifest itself almost anywhere that feedback is
present. Does this mean civil engineering is a lost cause? Should
engineers simply accept that 75% of bridges will fail, or rely on testing
as a means of determining that a bridge is built correctly? Of course,
testing is important, but it's not the only thing we can do. Bridge
design isn't just guesswork: there are fundamental principles of physics
that can and should be employed in the design of bridges. So it is in
software design. There is a well developed underlying theory that can and
should guide our work. But, sadly, it is often deemed to esoteric or
"formal" to be of any practical use. This is unfortunate, because there
really are tremendous benefits to be reaped from applying rigorous
mathematical methods to software design and analysis, and I believe we
are only beginning to understand what those benefits might be.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"The whole of science is nothing more than a refinement
of everyday thinking." -- Albert Einstein
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
