Why is software so buggy?

From iGeek
Revision as of 14:37, 16 June 2019 by Ari (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Why are programs so buggy? They're not bugs, they're features... sorry, that's an old programmer joke. Everyone has problems with their programs (software), it crashes, stalls, or does unexpected things. People ask about these "bugs", why are there so many, and what can they do about it. Hopefully this helps you understand why.

Programming is actually pretty easy, you just tell the computer in very explicit detail what to do, and the computer runs through each line, doing exactly what you tell it. Most of the instructions are simple, but the problem is the sheer magnitude; an average program can have tens or hundreds of thousands of these instructions that all inter-related and work together, or sometimes don't quite work together in the way that is expected.

Piled on top of this is that these programs are written by dozens or hundreds of other people, all doing the same, and talking with other programs that are equally as big (or bigger), like the Operating System that runs the computer, which often have millions of lines of code of their own, along with their own bugs. And a single mistake anywhere can cause bizarre things to happen, just about anywhere else. And the process of finding bugs (after the fact) can be very complex and time-consuming because there are just too many possible causes for any bug or unexpected behavior. You also have many people adding features over years (or decades) and very few get the time to remove stuff or clean it up: just layers over layers -- with the language, techniques, and hardware all changing underneath. So things that made sense and worked 10 years ago, might not continue to work on the latest stuff today.

To give you an idea of the scale, there are more parts in the average program (by far) than there are in the average car and probably the average airplane. And the solutions to design and engineer machines are much better and more mature than those for creating programs. And while you have hundreds of engineers working on designing and building a car and there are many more people testing each function in the car; you often only have a few working on the average program.

Then you have the people issues. Computers have made it so easy to "create things", that many organizations think they can do it well. And usually, the engineers or people that understand and care the most about the software have the least control in organizations with business and marketing people making all the decisions for engineering. This cost lives in mechanical engineering, so happens less; but in software it only causes bugs, so happens more.

Then the economic pressures kick in.

Management always wants more, faster - which, to them, means cheaper. It takes programmers a lot of time to test each possible path that code can go in, in order to prevent bugs. So when the schedules get tight, programmers test less, and thus find fewer of the bugs and leave more for others (often users) to find. Ironically, bugs found by users cost companies far more than it does to prevent them - but the managers shipped the project sooner, so look better. Programmers dont' like shipping shoddy products, but management wants to make money and so has to rush products out.

To compound this, companies often get paid to support and upgrade their software. So if they have bugs in their software, they are rewarded with people buying upgrades or support agreements to fix those bugs; and in fact, if you call in for a bug, they usually ask you if you are running the latest versions of the software, and if not, to upgrade first. In other industries this is known as extortion or planned obsolescence, in software, it is called the norm.

So sadly, the reasons that bugs exist, is because partly because of the magnitude of the problems; and mostly because of market realities. Bugs exist because customers will buy buggy software, tolerate it, and even pay more for upgrades to fix them (which introduce more bugs). In the few sub-industries where software really matters (bugs could cost lives), the code is thoroughly tested, and very few bugs get through, but your Operating System, spreadsheet, database or word-processor just aren't that important to those who have the say. Unless bad management is punished and good management is rewarded, and unless consumers vote with their wallets and send back buggy software, then this is not going to change.

Written 2002.03.11