The Becsta.NET Fourth Rant - Software Quality

Software is such a complex beast these days, it's very hard to release a bug-free software product. Or is it?

What I'm about to do is compare apples to oranges, or more specifically, software to cars. Cars are very complex beasts these days, right? Just look under the hood of one - steel and wires and tubing everywhere under there. When I picked up my new car the dealer lifted the bonnet and said something to the effect: "Don't worry about all of this. All you need to do is check the yellow caps". There were 5 or 6 yellow caps I had to look after - engine oil, radiator overflow tank, front washer reservoir, rear washer reservoir etc, fuse box, etc. Windows is like that - very simple interface, yet under the hood it's all quite complex.

Another similarity is the ease of use of the product. All I need to do is sit in my car, put it in gear, and drive it around. The engine management computer in the car will take care of fuel/air ratios, fuel flow, acceleration whilst in cruise control mode, engine temperature, etc etc etc. Windows is like that - you sit at your computer, and use the buttons to create a document, whilst the OS takes care of housekeeping tasks, freeing memory and disk space, writing stuff to disk, managing viruses and applications etc.

Yet another simillarity is the manufacturing. For a car, they do the research, make a model, do more research, make templates, employ personnel to make the cars, employ robots to do the repetitive stuff, and out pops a brand new car. Software is not much different - they do research, make a model piece of software with basic concepts of the finished product, do more research, make programming templates, employ programmers to do the programming, write scripts to do the repetitive stuff (like nightly compiles), and out pops a brand new bit of software.

So, what makes software so different to cars (apart from physically)? One of the differences is build standards. Software development typically follows a program/alpha build/program/beta build/bug fix/release development lifecycle. It seems to me that software fit for consumption by consumers (me, you, everyone else) is in a constant state of alpha/beta releases - ie not quite fit for human consumption yet. Have a look at Freshmeat, and count the software releases with revisions below 1.0 - there's quite a lot. Microsoft, and open source, applications are constantly buggy and exploitable. We never get a bit of software which is stable and usable.

If a car was manufactured with as many inherant bugs as software products do, people get killed, a big fuss is made of the issue, the car gets blacklisted, the manufacturer gets their ass sued off because they've broken state/national laws, and people refuse to buy it. This doesn't happen to software. At most, the software manufacturer gets some bad publicity in the IT press, they release a bug fix, their marketing department says everything is hunky-dorey and, oh, by the way, we've added extra functionality!

We've somehow managed to legislate away the right to sue the software manufacturer if something goes wrong with their bit of software.

What happens to the software which sits in your engine management computer, controlling your car? What happens to the software which controls your breathing and monitors your heart-rate when you're hooked up to a life-support system in hospital? Have you ever seen a life-support system blue-screen? I doubt it!

Why can't we have the same quality standards across all forms of software - embedded systems, consumer software, server software? Why can't companies get sued for the lost millions in overtime and productivity because a vulnerability in their product allows viruses to bring enterprise networks to their knees?

Which brings us to another question. Why is software becoming more and more complex? I summise the reason to be that, because processors are getting faster and faster, the programmers can become lazier and lazier, bloating the codebase out by inefficient (and buggy) code. The increasing disk space, and increasing CPU speeds, contribute to hide inefficiencies in the codebase. The codebase in the various Windows OS's is increasing exponentially in size for what? Extra functionality? Prettier GUI's?

Lets take the K Desktop Environment for instance. Why is it so big? Because the consumer (me) wants pretty interfaces with lots of features, not bland interfaces like CDE or twm.

When I was in uni, there was profiling software out there (Borland Turbo Profiler rocked) in public land which, when software was run through it, would spit out brilliant statistics, detailing at great length where code was inefficient. This, combined with the fact that processors were quite slow (8086's were running at up to 11Mhz in "turbo" mode) and memory was only 640k to 4Mb, applications were quite lean and efficient at utilising every bit of processor and memory time. Heck - you could get Windows 3.11 on 1.44Mb floppies, and run it on a 386 w/ 4Mb of memory. It had a chunky, but quite usable graphical interface, could do networking, and browse the Internet. Why do we need to have Intel P4/1.5Ghz w/ 256Mb memory to run Windows XP? Is it because they want us all to spend more money in order to upgrade our machines?

Am I the only one who still takes immense pride from producing bits of software which are small, efficient, and usable? Hell, disk and CPU is so cheap now, we may as well unroll all of our loops, stick lots of NOP's everywhere in the codebase, put in functionality and "eggs" which noone will use or view (the excel flight sim comes to mind), and noone will notice, or give a damn.

Until software companies become liable for bugs and security vulnerabilities, we will forever be stuck in the alpha/beta stage, being spoon-fed inferior software.