Why Scheduling Estimates Fail
Working to a deadline can be a tricky business. The trouble starts with all the faulty assumptions that go into setting the due date. Given all the variables that affect how long it takes to write a program, who can say whether the estimate is accurate?
In the worst case, the timeline was set by somebody else—a top-down estimate made by an executive or imposed by an impatient client. In the best case, you get to set the schedule yourself, and you can add a little padding for comfort. But even when you set your own deadlines, you'll never have perfect knowledge of the future before undertaking the work, so your estimate can be off the mark.
The problems of setting a deadline are soon followed by all the things that can go wrong along the way to finishing the project. Here are some typical examples:
- You might depend on code written by another engineer, but find that it's more buggy than expected.
- Your interpretation of the requirements might not be in line with the understanding of your supervisor or client, leading to time spent reworking bits and pieces.
- You might have to fight fires on other projects, and thereby have less time available to put toward the deadline you're expected to meet.
On the bright side, a corollary to Parkinson's law sometimes comes into play. Parkinson's law is "Work expands so as to fill the time available for its completion." A corollary would be as follows: If the estimates are at least in the right ball park, most of us are able to adjust and meet the deadline. Of course, this rule assumes that we really want to finish the project, which brings me to another set of problems that crop up when you try to meet deadlines.