On software quality and engineering

[Alex Satrapa]

Michael Still wrote:
> On Mon, 4 Nov 2002, Martin Schwenke wrote:
>>It does take longer to write the the software, but the maintenance
>>costs end up substantially lower...  especially if you get yourself a
>>good proof tool...  :-)
> 
> This is actually lectured on in second year of Engineering at UC. I
> haven't seen it used in the field though.

As anyone knows who's sat through Software Engineering 1, formal proof 
is a very burdensome excercise.  The "proof" for:

   x = y + z;

Is almost a page full of Z notation.

The "proof" for:

for(x = 0; x < 10; x++) {
  # stuff
}

is several pages, and the "proof" for:

x = 1;
while(x>0) {
   if (somecondition()) {
     x = 0;
   }
}

is practically impossible (without fully unrolling the loop in Z).

Then you have to prove that your proof is correct! (And that your method 
of proof is correct, etc).

> How many people on the planet can honestly say they
> understanding their chosen language(s) fully?

I'm a Perl programmer.  There is noone who can say that they truly 
understand Perl - not even Larry Wall!

Thus, since no man can claim to understand Perl, I conclude that Perl is 
a Woman - and you can only ever love Perl, not understand her ;)

> I think complexity is the killer.
> 
> ...  we still have to
> impose a code freeze in order to introduce stability in the released
> product.

That's not so much due to the complexity of the product, as much as the 
political environment it's being developed in.  I was building a 
"simple" (chortle chortle) web interface for an RTF -> HTML publishing 
system.  I knew from the start that specifications would change, and I 
knew which specifications were most likely to change - so I wrote those 
pieces to be "general" from the start.  My converter was configured 
using Config::IniFiles (I'm heavily biased towards using that module for 
configuration), and most aspects of the system were tested using the 
Test module.  That was the first system I wrote test-first, and was the 
most fun I ever had.

> How do you get around this? I suspect a lot of the answer is "the unix
> way" anyway. Many small, well tested apps, which integrate together well.

Gee... i always thought "the unix way" meant many applications of 
various sizes that use conflicting mnemonics for their command line 
parameters (eg: "-y" meaning variously "yes to all", "yes to safe 
questions" or "turn on syntax colouring" ;) (and no, I can't remember 
the program which used "-y" for "syntax colouring" and "-a" for 
"affirmative to all safe prompts")

Alex