Quotes on computer programming to meditate upon.
We should forget about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil.
You're bound to be unhappy if you optimize everything.
The best performance improvement is the transition from the nonworking
state to the working state.
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
If builders built buildings the way programmers wrote programs, then
the first woodpecker that came along would destroy civilisation.
Since human beings themselves are not fully debugged yet, there will
be bugs in your code no matter what you do.
--Chris Mason, Microsoft, "Zero Defects" memo
There is nothing that would make me happier than to fix every bug that
is found during testing before the product officially ships.
Unfortunately, the realities of product development always dash my
happy dreams and I wind up taking a lot of aspirin. I don't care what
model of software development you use -- waterfall, spiral, eXtreme,
or otherwise -- the process of shipping a piece of software boils down
to the same thing: trying to control chaos.
--Joe Bork, Microsoft software tester, "The anatomy of a bug", Oct 2003
What is a good module? That's hard to say. What is good code? That's
also hard to say. "Quality" is not a well-defined term in
computing... and especially not Perl. One man's Thing of Beauty is
another's man's Evil Hack. Since we can't define quality, how do we
write a program to assure it?
Kwalitee: It looks like quality, it sounds like quality, but it's not
--CPAN Testing Service (quoting Schwern)
Measuring programming progress by lines of code is like measuring
aircraft building progress by weight.
It's not finished until it's documented.
--This may originally have been said by Tom Limoncelli.
Documentation isn't done until someone else understands it.
--Originally submitted by William S. Annis on 12jan2000.
Good code is its own best documentation. As you're about to add a
comment, ask yourself, 'How can I improve the code so that this
comment isn't needed?' Improve the code and then document it to make
it even clearer.
--Steve McConnell, "Code Complete"
If the code and the comments disagree, then both are probably wrong.
--attributed to Norm Schryer
Incorrect documentation is often worse than no documentation.
Any code of your own that you haven't looked at for six or more months
might as well have been written by someone else.
Good programmers use their brains, but good guidelines save us having
to think out every case.
Just because the standard provides a cliff in front of you, you are
not necessarily required to jump off it.
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
--Brian W. Kernighan
There are two ways to write error-free programs; only the third works.
--Alan J. Perlis
There's no such thing as a temporary fix.
--Originally submitted by David Todd on 21dec99
There are only two hard problems in Computer Science: naming things
and cache invalidation.
Testing by itself does not improve software quality. Test results are
an indicator of quality, but in and of themselves, they don't improve
it. Trying to improve software quality by increasing the amount of
testing is like trying to lose weight by weighing yourself more
often. What you eat before you step onto the scale determines how much
you will weigh, and the software development techniques you use
determine how many errors testing will find. If you want to lose
weight, don't buy a new scale; change your diet. If you want to
improve your software, don't test more; develop better.
--Steve McConnell, "Code Complete"
If testing costs more than not testing, then don't test.
En guise of conclusion
...well over half of the time you spend working on a project (on the
order of 70 percent) is spent thinking, and no tool, no matter how
advanced, can think for you. Consequently, even if a tool did
everything except the thinking for you -- if it wrote 100 percent of
the code, wrote 100 percent of the documentation, did 100 percent of
the testing, burned the CD-ROMs, put them in boxes, and mailed them to
your customers -- the best you could hope for would be a 30 percent
improvement in productivity. In order to do better than that, you have
to change the way you think.
--Fred Brooks, "No Silver Bullet", in "The Mythical Man Month",
paraphrased by Allen Holub