From the article:

> Maybe it is time that users should expect software to be,

> while not "unbreakable" (that’s arguably impossible to

> achieve), at least pretty damned reliable and robust - in

> much the same way that I assume that, when I go to bed,

> the walls of my house will still be there in the morning.

That is exactly how I expect software to be; and it has to be said that most of the time, it is exactly how I find software to be.

If I want to install a package "foo" on one of my servers, I just have to log in via SSH and enter

# apt-get install foo

The files that make up the package will be downloaded for me, along with any other packages upon which "foo" depends, and installed; and then, depending upon the complexity of the package, I may be asked some questions, the answers to which will be used to create basic configuration files {and if I just blindly accept the defaults, the configuration will be as safe as possible}. If the package I just downloaded was a daemon, then it will be started straight away -- and again every boot-up until I decide otherwise.

This, in a nutshell, is the Debian experience. In addition to ease of installation and a vast repository of packages from which to chose, I get the peace of mind that comes from knowing that all the software I am installing has been independently verified by competent programmers working for the Debian project -- I need not take the author's word for it.

If there is ever an important security-critical update which affects a package I am running, I need only enter

# apt-get update && apt-get upgrade

to take care of it.

And if the package I just downloaded doesn't do quite what I want, or does not do it quite the way I want it to, I know that I can modify it -- or get any competent programmer to do that for me.

And this costs not a penny beyond the price of the hardware and the bandwidth used to download the software. Upgrading to a more powerful server will never incur additional "per-processor licencing" costs, nor will adding more users ever incur "per-seat licensing" expenses.

The only real question I have is, why the hell is anyone else doing it any other way?

It baffles me that we, the users, have been prepared to put up with "buggy" software for as long as we have. It's down to the mindset of the developer - it's more interesting to produce new stuff than to get it working.

A classic book on software testing (can't remember it's title, sorry!) had a story about a couple of hardware engineers who put together a little software program to help them with their development and testing. It became commonly used, and as far as anyone could tell, it had NO bugs. When asked how they had managed to achieve this Holy Grail, they said in a puzzled tone, "We didn't know bugs were allowed."

That's the approach developers should be taking, and should have been taking for the last thirty-five years. Bugs aren't allowed.

It's probably too late now.

It's already being done. There's a company called Praxis High Integrity Systems (http://www.praxis-his.com/) who (I'm told - no, I don't work for them!) create software which needs to be completely reliable (think air-traffic control systems) by applying the kinds of theoretical techniques taught in formal programming courses but rarely applied in the real world due to the extra work involved.

As far as I remember, they use a language called SPARK-ADA which is a subset of ADA, but with annotations for pre and post conditions on various blocks of code. There's then a tool which checks that the code ensures the post-condition holds if the pre-condition held when the code was run, etc.

Rather them than me, but still, nice to know someone's trying!

I met Praxis at a BCS seminar some time ago and was impressed by its approach - a hybrid of conventional testing methods and formal approaches. The point it made, iirc, was that it found roughly the same number of defects using testing and formal proof - but that (despite the overheads involved in learning the techniques etc) cost-per-defect-found (for the sort of defects found using proof) was much lower using the formal proof approach. OTOH, using formal methods exclusively was impractical.

The speaker also said that SPARK-ADA was a safe, restricted, subset of ADA - but if you tried to do the same with C there'd be nothing left <g>. In other words, ADA really does have advantages for writing reliable code....

Pan Pantziarka and I wrote an article on this sort of thing for Applicatiion Development Advisor back in 2002, I believe. We still own the copyright, I think, so I might see if we can resurrect it....