Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

The Geneva Convention On The Treatment of Object Aliasing

The Geneva Convention On The Treatment of Object Aliasing, Hogg, Lea, Wills, deChampeaux and Holt.

Aliasing has been a problem in both formal verification and practical programming for a number of years. To the formalist, it can be annoyingly difficult to prove the simple Hoare formula {x = true} y := false {x = true}. If x and y refer to the same boolean variable, i.e., x and y are aliased, then the formula will not be valid, and proving that aliasing cannot occur is not always straightforward. To the practicing programmer, aliases can result in mysterious bugs as variables change their values seemingly on their own. A classic example is the matrix multiply routine mult(left, right, result) which puts the product of its first two parameters into the third. This works perfectly well until the day some unsuspecting programmer writes the very reasonable statement mult(a, b, a). If the implementor of the routine did not consider the possibility that an argument may be aliased with the result, disaster is inevitable.

Over the years, solutions or workarounds have been found for aliasing problems in traditional languages, and the matter is seemingly under control. Unfortunately, as described below these solutions tend to be too conservative to be useful in object-oriented programs.

The object paradigm has been sold partly on the basis of the strong encapsulation that it provides. This is a misleading claim. A single object may be encapsulated, but single objects are not interesting. An object must be part of a system to be useful, and a system of objects is not necessarily encapsulated.

posted Sat 15 Nov 2003 in /software/theory | link

SWEBOK: Sink the Slipper

Cem Kaner tears apart SWEBOK, the so-called “Software Engineering Body of Knowledge”.

SWEBOK was created using a strange process. They started with the table of contents of the main software engineering textbooks -- as if there is a strong relationship between software engineering as described in textbooks and software engineering as practiced in the field. From there, SWEBOK developed as delta's from these books. SWEBOK is focused on "established traditional practices recommended by many organizations" and is intended to exclude "practices used only for certain types of software" and to exclude "innovative practices tested and used by some organizations and concepts still being developed and testing in research organizations."

Somehow, we conclude that mutation testing is an established traditional practice that is widely recommended and used, but we exclude scenario testing. We conclude that massive tombs of test documentation are an established traditional practice widely followed, even though rants about bad test documentation are, to say the least, a common theme of comment in the community. And we exclude consideration of requirements analytical techniques (or project context considerations) that might help you make a sensible engineering determination of what types of documentation, at what level of depth, for what target reader, are worth the expense of creating and (possibly) maintaining them.

In the SWEBOK, page IX, we learn that the purpose of SWEBOK is to provide a "consensually-validated characterization." In this, SWEBOK has failed utterly. Only a few people (about 500) were involved in the project. It alienated leading people, such as Grady Booch who recently said (in a post to the extremeprogramming listserv on yahoogroups, dated 5/31/2003)

"I was one of those 500 earlier reviewers - and my comments were entirely negative. The SWEBOK I reviewed was well-intentioned but misguided, naive, incoherent, and just flat wrong in so many dimensions."

[...]SWEBOK says "Clearly, unit testing starts after coding is quite mature, for instance after a clean compile."

This is 100% in disagreement with the practice of test-driven development, which requires the programmer to write a unit test immediately _before_ writing code that will enable the program to pass the test.

I think that test-driven development is the most important advance in the craft of testing of the past 30 years. This, more than any of the other flaws, illustrates the extent to which SWEBOK is blind to modern good practice.

Why does the criticisim cheer me? Because I know there's a certain type of person who laps up this “pious-sounding claptrap, religious doctrine rather than engineering”. Given half a chance they'll use SWBOK to make their students' or engineers' lives a misery...

posted Fri 5 Sep 2003 in /software/theory | link

Copyright (C) 1999-2007 Martin Pool.