Software Quality
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. - Gerald Weinberg
I'm not sure when this was written, but I first saw it reproduced in the mid seventies. At that time I thought it was funny, but did not appreciate the truth of it. After spending 20 years writing programs I do not think it would require a woodpecker, a strong breeze would be sufficient.
I have heard many times that computer programs are the most complex structures ever built by man. I'm not sure what this claim is based on, but I find it hard to believe. If it were true we would see a lot more software failures than we do.
When Roman engineers built a bridge, they had to stand under it while the first legion marched across. If programmers today worked under similar ground rules, they might well find themselves getting much more interested in Ada! -- Robert Dewar (President Ada Core Technologies)
The Romans did not have sufficiently developed mathematics, physics and material science to be able to determine in advance whether or not a bridge would be able to support a legion marching across it. So the engineer was made to stand under it to demonstrate his confidence in his design. Since the engineer had to stake his life on his bridge not falling, but had no objective way of determining whether or not it would, he was forced to make sure the bridge could not possibly collapse when the legion marched over it, as a result many of these bridges are still standing thousands of years after their construction. I strongly suspect that many of the people who funded the building of these bridges would have preferred to save a few bucks by building a bridge that would have stood for only a tenth as long, but they were not given the option.
True Software Engineering is still a dream, but many tools do exists. For some reason they seem to be universally regarded as being of interest only to academics. Industry shuns them, I have worked on many projects, on only one was a simple Lint tool used. Most professional programmers believe Lint generates too many warnings when run against production code, so they will not use it. Is the problem with Lint, or with the production code?
Why does the software industry shun any of the tools that could move it toward a true engineering discipline? I cannot say for sure, but I can make an educated guess. I think it is because they think it may slow things down. On all projects I've worked on, with only one exception (which was also the one with the most ridged schedule and the one that used Lint), the goal was to ship something, anything, on the ship date. I think most of my managers would have been perfectly happy shipping blank diskettes if they though they could get them past the test team. Many times there were known serious problems with the software, but they did not need to be fixed because the test team had not found them, and hopefully we would ship before they did. This is patently false economy, since it is less expensive to write good software than to fix bad software. But the mindset in American business for the past several decades has been that it is better to spend $100 tomorrow than it is to spend $1 today. We have to maximize quarterly profits, not long term profits.
I heard that in a resent study American consumers were given a choice of a low quality item which cost $1 and would last a year or a similar higher quality item which cost $4 and would last ten years, over 80% of them chose the less expensive item. So writing poor quality software may not be as foolish as it seems, particularly if you can avoid maintaining the software, and can get your customers to pay for an upgrade to fix the defects. If builders could get away with it I'm sure they would rather build buildings like programmers write programs, and sell new buildings to replace the ones destroyed by woodpeckers.
Labels: Programming
