How To Prevent Software Bugs

May I offer a silly and simplistic answer to the question, "How do you prevent bugs?"...
==> You have to want to.

Management understands that a bug-free product is almost worthless because...

1) People would be able to use it without tech support thus eliminating that cash flow.

2) People would also be much slower to upgrade since most upgrading is done in the desperate hope that the worst bugs in the older product will be fixed. They are often enough but, of course, new ones are introduced. No upgrades, again no cash flow.

Now developers seldom are in on this strategy. Instead they scream and struggle mightily with impossible deadlines, limited resources and mindless orders for more unique features. All of these are, of course, designed to insure those highly valuable defects.

No one wants to do "a bad job" so management can't come right out and say all this. Instead they choose to sacrifice the health and sanity of some of the brightest, most productive and most self-motivated people on the planet. People who become the workplace equivalent of "cannon fodder". Their careers die as they either totally burn out from the impossible stress and long hours of fighting a battle they can't win or they switch to something else before it's too late. The owners and managers are the only people in the equation that can possibly "do a good job" and thus feel good about themselves, since their jobs are to make the most money possible from the business.

Most, if not all, experienced programmers are dissatisfied with the poor quality of today's software. This forum and many like it are admirable attempts to work together to find solutions. Pragmatic Programming and many other process improvement techniques drive the state-of-the-art in software design..... which management must then find new ways to thwart in order to keep the company in business.

We've known for decades how to prevent bugs. It's not brain surgery.
Several characteristics are:

1) Design from the top down and build from the bottom up. Never use any module (I use "module" generically to mean any identifiable block of code... variously called "method", "procedure", "function", "macro", etc.) that is not 100% reliable. To do so absolutely guarantees the module being written is unreliable and there is no way to fix it. The defect incidence grows exponentially from there.

2) Do not allow any module to have side effects. Side effects cannot be documented sufficiently to make them fully known for future work. Thus they are unreliable.

3) Software development is highly non-linear. An "80/20" is far closer to reality than the linear projections forced upon most software projects. If one wanted to produce reliable software (we're not even going for "bug-free" nirvana here), 80% of the development time will be spent on the 20% of the code at the bottom -- the lowest level -- the first modules upon which everything else is built.

4) Large groups cannot produce good software. The only software I've ever seen that approaches "perfection" has always been written by one person alone and thus the ideal group size is -- one. As each new developer is added to a project, the communication and coordination overhead grows exponentially till at 8-10 or more, it exceeds the amount useful work being done. More importantly, it is virtually impossible for it to be accurate or complete enough to prevent defects. 50+ developer teams are ludicrous in my opinion. Teams of up to 10 where each member excels in a different discipline required for the task (i.e. GUI, business logic, database, testing, cat herding, etc.) can work well if the cat herder (leader) is truly a leader and not just a manager (but I digress).

So what are we left with?

We must realize that the commercial software industry as it exists today depends on demoralizing its workers by forcing them to do a bad job. That's reality. Now owners and managers surely never set out to do this, and I would be very surprised if anyone in such a position were not outraged at my assertions since it's pretty much impossible for anyone to believe that what they are doing is not what is "right"... or at least what is "necessary". They should not be blamed for "playing the game" as that is the surest road to success and living to tell your grandchildren about it. However, I don't believe such a system can survive much longer.

Software is a means to an end -- faithfully reproducing intellectual processes faster and more efficiently than humans. The processes are where the value to the business or society is -- not the software. Thus, open-source software would seem to be the best way to get reliable products. The software is usually written by a relatively small group of developers, refined over its life-cycle by a larger group working in a loose coalition or independently, and is free from the demands of continued cash flow and profits.

Perhaps a model will develop where companies use, improve, leverage and produce open-source software to make themselves more profitable and then license it (maybe the previous version) to software distribution and support companies who sell it commercially to other businesses and individuals while providing the sales and modest support operations necessary. That seems viable to me.
[Robert C. Watson on PragProg, 11/20/2004]