"Abraham Lincoln reportedly said that, given eight hours to chop down a tree, he'd spend six sharpening his axe."

I always thought that I was wasting time until I read this one a few years ago.

It didn't stop me from wondering if I am sharpening the axe all eight hours.

The danger is that if I were hired to chop down the tree, I would make the mistake of only billing for 2 hours.

And if I billed for 8 hours, the client would make the mistake of finding someone who would bill for only 2.

"the client would make the mistake of finding someone who would bill for only 2"

Sounds like a self correcting problem. You'd let "someone" have the clients you don't want and end up with only those worth keeping.

Some good stuff here, and some dreck dressed up as profundity, I think. Of course depending on one's position in the software foodchain, what's dreck and what's wisdom might vary.

Tom van Vleck's software quality / Black Death analogy makes all the sense in the world to me while I'm nose-down in the code. To my clients and my managers it's probably worse than gibberish. Conversely, "Deming's 14 points" strike me as meaningless word salad.

And if I could mention one I love that's not on that list: "Premature optimization is the root of all evil." (Donald Knuth)

+1 for the use of the word "dreck" to describe something technical

A couple of thoughts -

> Don't patch bugs out, rewrite them out.

I like this one. But it's only really possible to do that with a fully unit tested application. And when rewriting it out, you'll need a test in place to reproduce the error before actually fixing it.

> If something is worth doing once, it's worth building a tool to do it.

People I work with find me odd for doing little tools that automate things. I find this to be an excellent indicator of how good a developer is and how much I can trust them to develop something for me.

> It is not enough to do your best: you must know what to do, and THEN do your best.

Sage advice. Never thought of it like that, but very insightful.

> when the cart stops > do you whip the cart > or whip the ox?

Don't get it. To place in coding analog, does this mean that people would whip the code rather than the developers of said code? If so, then that doesn't make sense. developers will tend to bear the brunt of any failures of the code they produce. Don't they?

> Don't get it.

Are you working the problem, or simply the most visible symptom?

I'd like to add my own: Software can be developed - it can't be engineered (in the manner of bridges, tunnels, and chemical plants)