• Most of our estimates are more like wishes than realistic targets.

  • There is almost always a price to be paid for working toward an unrealistic deadline. That price is most often paid in human terms (reputation, morale, and health, among others), but - as you can see in this story - there is likely a financial price to be paid as well.

  • Screwed together components would be a wonderful way to build software. So would automatic generation of code from a requirements specification. And neither of those, in my view, is ever likely to happen in any meaningful way.
  • Someone building a reusable component is thinking of a particular problem to be solved and trying to determine whether there is some more general problem analogous to this specific one.

  • Reusable component needs to be generalized: it is not enough to show that it solves your problem at hand. It must solve some related problems, problems that may not have been so clearly in mind when the component was being developed.

  • The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves.

  • Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome. Therefore, it is worth adopting new tools and techniques, but only if their value is seen realistically and if patience is used in measuring benefits.

  • Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.

  • Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.
  • Most software estimates are made either by upper management or by marketing, not by the people who build the software or their managers. Estimation is, therefore, done by the wrong people.
  • Software estimates are rarely adjusted as the project succeeds. Thus those estimates done at the wrong time by the wrong people are usually not corrected.

  • Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway.

  • Requirements errors are the most expensive to fix when found during productioni but the cheapest to fix early in the development.

  • Missing requirements are the hardest requirements errors to correct.

  • Software that a typical programmer believes to be thoroughly tested and has often had only about 55 to 60 percent of its logic paths executed. Using automated support, such as coverage analyzers, can raise that roughly 85 to 90 percent. It is nearly impossible to test software at the level of 100 percent of its logic paths.

  • Even if 100 percent test coverage were possible, that is not a sufficient criterion for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent from the execution of a unique combination of logic paths. They will not be caught by 100 percent coverage.

  • Errors tend to cluster.

  • There are tradeoffs between size and time optimization. Often, improving one degrades the other.

  • You can’t manage whay you can’t measure.