[evoltix]

Another thing to note here that I have experienced is when management has an incompetent mentality that, for a given project, that all tasks for this project are created equal. For example, they expect that if task X took 1 hour that surely task Y will also take 1 hour despite the fact that task X and task Y vary greatly in complexity.

[tluyben2]

Explaining the difference in complexity helps, but the problem is that often the programmer doesn't really know in detail besides a feeling that comes mostly from many years of experience. And the best thing is if they then get 'their 10x code slinger' who does it indeed very fast, sends the code back to you and you are stuck with something akin to a broken toilet with diarrhea coming out the sides.

[evoltix]

True. But it does no good if management is dismissive. But that's another problem outside of the topic of estimating.

> And the best thing is if they then get 'their 10x code slinger' who does it indeed very fast, sends the code back to you and you are stuck with something akin to a broken toilet with diarrhea coming out the sides

A grim picture to think about but I find this to be true a lot of the time.

[maxxxxx]

I always have trouble explaining that it took a week to implement 90 percent of the whole project but then it took another 4 weeks to figure out why some little feature failed sometimes. That's my problem with scrum and velocity numbers. It gives clueless people the illusion that they can estimate everything easily.