Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When did estimates turn into deadlines?

domainanalysis.io

Post reply on HN
Print view View original

181–190 of 237 posts

Re: When did estimates turn into deadlines?

#181

Post by veunes »

ethbr1 wrote: post #87
bigiain wrote: post #51

Earlier quoted context omitted.

> 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…

This is literally the endgame. And the only cure is instead building a company that's tolerant of mistakes while still aspiring to excellence. The one I've worked at which got the closest had a corporate culture that failures were atrributable to processes, while successes were atrributable to individuals/teams. Of course that had its own negative side effects, but on the whole it made the company a lot more honest w…

To shift the focus from blame to improvement is critical for fostering innovation

Re: When did estimates turn into deadlines?

#182

Post by veunes »

Etheryte wrote: post #80
redleggedfrog wrote: post #9

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…

The hallmark of a bad manager who doesn't know they're a bad manager: "Why can't you just give me a number?" Inexperienced managers or people backfilling for someone else I can completely understand, they're not comfortable with the uncertainty they're dealing with. However in any other circumstance I think it's inexcusable.

The irony is that managers who demand certainty often undermine the very trust and collaboration they need to get reliable insights

Re: When did estimates turn into deadlines?

#183

Post by veunes »

jimmydddd wrote: post #85
Etheryte wrote: post #80

Earlier quoted context omitted.

The hallmark of a bad manager who doesn't know they're a bad manager: "Why can't you just give me a number?" Inexperienced managers or people backfilling for someone else I can completely understand, they're not comfortable with the uncertainty they're dealing with. However in any other circumstance I think it's inexcusable.

But you have to remember that the manager is going to be asked for an estimate by his boss. He can't just say some time between "1 day and 10 years." In the real world, you have to be able to give some sort of estimate and help the poor guy do his job.

Managers are often caught in the middle

Re: When did estimates turn into deadlines?

#184

Post by veunes »

intelVISA wrote: post #102
redleggedfrog wrote: post #9

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…

Problem is anything non-trivial can't be estimated: deadlines are useful to timebox the process and keep it accountable with a follow-up to see if it's worth continuing. Otherwise it becomes "just trust me bro" which is equally unfair in the opposite direction.

"Just trust me" approaches can be just as damaging as rigid demands for precise estimates

Re: When did estimates turn into deadlines?

#185

Post by sobkas »

oefnak wrote: post #157
timy2shoes wrote: post #154

Earlier quoted context omitted.

The padding in healthcare is part of the system. One part is to have high prices so insurance can negotiate them down. And for hospitals in particular, prices are padded to subsidize emergency care for the indigent (which they have to provide without regard to ability to pay; thanks Reagan).

How can you not be grateful for that? You don't have money, so you should die? Is that really what you mean?

How about government is paying for treatment of people too poor to pay themselves and everyone is paying their share to finance that spending? And as a bonus everyone else will also get their medical treatment financed this way?

Re: When did estimates turn into deadlines?

#186

Post by rightbyte »

mewpmewp2 wrote: post #97
aoeusnth1 wrote: post #45

Earlier quoted context omitted.

In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks. Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who…

I've been considered high performer everywhere I went, only when I was beginning I usually gave very low and naive estimates, experience has taught me otherwise. Of course it will also depend on who and why I'm giving those estimations to. Usually there are just too many unknowns that higher estimate is justified to avoid having to explain why you didn't make it by certain deadline. The estimates I give are not media…

Ye and this is the problem with management using estimates as deadline.

When I was naive and believed that Agile was not a sinister micromanagement toolkit to mess with programmers, I tried to explain to people that about half of our estimates should overshoot and half undershoot or they are biased and that there should be more overshoots since there is no upper bound on how much time a task can take if the estimate is wrong.

Ye. No. The burndown chart shouls be as straight as possible.

Re: When did estimates turn into deadlines?

#187

Post by bdangubic »

leetcrew wrote: post #153
bdangubic wrote: post #147

Earlier quoted context omitted.

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 g…

in the short term, people will work crazy hours to hit a date if it's the difference between a 7 figure bonus and getting fired. if the estimate is based on devs working reasonable hours, that's a lot of slack built in. I'm sure they hit the date more often than not in your scenario, provided they control most of the dependencies, but it's not a sustainable approach for delivering features. "provided they control mos…

I honestly do not think it is about working crazy hours. perhaps my example can be misunderstood in a sense that if you give someone 7-figure bonus they will inevitably work 20hrs/day if necessary to get there which of course would not mean that they estimated correctly but were off by 12hrs/day :)

as things stand what is my incentive to provide an accurate estimate? if no one can question my estimate and hold me to it (well perhaps they can question it but we as industry have successfully been able to convince everyone that these are just estimates, nothing else...) what is my incentive to be accurate? If like one of the commenters above can say "it'll be 2 to 3 weeks" there is an INSANE difference between 2 and 3 weeks, 33% difference. it's like coming to buy a house and agent says "this house is $200k or $300k but you sign here on the bunch of dotted lines and we'll tell you all about it eventually before you have to cut a check." It is good to be in this industry (and especially if you WFH) - say 2 to 3 weeks, finish in 2 and get a week of working on your wellness (or another job :) )

Re: When did estimates turn into deadlines?

#189

Post by rightbyte »

avidiax wrote: post #19

One trick, if you can get away with it, is to ensure that you are always estimating for a fixed scope exclusive of unknown unknowns. You should not provide an estimate for "feature X implemented", but rather for "feature X engine". If you discover additional work to be done, then you need to add "existing code refactor", "feature X+Y integration", etc. as discovered milestones. Unfortunately, you need that nomenclatu…

> These are the same people that want to heat their home to a temperature of 72F, but set the thermostat to 80F "so it will do it faster".

This usually works though in water based heating systems where the flow in the radiators is proportional to the error in temperature.

In practice it might work for electrical radiators too, as the radiator wont cut off when just the air close to it is warm.

Re: When did estimates turn into deadlines?

#190

Post by genghisjahn »

wolpoli wrote: post #164
Izkata wrote: post #137

Earlier quoted context omitted.

> Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points. Isn't the entire point of a sprint that, once planning at the start of the sprint is over, you can't change what's in it by reprioritizing? All of product's reprioritizing shoul…

In official scrum, the development team could choose to accept substitution. It looks like the GP's case, they are obligated to accept substitution.

After I presented the volatility findings, that changed. Sprints largely had to stay as they were and the team decided what we’d take on after the sprint started. It got better. But the whole sprint/scrum/agile thing is still weird. It can be helpful but in a large org it’s never easy. I hope for further improvement in the area of scheduling/estimation in software development.
Post reply on HN