Poor Abstractions as a cause of Software Failures

From Software Abstractions - Logic, Language and Analysis by Daniel Jackson (MIT Press, 2006):

The case for formal methods is often based on the prospect of catching subtle bugs that elude testing.  But in practice the less glamorous analyses that are applied repeatedly during the development of an abstraction and which keep the formal model in line with the designer's intent, are far more important.  Software, unlike hardware, rarely fails because of a single tiny but debilitating flaw.  In almost all cases, software fails because of poor abstractions that lead to a proliferation of bugs, one of which happens to cause the failure.

Design by Guesswork

Over at Aftermarket Pipes Tim Lesher has a nice explanation of some strange behaviour of  Windows Notepad.  However, I disagree with him when he says "we can't even blame Notepad: it's a limitation of Windows itself".  The documentation for the IsTextUnicode Windows API call is quite explicit that the call makes an informed guess and might give a wrong answer.  The mistake made by the designers of Notepad was to hide from the user the fact that a guess was being made.  Lesher approvingly quotes Tim Peters'  "In the face of ambiguity, refuse the temptation to guess", to which I would add "but if you have to then don't hide the fact from the user".

This all reminds me of the following story reported by Edsger Dijkstra in EWD 466(pdf) :

...  Niklaus [Wirth] told a terrible story about CDC software.  With 10 six-bit characters (from an alphabet of 63) packed into one word, CDC used the 64th configuration to indicate "end of line"; when for compatibility reasons a 64th character had to be added, they invented the following convention for indicating the end of a line: two successive colons on positions 10k+8 and 10k+9 --a fixed position in the word!-- is interpreted as "end of line".  The argument was clearly that colons hardly ever occur, let alone two successive ones!  Tony [Hoare] was severely shocked: "How can one build reliable programs on top of a system with consciously built-in unreliability?"  I shared his horror; he suggested that at the next International Conference on Software Reliability a speaker should just mention the above dirty trick and then let the audience think about its consequences for the rest of his time slice! ... 

Beware the Optimistic Engineer

At the end of EWD500, an account of how he discovered and then corrected a bug in the On-the-Fly Garbage Collection algorithm, Edsger Dijkstra draws the following conclusion:

... for the design of multiprocessor installations we cannot rely on the traditional approach of the optimistic engineer, who, when the design looks reasonable, puts it together to see if it works.

After having just spent several weeks tracking down and fixing a bug in some multiprocessor software that I wrote myself, I now recognize myself to be an 'optimistic engineer'.  I am teaching myself to use Alloy in order to keep my 'optimism' under control.

The Maya project

I have just come across Piet Hut's and Jun Makino's Maya Project .  The aim of this project is to develop software to perform detailed simulations of star clusters.  Now I myself have quite an interest in star clusters and with my trusty copy of Numerical Recipes to hand I could probably work my way through most of the maths, but, to me, by far the most interesting thing about this project is the decision to document the development in the form of a dialogue between two astrophysicists.  These dialogues cover the astrophysics, the maths and the software development and appear to contain a wealth of information and good advice on program development.  The language chosen for the development is Ruby, which is an  interesting decision in itself (and one which is discussed in the dialogues). 

The development dialogues are included in the Development Series (use the link near the foot of the Maya Project home page).

One thing to note  is that the project used to be called the Kali Project and there are quite a few references to this old name still in existence, in particular, the simulation system that is being developed is referred to as the Kali Code (researchers in stellar structure and evolution refer to computer programs as 'codes' - apparently a term left over from the very early days of computing).

Opening Files in Java

This morning I came across the following statement by Bruce Eckel:

In Java, it's a research project to open a file.

This is remarkably frank for someone who has just published a book on Java!