Live data from Hacker News

When did estimates turn into deadlines?

domainanalysis.io

141–150 of 237 posts

Re: When did estimates turn into deadlines?

#141
post #3
post #2

I learned something important early in my career: the first number you put out will be remembered. Unfortunately it’s often true. People keep saying: "but didn’t you initially say X?" "Sure I did, but I have new knowledge" won't always work. A nasty side-effect is that people who are aware of this shy away from giving you numbers.

> Kirk: Mr. Scott. Have you always multiplied your repair estimates by a factor of four? > Scotty: Certainly, sir. How else can I keep my reputation as a miracle worker?

My rule: list all the tasks, estimate times for each task, add up all the estimates, and multiply the results by π. If you're using unknown technology, use π^2.

Re: When did estimates turn into deadlines?

#142
post #51

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…

> I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. I worked at a place where this management insanity was endemic, which lead to everyone padding all estimates with enough contingency to account for that. Which lad to the design team, and the front-end tea…

That is probably analogous to what happens in the American healthcare sector with physicians/hospitals/insurance carriers/pharma/etc. Each one padding their bills making it horrendously expensive for everyone at the end of the chain.

Re: When did estimates turn into deadlines?

#143

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…

One way to get the point across is by stopping to pretend estimates are precise.

Instead of giving a single fixed estimate, give one with error bars. "3 months, plus minus 4 weeks". Most engineers know their estimates have error bars, but have somehow been bludgeoned into forgetting to mention them.

It's also helpful from the management side - the size of the error bars makes it immediately clear how confident folks are in the estimate. It allows reasoning about risk. It allows things like "OK, currently we have 30% error bars either way - what are the biggest contributors to that? Can we knock one or two of those out when we spend a few days investigating?"

It's beyond me why we, as a supposed engineering profession, are unable to talk about risk, probabilities, and confidence intervals. And that isn't just on managers.

Re: When did estimates turn into deadlines?

#144
When managers refused to accept that we just can't predict the future of the creative work that is software design and implementation.

And that's because their entire existence is based upon money, not results. I've only ever had one good manager, and that was because he knew what he didn't know and accepted that we do and are trying our best.

Re: When did estimates turn into deadlines?

#145
post #140
post #115

Earlier quoted context omitted.

> I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates I have the same anecdotal experience with a possible explanation: Inexperienced engineers often don't see the greater picture or the kind of edge cases that will probably need to be handled ahead of time. I've often had the following type of conversation: Engineer: "I think that would be a day's work" Me:…

> "Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue This is software though, if X has actually been done before then it doesn't need to be done again. It is already done. Task X clearly had the potential to blow out by 3 months, and they are now working on task Y that is similar to X. It is a reasonable position to assume that there are other as-yet-unknown i…

I've always found that finding a similar scope problem and how long it took is the best predictor of how long the new problem is going to take.

Re: When did estimates turn into deadlines?

#146
post #98

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…

Reminds me of Hofstadter's Law: It always takes longer than you think, even when you take into account Hofstadter's Law. We could say, always say it will take longer than you think? Though by this principle, it seems that "overestimates" are likely to be actually accurate? Joel Spolsky wrote about his time estimation software which recorded the actual time required for completion, and then calculated for each person…

I’m more of a Parkinson’s Law person: "Work expands so as to fill the time available for its completion.”

Things take longer but if you over-estimate the project won’t come in significantly any earlier.

Re: When did estimates turn into deadlines?

#147

Earlier quoted context omitted.

I think general problem on HN is that you can't say something "bold" without people going "nuts" - especially when it comes to estimating work. In my experience (been hacking since the '90's before it was cool) great developers are great at estimating things. And these are not outliers, all except 1 great developer I've had pleasure of working with over these years has never been "off" on estimates by any statistical…

You can't make accurate estimates that can be used for deadlines for non-trivial work. You can make educated guesses on how long specific things will take, and it might be a pretty good guess if you've been keeping metrics on your past work, including things like vacation days and other similar disruptions as well, and keeping a team together long enough to have solid institutional knowledge on your code-base. And yo…

your comment is exactly what I am talking about. you actually CAN make accurate estimates for non-trivial works. try to envision this - I hand you a non-trivial assignment to estimate with a condition that if you meet your estimate -/+ 5% you get 7-figure bonus. alternatively if you do not you get fired. after working 30 years in the biz you tell me which of the two is happening for you?

I worked at two places that gave huge bonuses when deadlines were met (based on “estimates”) and wouldn’t you know it sh*t always got done on time and people got paid.

Re: When did estimates turn into deadlines?

#149

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…

One way to get the point across is by stopping to pretend estimates are precise. Instead of giving a single fixed estimate, give one with error bars. "3 months, plus minus 4 weeks". Most engineers know their estimates have error bars, but have somehow been bludgeoned into forgetting to mention them. It's also helpful from the management side - the size of the error bars makes it immediately clear how confident folks…

>It's beyond me why we, as a supposed engineering profession, are unable to talk about risk, probabilities, and confidence intervals. And that isn't just on managers.

Because management quits listening after hearing "3 months," and bad management heard "3 months minus three weeks" and goes "okay 2 months it is".

Re: When did estimates turn into deadlines?

#150

The best estimation system I've seen is to actually BET on the completion date, closest gets a free lunch paid for by other members of the group. Those dates were mostly informed guesses of what would actually happen or go wrong. Importantly this was between friends. Needless to say, they turned out very accurate.

I could see that working well for managers, if they incentivize estimates as biweekly or monthly bonuses going to the most accurate one, and each person gives a detailed estimate of ballpark plus probability of what sorts of things can go wrong and how that impacts the estimate.
Post reply on HN