The difficulty of accurate time estimates is not limited to developers. Anyone who's ever ordered food for delivery intuitively knows this, but many people in our industry fail to make that connection. It's the same problem.
The cause of the problem is you make estimates by running a simulation and no matter how complex, the longer the time / the bigger the scale of the project, the more entropy reality will introduce which your simulation did not account for.
Rather than embracing delusion that you can give accurate estimates -- or driving yourself insane trying to reach deadlines you created with incomplete information -- developers should follow the lead of other professions, and when we give estimates make it clear that it is an estimate.
House contractors don't have this problem. Plumbers don't give this problem, and in 2013 even pizza drivers no longer have this problem. Why are we still pulling our hair out trying to give perfect time estimates and follow through on them as though they are gospel?
Here's my rules of time estimates:
1) Under promise, over deliver. Be conservative in your estimates (that means expect it to take longer than you initially think.)
2) Make it clear to whoever this estimate is for that it is only an estimate, and that it is only good for the current parameters of the project. As problems come up, and when the paramters change, the estimate will become insufficient.
3) Don't treat them like gospel. If you do a good job of setting up expectations, sometimes you will finish ahead of "schedule", and unfortunately no matter your best efforts, sometimes you will finish behind. That's OK. This is reality, not a simulation. Things aren't perfect. If you're working with someone who says it's not ok, stop working with that person in the future.
The cause of the problem is you make estimates by running a simulation and no matter how complex, the longer the time / the bigger the scale of the project, the more entropy reality will introduce which your simulation did not account for.
Rather than embracing delusion that you can give accurate estimates -- or driving yourself insane trying to reach deadlines you created with incomplete information -- developers should follow the lead of other professions, and when we give estimates make it clear that it is an estimate.
House contractors don't have this problem. Plumbers don't give this problem, and in 2013 even pizza drivers no longer have this problem. Why are we still pulling our hair out trying to give perfect time estimates and follow through on them as though they are gospel?
Here's my rules of time estimates:
1) Under promise, over deliver. Be conservative in your estimates (that means expect it to take longer than you initially think.)
2) Make it clear to whoever this estimate is for that it is only an estimate, and that it is only good for the current parameters of the project. As problems come up, and when the paramters change, the estimate will become insufficient.
3) Don't treat them like gospel. If you do a good job of setting up expectations, sometimes you will finish ahead of "schedule", and unfortunately no matter your best efforts, sometimes you will finish behind. That's OK. This is reality, not a simulation. Things aren't perfect. If you're working with someone who says it's not ok, stop working with that person in the future.