Quotes from Steve McConnell

Don't differentiate routine names solely by number. One developer wrote all his code in one big function. Then he took every 15 lines and created functions named Part1, Part2, and so on. After that, he created one high-level function that called each part.

One of the paradoxes of defensive programming is that during development, you'd like an error to be noticeable—you'd rather have it be obnoxious than risk overlooking it. But during production, you'd rather have the error be as unobtrusive as possible, to have the program recover or fail gracefully.

developers insert an average of 1 to 3 defects per hour into their designs and 5 to 8 defects per hour into code

The goal is to minimize the amount of a program you have to think about at any one time. You might think of this as mental juggling—the more mental balls the program requires you to keep in the air at once, the more likely you'll drop one of the balls, leading to a design or coding error.

When executives ask for an "estimate," they're often asking for a commitment or for a plan to meet a target.

Spend your time on the 20 percent of the refactorings that provide 80 percent of the benefit.

Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor

Try to create modules that depend little on other modules. Make them detached, as business associates are, rather than attached, as Siamese twins are.

Reduce complexity. The single most important reason to create a routine is to reduce a program's complexity. Create a routine to hide information so that you won't need to think about it.

Inheritance adds complexity to a program, and, as such, it's a dangerous technique. As Java guru Joshua Bloch says, "Design and document for inheritance, or prohibit it." If a class isn't designed to be inherited from, make its members non-virtual in C++, final in Java, or non-overridable in Microsoft Visual Basic so that you can't inherit from it.

Building software implies various stages of planning, preparation and execution that vary in kind and degree depending on what's being built. [...] Building a four-foot tower requires a steady hand, a level surface, and 10 undamaged beer cans. Building a tower 100 times that size doesn't merely require 100 times as many beer cans.

few people can understand more than three levels of nested ifs

As Thomas Hobbes observed in the 17th century, life under mob rule is solitary, poor, nasty, brutish and short. Life on a poorly run software project is solitary, poor, nasty, brutish, and hardly ever short enough.

A blanket attempt to avoid mistakes is the biggest mistake of all.

Managing complexity is the most important technical topic in software development. In my view, it's so important that Software's Primary Technical Imperative has to be managing complexity. Complexity is not a new feature of software development.

People who are effective at developing high-quality software have spent years accumulating dozens of techniques, tricks, and magic incantations. The techniques are not rules; they are analytical tools.

It's better to wait for a productive programmer to become available than it is to wait for the first available programmer to become productive.

A brute force solution that works is better than an elegant solution that doesn't work.