On software quality and engineering

[Michael Still]

On Mon, 4 Nov 2002, Martin Schwenke wrote:

> [Mikal, I'm happy to talk about this at CLUG this month, if there's
>  interest.  It has occupied a fair amount of my life...  :-]

I recon the more talks the merrier. Worst case be end up having "break
out" sessions or something...

> 1. Specify your software in a mathematical langauge.
>
> 2. Think of some properties that you'd like your system to have and
>    write them in the mathematical language.
>
> 3. Prove that the specification has the properties.
>
> 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.

> If you understand the mathematics, it is easier to tell whether a
> specification meets the required properties.  However, it may not be
> obvious that the properties have been correctly specified.  :-)

This goes back to the start of the thread though. Most coders are poorly
trained, and hold no actual qualification. I am sitting right now in a
room with 5 VB coders (and 10 C++ coders), and the VB guys have _all_ come
from helpdesk / admin / paper pushing backgrounds.

I suspect having people understand a mathematical proof language is less
important that having them even just understand the language they are
writing in. How many people on the planet can honestly say they
understanding their chosen language(s) fully?

> You've pointed out a large part of the problem here: complexity.
> Software is very complex.  The decomposition is hard.  Most people
> can't keep a very large problem in their head - think of the people
> who are really good at software and you'll probably realise they're in
> the minority who can, and many of them are OSS maintainers for big
> projects.  :-)

I think complexity is the killer.

The commerical project I am working on has about 1,000,000 lines of C++,
and over a million dollars worth of development time per year spent on it.
Even then, with presuably well qualified C++ people, we still have to
impose a code freeze in order to introduce stability in the released
product.

Another example, the linux kernel must have tens of millions of dollars
worth of development time spent on it a year, with real smart people, but
they too need a code freeze to stabilize 2.5...

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.

Mikal

-- 

Michael Still (mikal at stillhq.com)     UTC +10 hours