- Always deal with emergencies and pressure by other means
In emergencies, favor solutions that are temporary by nature rather than permanent by nature. Computer programs, design choices, and systems are permanent by nature, and rushing to complete them under pressure will convert all of your mistakes into institutions
- The time required to accurately estimate how much time is required to develop a program is equal to the time required to develop that program
Estimates are generated by analyzing the problem and defining its subtasks, and this happens to be the same activity as actually developing the software. All other kinds of estimates are guaranteed to be wrong
- Use deadlines for motivation, not schedules
Break up your schedule into phases and assign due-dates to each phase only when you're near the end of the previous phase. If you assign due-dates for every phase at the beginning then you'll program both laziness and then depression into the system before you've even started
- When writers write, they discover what they actually think. When developers develop, they discover what the customer actually needed
Both conclusions happen near the end of the process, and invariably require going back and starting all over again. Nobody knows what the program should do until it doesn't do it, nobody will know when the program is done until it is
- Thinking is superior to programming
Most development time should be spent trying to figure out a better way of doing what you were about to do. Each phase of a schedule should begin with a Big Think Up Front
|
|