Software bugs aren't inevitable

[Ron Adam]

Paul Rubin wrote:
> Steven D'Aprano <steve at REMOVETHIScyber.com.au> writes:
> 
>>But there is a difference: writing assembly is *hard*, which is why we
>>prefer not to do it. Are you suggesting that functional programming is
>>significantly easier to do than declarative?
> 
> 
> I think you mean imperative.  Yes, there is a community that believes
> that writing bug-free programs in functional style is easier than
> writing them in imperative style.  Writing buggy programs might be
> easier in imperative style, but in some application areas, that's not
> good enough.
> 
> Why don't you read the Hughes paper I cited instead of taking cheap
> shots at it without reading it, if you want to understand the issues
> better.


Just some comments from my own experiences concerning bugs and writing 
dependable software.  It pretty much depends on a number of things and 
isn't just a matter of good design or what language is used.

    * The dependability of the hardware
    * The dependability of the OS
    * The stability of the language used
    * The programmers knowledge of the language used
    * Program design
    * How many programmers are working on the same project
    * How many extensions are used and written by other people
    * The stability of those extensions
    * Rate of change of the program design, and all underlying parts.

A small program with no external modules and written by a single person 
can be fairly dependable, or as dependable as the underlying language, 
OS, and hardware.

But as soon as the softwares complexity increases and/or multiple 
programmers are used, either directly or indirectly through third party 
extensions, then the probability of bugs increases substantially.

Given *enough* time, effort, and testing, without changing the design, 
even a large program can be nearly as dependable as the least dependable 
part of the platform it is running on.  ("enough" could be a long time 
here.)

To increase reliability to nearly 100%, you need to run different 
versions of a program on several different platforms simultaneously and 
use only the results that have a majority agreement.

Or to put it another way; risk management by ... "keep it simple", 
"don't have too many cooks", "get second opinions", and "don't put all 
your eggs in one basket".

Cheers,
Ron