Software Reliability Quotes

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.

Beware of bugs in the above code; I have only proved it correct, not tried it.

Yet, I am convinced that there is a need for high quality software, and the time will come when it will be recognized that it is worth investing effort in its development and in using a careful, structured approach based on safe, structured languages.

I've noticed that just about every time I find a large program with known glitches that no one seems able to fix, that program is written in C and is likely written by a programming team in a remote location.

All software sucks.

If I say I've got two versions of Word - that old one from 1982 that's perfect, with zero defects; or the new one that's got all this cool new stuff, but there might be a few bugs in it - people always want the new one. But I wouldn't want them to operate a plane I was on with software that happened to be the latest greatest release!

I'm never fully satisfied with any Microsoft product.

Frequently, crashes are followed with a message like 'ID 02'. 'ID' is an abbreviation for idiosyncrasy and the number that follows indicates how many more months of testing the product should have had.

Agitator and the Agitar Management Dashboard lower the barriers to accountability in software development and increase the value of developer testing.

When you develop software, the people who write the software, the developers are the key group but the testers also play an absolutely critical role. They're the ones who ah, write thousands and thousands of examples and make sure that it's going to work on all the different computers and printers and the different amounts of memory or networks that the software'11 be used in. That's a very hard job.

Microsoft knows that reliable software is not cost effective. According to studies, 90% to 95% of all bugs are harmless. They're never discovered by users, and they don't affect performance. It's much cheaper to release buggy software and fix the 5% to 10% of bugs people find and complain about.

I think it's a combination of technical and social factors that leads to all the defects in deployed software.

There is a strong movement towards increased accountability for software developers and software development organizations.

Defect-free software does not exist.

I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

With software products, it is usual to find that the software has major 'bugs' and does not work reliably for some users... The lay public, familiar with only a few incidents of software failure, may regard them as exceptions caused by exceptionally inept programmers. Those of us who are software professionals know better; the most competent programmers in the world cannot avoid such problems.

The problem is, we're moving to software-as-service, which can be yanked or transformed at any moment. The ability of your PC to run independent code is an important safety valve.

There's an old maxim that says, 'Things that work persist,' which is why there's still Cobol floating around.

In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.

And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies.

As you get to the end of the project you want to run all the tests cases against one version and make sure that you know that that version passed everything. And so as you get late in the project you get a little more conservative about making radical changes to the software.

In a previous life I wrote the software that controlled my physics experiments. That software had to deal with all kinds of possible failures in equipment. That is probably where I learned to rely on multiple safety nets inside and around my systems.

Software breaks before it bends, so it demands perfection in a universe that prefers statistics.

When someone builds a bridge, he uses engineers who have been certified as knowing what they are doing. Yet when someone builds you a software program, he has no similar certification, even though your safety may be just as dependent upon that software working as it is upon the bridge supporting your weight.

However, writing software without defects is not sufficient. In my experience, it is at least as difficult to write software that is safe - that is, software that behaves reasonably under adverse conditions.