|
Estimates for relative comparisons are more justifiable but rarely used, in my experience. And you can't bend on that stuff. The moment you say (to non developers), OK, I'll estimate X for task 1 and Y for task 2 they think, ah ha, if you can do estimates for this you can do estimates for all tasks. Also and I cannot stress this enough, if you can make any estimates at all you're playing on easy mode. If the stuff you're programming isn't entirely rote boilerplate then you cannot estimate anything, ever, because your error rate will be measured in orders of magnitude not multiples. Classic scenario: "how long will task X take?" ... "hmm well there's an open source library that claims to do X here, looks pretty easy to use, so maybe two days?". Some time later: "why is X taking 2 months and not 2 days?" ... "it turned out the library has some non obvious architectural limits we can't fix and which kill performance for our use case, so we have to write our own from scratch". That sort of thing - you thought you could rely on another component and then you can't - can happen at any time, to anyone, and renders all estimates based on the assumed viability of that component meaningless. But you're always building on third party work. If you have absolute confidence in all your dependencies it, again, means you are doing repetitive work that isn't much different from your last task. Such works exists, I guess a lot of frontend dev falls into that category, but it's also highly susceptible to being automated away by better frameworks or AI. >> it doesn’t reflect the way that decisions have to get made in the real world with limited resources. My experience was the opposite actually, the big successful companies do exactly that. They may cancel projects if they seem to be no hopers, but they don't try and estimate up front how much a project will take because they don't think in terms of projects at all. If something is important, it gets staffed until it either stops being important or the team is beaten, at which point it gets unstaffed. If progress isn't fast enough they add more headcount. Everything is thought of in terms of relative resource flows, not timed Gantt charts. |