Why Projects Always Take Longer Than You Think

When it comes to estimating tasks as a software engineer, most people usually estimate the time it will take for a series of tasks, total them up, and that’s about how long it will take. Some methods are most sophisticated than others, using average case and safe estimate cases, and totaling those up - but fundamentally, everyone is still working with averages.

The problem that most people run into is that they’re trying to intuitively fit a normal distribution on the length of a task, and pick the average time.

That’s all well and good. If you’re more or less right with your estimations of the average time, your total time will be accurate, right?

Well, maybe not.

The reason is that tasks don’t follow a true normal distribution.

But why?

In a true normal curve, you have a continuous number of possibilities for every option. But with real-world estimation, no task can take less than zero time. So, the probability distribution of a task is bounded by zero. The percentage of tasks that take zero time is zero, and grows from there. However, there is no upper bound on how long a task will take. The percentage of tasks that take infinite time drops to an infinitesimal amount over.

So, when you pick the average, you’re saying, half the time it’ll take longer, and half the time it’ll take less time, overall it’ll even out. But it won’t. The tasks that run short are bounded by 0, whereas the tasks that run long have no bound. Because of this the area of the curve before the 50/50 mark is less than the area after the curve.

You don’t want your average to be the 50/50 mark of when the task will be finished. You want your mark to be the 50/50 of the area, which takes into account the bounding problem.

This number will always be higher than the original.

Which is why you’re always late with your projects.

Or you’re just a slacker.