There are two ways to write error-free programs; only the third works.
Each new user of a new system uncovers a new class of bugs.
If McDonalds were run like a software company, one out of every hundred Big Macs would give you food poisoning — and the response would be, “We’re sorry, here’s a coupon for two more.
No matter how slick the demo is in rehearsal, when you do it in front of a live audience the probability of a flawless presentation is inversely proportional to the number of people watching, raised to the power of the amount of money involved.
Law 1: Every program can be optimised to be smaller. Law 2: There's always one more bug. Corollary: Every program can be reduced to a one-line bug.
It's not a bug — it's an undocumented feature.
Any non-trivial program contains at least one bug.
At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.
No one in the brief history of computing has ever written a piece of perfect software. It's unlikely that you'll be the first.
The trick is to fix the problem you have, rather than the problem you want.
“That hardly ever happens” is another way of saying “it happens”.
Without requirements or design, programming is the art of adding bugs to an empty text file.
Not all eyes that notice bugs in Open Source code belong to saints who will report or repair them in the interest of the public good.
Code smells.
If it doesn’t work, it doesn’t matter how fast it doesn’t work.
The standard rule is, when you're in a hole, stop digging; that seems not to apply [to] software nowadays.
The longer it takes for a bug to surface, the harder it is to find.
