Hacker News Reader

Comment by pylua | Hacker News Reader

A big problem is that estimates given by developers are never treated as estimates but rather as quotes . If you miss your estimate then your employer may expect you to work extra hours to make up for the gap . Best strategy is to under promise over deliver .

View on HN

I learned early in my career to never give an executive a completion date or time estimate I hadn't thought long and hard about and had full confidence in. They won't remember any of the contingencies you tacked onto your estimate or the additional features they insisted on adding to the project after you talked, but they'll never forget when you said it would be done. It's far better to annoy them in the short term by saying what you'll need to provide an accurate time frame than it is to guestimate something that will bite you later.

Even estimates that are requested explicitly as estimates and not quotes have a tendency to be used for planning other dependencies.

Once other dependencies are scheduled around a estimate, missing that deadline incurs rescheduling costs so no one wants to see it missed.

Some of my biggest arguments as a lead were when I'd sit in one meeting and my team would be promised that these estimates weren't going to be held against them and its just for a rough understanding. Then I'd go to the next meeting where those 'project managers' would be using the estimates to try and plan months into the future, as if those estimates were 100% accurate.

Then when it turns out estimates are out, I'm stuck in another meeting where they melt down about how they're going to explain overruns to their bosses. Utterly predictable madness.

Then they had the nerve to get arsey when we started refusing to estimate.

This is my experience, over and over - to the point where I often get to the point the article states as "just … give up".

Then there's the "let's split it up into pieces first". This is where, instead of rolling one 100-sided die, we flip 100 coins to get a better estimate.

But my absolute favorite is when the Project Manager asks for an estimate and you give a number and if they think it's too high or too low, they will keep asking until you give them the number they were looking for in the first place. Why even ask? Because now it's your fault if it's wrong!

(side note: There are solutions to these things and they are definitely not the right way to do things and are signs of a toxic environment - but there is hope!)

This is part of the reason I refuse to give estimates.

As TFA says, you do get better conversations with the rest of the business if you refuse to give an estimate.

And yet, in my experience, even people who recognize this focus hard to improving estimates and "accountability", but rarely seriously try to reduce dependencies.

I tend to operate on the opposite principle, to the point that I believe it is worth doing substantial amounts of seemingly redundant or throw-away[1] work to turn hard dependencies into soft dependencies. But you have to have both a business organization and a software architecture that can support this.

[1]: Really, "throw-away" just means "temporary", and all our work is temporary—the question is just how temporary.

80/20 rule: “Nothing – and I mean nothing – in IT takes less than 80 hours, and whatever you think it’ll actually take, multiply it by 20, and tell management that. You see, 80/20.”

Nothing would get built if 100% accurate estimates were given. Finance would say it's too expensive and that would be that.

Awesome.

I just found another competitive advantage in my startups.

That's why scrum changed the wording from "estimate" to "forecast". It's more like a weather forecast: you'll often get close, but sometimes it's completely off.

You can give a range - eg 3 to 5 months.

I tried that, and it was almost (but not quite) invariably held to be the lowest of the range, and still construed as a deadline. "3-5 months" becomes "3 months or we have to reschedule other stuff".

Reply on news.ycombinator.com