On software quality and engineering

[Doug.Palmer at csiro.au]

> 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.

A decent specification will almost always be a declarative statement of what
needs to happen, not how it happens. For example, something which needs to
solve a heat conduction might say that the conduction is governed by the
equation

d^2T   d^2T   d^2T    dT
---- + ---- + ---- = c--
dx^2   dy^2   dz^2    dt

and that this equation is to be solved to a resolution of 10mm and accuracy
of 10^-3% for temperature of a system with a constant heat applied in the
top left corner and heatsinks across the bottom.

If you can find a general purpose translator that can automatically generate
a solution to this from that specification then you're well on the way to a
Field's medal. In the meantime, a designer will have to thumb through
Numerical Recipes in C and come up with an algorithm that generates an
acceptable approximate solution to this problem. It's got to be an informed
choice, since most equation solvers have interesting boundary behaviours --
and the boundaries aren't obvious, solving matrix equations by Gauss-Seidel
iteration goes off the planet if the iteration matrix has a spectral radius
> 1 and finding out what the spectral radius is is an interesting exercise
in itself.

> 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. 

Well yes. But the formal system both gives you a language to think deeply
about the system in and a way of communicating your thoughts. It also
insists that you do so in a way that is unconnected with code hacking,
ensuring that there is less chance that you repeat the same mistakes. The
methods also give you a framework that allows you to ensure that your
software is correct over an entire domain, not just what your test cases
test. If multi-9 percent reliability is what you are after, then you'll
never get there by test cases alone.

> 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). 

It depends what the domain is. For example, many -- if not most -- people
use GUI builders now, rather than hand-code the layout and hookup of the
components. And very few people hand-code in assembly any more. In both
cases, I can remember when the reverse was true.

However, these things are distillations of expertise into what are
effectively expert systems. So I suspect that the hand coding area will
simply move to where there is no expertise yet -- and, therefore, where
people and companies are likely to develop innovation. There's an
interesting question there for open-source, since a great deal of OSS
involves reproducing best practises in well-understood areas. Could someone
develop an OSS code generator? It would take the fun out of it :-)