Rapid Development

By Steve McConnell (1996)

The effects of individual ability, individual motivation, team ability, and team motivation dwarf other productivity factors.

My Notes


Projects hardly ever make up lost time.

Programmers tend to underestimate their projects by 20 to 30 percent.

I am most opposed to overly optimistic scheduling because it doesn’t work. It doesn’t result in shorter actual schedules; it results in longer ones.


Projects that aim from the beginning at having the lowest number of defects usually also have the shortest schedules.

Given the same set of requirements, developers will create solutions that vary by as much as a factor of 10 in the amounts of code they require… If you’re on a rapid-development schedule, you can’t afford to create a pressure-cooker environment in which people are too rushed to find the solution that is one-tenth as expensive to implement as the others.

Developers derive some of their self-esteem from the products they develop. If they develop a high-quality product, they feel good. If they develop a low-quality product, they don’t feel as good.

If you feel that your developers won’t be able to build a high-quality product in the time available, let the developers come to that conclusion themselves.

User Involvement

In a survey of 8,000 projects, the Standish Group found that the number one reason that projects succeed is user involvement.



When you cut across this set of studies, the bottom line is that among groups with different backgrounds and different levels of experience, there is about a 5-to-1 difference in productivity. Among groups with similar backgrounds and similar levels of experience, there is about a 2.5-to-1 difference in productivity.

Group cohesiveness contributes more to productivity than project members’ individual capabilities or experience.

Make the team responsible for its actions rather than making individuals on the team responsible for their individual actions.