Joel Spolsky had written this article in August 2000 about software cost estimates and schedules. Some interesting extracts.

[Spolsky] Testosterone-crazed game companies like to brag on their web sites that the next game will ship "when it's ready". Schedule? We don't need no stinkin' schedule! We're cool game coders! Most companies don't get that luxury. Ask Lotus. When they first shipped 123 version 3.0, it required an 80286 computer, which wasn't very common then. They delayed the product by 16 months while they worked to shoehorn it into the 640K memory limit of the 8086. By the time they were done, Microsoft had a 16 month lead in developing Excel, and, in a great karmic joke, the 8086 was obsolete anyway!

He refers to this story of the rise and fall of Netscape by one of Netscape's employees. Extracts from there.

[Zawinski] Why? Because the company stopped innovating. The company got big, and big companies just aren't creative. There exist counterexamples to this, but in general, great things are accomplished by small groups of people who are driven, who have unity of purpose. The more people involved, the slower and stupider their union is.

And there's another factor involved, which is that you can divide our industry into two kinds of people: those who want to go work for a company to make it successful, and those who want to go work for a successful company. Netscape's early success and rapid growth caused us to stop getting the former and start getting the latter.

Make a schedule

13 silver bullets about scheduling (Spolsky)

1. Use MS Excel: (MS Project has too many dependencies)
2. Keep it simple (column and task list based)
3. Features consists of multiple taks
4. Let the programmer make the schedule
5. Pick finegrained tasks: As a rule of thumb, each task should be from 2 to 16 hours. If you have a 40 hour (one week) task on your schedule, you're not breaking it down enough. Time it in hours. Only then can it be considered as well defined.
6. Keep track of original and current estimate for a task: Helps learn from mistakes
7. Update everyday
8. Put items for vacations: Then add the Remaining hours field to estimate time of shipping
9. Add Debugging time: In principle, developers debug code as they write it. A programmer should never, ever work on new code if they could instead be fixing bugs. The bug count must stay as low as possible at all times
10. Add Integration time: Invariably there will be repeated code and parts that need to be cleaned up for the system overall.
11. Add a buffer to the schedule
12. Dont let managers change the estimated time
13. Features are like blocks of wood: You cant shrink features to accomodate them in the time you have. Either include them, or just leave them out for the next release.