Rapid Development - Classic Mistakes Enumerated
Classic Mistakes Enumerated
Some ineffective development practices have been chosen so often, by so many people, with such predictable, bad results that they deserve to be called "classic mistakes." Most of the mistakes have a seductive appeal. Do you need to rescue a project that's behind schedule? Add more people! Do you want to reduce your schedule? Schedule more aggressively! Is one of your key contributors aggravating the rest of the team? Wait until the end of the project to fire him! Do you have a rush project to complete? Take whatever developers are available right now and get started as soon as possible!
Developers, managers, and customers usually have good reasons for making the decisions they do, and the seductive appeal of the classic mistakes is part of the reason these mistakes have been made so often. But because they have been made so many times, their consequences have become easy to predict, and they rarely produce the results that people hope for.
This section enumerates three dozen classic mistakes. I have personally seen each of these mistakes made at least once, and I've made many of them myself. You'll recognize many of them from Case Study 3-1.
The common denominator in this list is that you won't necessarily get rapid development if you avoid the mistake, but you will definitely get slow development if you don't avoid it.
If some of these mistakes sound familiar, take heart. Many other people have made the same mistakes, and once you understand their effect on development speed you can use this list to help with your project planning and risk management.
Some of the more significant mistakes are discussed in their own sections in other parts of this book. Others are not discussed further. For ease of reference, the list has been divided along the development-speed dimensions of people, process, product, and technology.
People
Here are some of the people-related classic mistakes.
#1: Undermined motivation. Study after study has
Some ineffective development practices have been chosen so often, by so many people, with such predictable, bad results that they deserve to be called "classic mistakes." Most of the mistakes have a seductive appeal. Do you need to rescue a project that's behind schedule? Add more people! Do you want to reduce your schedule? Schedule more aggressively! Is one of your key contributors aggravating the rest of the team? Wait until the end of the project to fire him! Do you have a rush project to complete? Take whatever developers are available right now and get started as soon as possible!
Developers, managers, and customers usually have good reasons for making the decisions they do, and the seductive appeal of the classic mistakes is part of the reason these mistakes have been made so often. But because they have been made so many times, their consequences have become easy to predict, and they rarely produce the results that people hope for.
This section enumerates three dozen classic mistakes. I have personally seen each of these mistakes made at least once, and I've made many of them myself. You'll recognize many of them from Case Study 3-1.
The common denominator in this list is that you won't necessarily get rapid development if you avoid the mistake, but you will definitely get slow development if you don't avoid it.
If some of these mistakes sound familiar, take heart. Many other people have made the same mistakes, and once you understand their effect on development speed you can use this list to help with your project planning and risk management.
Some of the more significant mistakes are discussed in their own sections in other parts of this book. Others are not discussed further. For ease of reference, the list has been divided along the development-speed dimensions of people, process, product, and technology.
People
Here are some of the people-related classic mistakes.
#1: Undermined motivation. Study after study has