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

191–200 of 237 posts

Re: When did estimates turn into deadlines?

#191

Post by jprete »

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?

That's a hyperbolic misstatement of the situation on the ground. Poor people use free emergency rooms as primary care instead of paying for primary care physicians. That's a cost disaster no matter what you think should be done about health care. We'd be much better off with actually free primary care for the poor, and it would at least make sense to prevent the emergency room misuse since it's so wasteful. But it's politically untenable in the US to fix a broken system in any direction people don't like, even when it's Pareto optimal.

Re: When did estimates turn into deadlines?

#192

Post by [deleted] »

bdangubic wrote: post #187
leetcrew wrote: post #153

Earlier quoted context omitted.

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…

[deleted]

Re: When did estimates turn into deadlines?

#193

Post by zelphirkalt »

mewpmewp2 wrote: post #105
zelphirkalt wrote: post #100

Earlier quoted context omitted.

You make projections instead of estimates. You split the work that needs to be done into many tasks and project from past experiences. You cannot rely 100% on any estimates either, and all you are doing by demanding estimates is creating stress and making people less productive. The meta work imposed by that in itself will make a project take more time, as everyone will be padding their estimates.

What is the difference between a projection and an estimate?

For more info see: https://www.youtube.com/watch?v=QVBlnCTu9Ms

Re: When did estimates turn into deadlines?

#194

Post by yetihehe »

bdangubic wrote: post #187
leetcrew wrote: post #153

Earlier quoted context omitted.

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'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.

Not really with price, but when I've had my house built, the date was overshoot by about 30% too, because of various reasons, like having to stop for winter because some supplies were late by a week several times or my builders had to help teams at other places from time to time (because other teams were late too), not doing anything at my house sometimes for days. So even when building homes (something they do again and again) you can't really put exact estimates.

Re: When did estimates turn into deadlines?

#195

Post by mewpmewp2 »

rightbyte wrote: post #186
mewpmewp2 wrote: post #97

Earlier quoted context omitted.

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…

Yeah, and even if it is not being done as of moment, there is always a possibility of someone clueless from leadership deciding it is a good idea to check how many story points you have completed by some rough statistical analysis, in which case people who put higher estimates and completed those tickets will look better.

Re: When did estimates turn into deadlines?

#196

Post by heelix »

ethbr1 wrote: post #133
likium wrote: post #129

Earlier quoted context omitted.

Just curious if the processes got tuned/adjusted as a result? And what were the negative side effects?

Absolutely! That was one of the common productive outcomes: this policy / approach is screwed up, and we could do it better. Negative side effects were about what you'd imagine. Some low performers unjustly shielded themselves. Safeguards were overbuilt as proof "something" was changed to prevent a failure repeat. Executive promotion criteria could get squirrelly. Etc. But on the whole, I think the individual/team pr…

The first time I'd seen a blameless post mortem, I thought it was a load of bs, as another organization had just caused the first significant production outage our app had ever had. Convenient... no blame. We went along with the process and it did not take very long to understand how this changed the culture. If someone horked a step on a manual deploy, the real question is why is this not automated. People stopped hiding mistakes - so the old snipe hunts where information to trouble shoot might 'disappear' faded and made it easier to debug and then figure out what could be done better. It helped the business understand that 'running in production' did not mean done.

Ryan, if you are out there reading this - ty.

Re: When did estimates turn into deadlines?

#197

Post by ignoramous »

trashtester wrote: post #174
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.

Here is an approach for estimation that works pretty well (from the point of view of a manager). 1. Ask the dev team to provide an optimistic estimate, and to then multiply by 2 to make it "realistic". 2. On top of that, add another x2 (which can be recalibrated as you learn how accurate this tech team is over time with estimates). Don't tell the developers about this, but make sure your higher-ups understand that th…

> Ask the dev team to provide an optimistic estimate, and to then multiply by 2 to make it "realistic". On top of that, add another x2 ...

Reminds me of: Always Multiply Your Estimates by π (2021), https://news.ycombinator.com/item?id=28667174

> ... scope creep ...

  If you want to know what Tesla does right and most of us do wrong, it's this: they ship something small, as fast as they can. Then they listen. Then they make a decision. Then they stick to it. And repeat.

  They don't make decisions any better than we do. That's key. It's not the quality of the decisions that matters. Well, I mean, all else being equal, higher quality decisions are better. But even if your decisions aren't optimal, sticking to them, unless you're completely wrong, usually works better than changing them.
An epic treatise on scheduling, bug tracking, and triage (2017), https://apenwarr.ca/log/20171213

Re: When did estimates turn into deadlines?

#198

Post by tonyedgecombe »

tivert wrote: post #56
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…

> 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 do, they will see right through this. I think a manager who doesn't know the difference between and estimate and a deadline is one who "[doesn't] know what the fuck is going on," and that's the kind of manager the GP uses this strategy…

I think a lot of them know the difference, they just don't care. The estimate is a tool to beat you with.

Re: When did estimates turn into deadlines?

#199

Post by HelloMcFly »

jappgar wrote: post #126
HelloMcFly wrote: post #61

Earlier quoted context omitted.

It's literally impossible to know what you don't know. Sometimes you discover things in the process of your work that couldn't have reasonably been accounted for on first estimate, and it is not good practice to always give an estimate that assumes a 5x difficulty multiplier for some unforeseen reason. Yes, if this is an "every time experience" then there could be a skill issue or possibly some other undiagnosed or u…

When I cut open my ceiling to fix a plumbing issue I didn't know what I was going to find exactly, but I had a pretty good idea of the possibilities. My estimate for how long the fix would take was pretty close. Software is the same thing. There are unknowns but there aren't unlimited possibilities.

It's a great analogy, but I think it's the kind of analogy that works on the surface and not in the details most of the time due to a) much more codification of practice in construction and b) more "fixed" knowledge of what's likely based on location and build era of the home, whereas software is much more dynamic and often subject to individual whims of developers or management.

Re: When did estimates turn into deadlines?

#200

Post by rightbyte »

mewpmewp2 wrote: post #195
rightbyte wrote: post #186

Earlier quoted context omitted.

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…

Yeah, and even if it is not being done as of moment, there is always a possibility of someone clueless from leadership deciding it is a good idea to check how many story points you have completed by some rough statistical analysis, in which case people who put higher estimates and completed those tickets will look better.

Ye. The manager need to be a programmer and involved in the project to be able to evaluate the participants.

I guess 'estimation poker' is a way to counteract the obvious strategy to coast and look competent.

In poker you can also look good by underbidding your peers and then snatch the easy ones to look good while the scapegoats look bad.

The strategy need some social status or incubent code knowledge relative to the team though, to get the good tasks.

Post reply on HN