On software quality and engineering

[Alex Satrapa]

Simon Fowler wrote:
> Yes, but if you make the specification /complete/, in the sense that
> the design for a piece of physical engineering is complete,

Ick.. Most software specification deals only with form, fit and 
function.  It's usually the case that more fine-grained design isn't 
useful, since the requirements are not fully known before software 
construction is commenced.

Thus many software systems are actually built during the "requirements 
discovery phase" and never leave it.

As Fred Brooks said, "Always plan to throw out the first attempt and 
start from scratch... you generally will anyway".

> Couldn't you translate directly from the mathematics to an
> executable representation, though?

Formal languages like "Z" deal with properties of the thing that is 
going to be built (or the thing that is being tested).  This is similar 
to the test-first approach to software construction.

You describe certain parameters that indicate that the component "works" 
- in the case of Config::IniFiles, for example, one specification goes 
like this:

   # Test 1
   # Multiple equals in a parameter - should split on the first
   $ini = new Config::IniFiles( -file => 'test.ini' );
   $value = $ini->val('test7', 'criterion') || '';
   ok($value eq 'price <= maximum');

Where the "test.ini" file contains:

   ...
   [test7]
   criterion = price <= maximum
   ...

> Being cynical, I can't help wondering if a large part of the
> improvement in quality you get from putting all that effort into
> modelling the system comes from the simple fact that you've just
> spent a long time thinking very deeply about the system.

Thinking about the system doesn't always result in better software. 
Sometimes you make some basic assumptions right at the beginning of a 
software project, only to find 9 months in to a 12 month project that 
you made the wrong assumptions (and usually it's one of the assumptions 
you didn't realise you'd made), and you have to start from scratch.

Putting *some* thought in is usually better than putting *no* thought 
in.  That's why I feel that languages like Java are superior to Visual 
Basic - in Java you have to think at least one step ahead.  In Visual 
Basic, you just copy/paste/modify.

Now, can anyone give me the ISBN for a good reference or tutorial book 
on Z formal proof?