A lot of ink has been spilled on this topic.
The solution is simple: get better at estimating.
Software engineers act as if they're the only ones in the world who are asked to estimate and then held accountable.
It's a skill issue.
replies(6):
The solution is simple: get better at estimating.
Software engineers act as if they're the only ones in the world who are asked to estimate and then held accountable.
It's a skill issue.
Maybe. Sort of. Skill hints at the problem, but it's more of an experience issue. More experienced developers can give pretty reliable estimates for work they've already done. The catch is, how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it.
So where does that leave us? Well, developers who've seen a lot of different problems recognize when a new problem they see rhymes with a problem they've solved before. That can allow for a very good estimate. But even then, engineers tend to think in terms of best case, or maybe even typical case. I saw a study on this a few years ago, and it showed how often engineers tended to cluster around the median time for solutions. But, since really long tasks, with big error bars have a tendency to really skew timelines, the solution averages was much farther from these median times.
Believe it or not, lawyers have this problem too. They are taught in law school to come up with an estimate based on expected effort, then they apply a formula similar to: double the estimate, then increase the time units. So a 5 hour task becomes 10days. A 2 week task becomes 4 months. Mind you, this isn't the amount of billable hours they're predicting, it's the amount of calendar time that a given task will take until it's complete. This ends up taking into account a lot of variables that lawyers have no control over. Things like court scheduling, or communication delay. I suspect it also takes into account blind spots we humans have around time estimates in isolation. Like, 1 task, if you can focus on it can be done in so many hours. But if you have to do 5 similarly sized tasks, it takes more than 5 times as long, simply because it's easy to expend resources like brain power, and the estimate ignores the refractory periods necessary once the task is completed. (BTW this was one of the problems with the very first stop watch study in the rail yard, where the rail workers didn't work at their sustainable pace, but worked at their depletion pace).
It's still a "skill issue" but it's more about knowing how long it will take you or your team. If you don't have the relevant experience with the tech or with the team, you can't really gauge how long something will take.
Before I estimate larger projects I always ask who will be on my team. The estimate is very different depending on the answer.
I heard someone summarize this as saying, a surgeon may perform the same surgery over and over for decades, while if a programmer does something more than a few times, it becomes an app (or library, etc).
In a sense, unless we are building the same thing we've built before, we are, by definition, always operating at the limit of our abilities.