When executives ask for an “estimate,” they’re often asking for a commitment or for a plan to meet a target.

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.

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.

Choose your battles. If rapid development is truly top priority, don’t shackle your developers by insisting on too many priorities at once.

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

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

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.

The only way to reduce the variability in the estimate is to reduce the variability in the project.

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.

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.