On software quality and engineering

[Simon Fowler]

On Mon, Nov 04, 2002 at 10:36:04AM +1100, Martin Schwenke wrote:
> >>>>> "Simon" == Simon Fowler <simon at himi.org> writes:
> 
>     Simon> Another point is that if you have the specification in that
>     Simon> formal language, then you effectively /have/ the code - if
>     Simon> the formal language is sufficient to describe the system
>     Simon> completely, then it should be equivalent to the code for
>     Simon> the system. Equivalent meaning automatically translatable
>     Simon> to the code (and hence to the final executable).
> 
> No!  Specifications describe "what" a system should do and code
> describes "how" it should be done.  The process of transforming a
> specification into code is called "design" and that process is
> creative.  You can't (yet? :-) automate creativity.  However, there
> are things like refinement calculi that make the formal design process
> `easier'...
> 
Yes, but if you make the specification /complete/, in the sense that
the design for a piece of physical engineering is complete, then
there really isn't much difference between the spec and the code, in
terms of what it actually defines. And there's certainly not much
difference in terms of the effort involved . . . 

> You can try to write your design in an "executable subset" of a
> specification language, but then you're throwing away a lot of the
> expressiveness that the mathematics gives you anyway...
> 
Couldn't you translate directly from the mathematics to an
executable representation, though? Probably not easily, but that's
what I was thinking of. 'cause if you /can/ make that automatic
translation, you've just defined a new programming language.

> We have the "programming in the small" thing nailed, and have had for
> years, but only for the easily `abstractable' parts of applications.
> This is why there is no excuse for (re)writing a broken version of one
> of the algorithms or data structures that appear in undergraduate
> textbooks.  All of these reusable things are solved and their
> implementations can be proved correct.  What's more, if you use nice,
> high-level (academic, generally poor-performing) languages, the proofs
> get a lot easier.  One problem is that lots of "coders" can't cope
> with the required mathematics or the abstraction in the neat
> programming languages.
> 
Really, though, all that's happening with these languages is that
the small things are being made intrinsic to the language . . .
Moving the complexity to the compiler and the runtime and the
libraries - where they only have to be done correctly once, of
course. So it's improving things, but not by the several orders of
magnitude you'd need to make formal methods practical (I think - I
could easily be wrong about this ;-).

> Some things are harder:
> 
> * decomposing large systems; and
> 
> * talking to complex hardware (without a nice abstraction layer on top
>   of it - yes, I know we're always talking to complex hardware, but
>   usually we don't have to know about it).
> 
> The really hard thing is managing complexity.  Most people are simply
> not good at it, and most of those are "professional software
> engineers".
> 
> One way of managing complexity is to build a model of a system that is
> abstract enough so that it hides enough complexity so that you can
> cope.  You can then reintroduce the complexity when you specify the
> internals of the relevant pieces.  Again, abstraction is hard...
> 
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. That almost
always seems to result in a better system, regardless of anything
else you do. 

But that's probably being too cynical (tempting though it is).
Though it's hard /not/ to be cynical about this kind of thing, given
some of the claims out there (such as being told in a software
analysis and design lecture that anyone writing code by hand would
be out of a job five years from now). 

Anyway, I'm far to lazy to use formal methods, so it's probably a
good thing I don't call myself a software engineer ;-)

Simon

-- 
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS) 
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux/attachments/20021104/902c404d/attachment.bin