OK, just so you know, I read it. On Saturday 12 November 2005 07:52 pm, Gregory Woodhouse wrote: 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 -- Nancy Anthracite ------------------------------------------------------- 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
