When did estimates turn into deadlines? • Hacker News Board

Re: When did estimates turn into deadlines?

#211

Post by MichaelZuo » Wed, Nov 20, 2024, 4:19 PM UTC

skeeter2020 wrote: post #205

jprete wrote: post #191

Earlier quoted context omitted.

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…

This is the story in Canada as well, but way more than the very poor, because there are not enough primary care physicians where needed, and not enough people pursue family medicine. Why would you? What med student looks at the prospect of administering a dinky small business on top of actually practicing medicine, pay well but not great, and have zero equity when they retire? So we land in a similar position because…

Yeah it seems partial privatization is inevitable or at least the default outcome, at least in Ontario. No other way out that’s also politically viable to enact.

Re: When did estimates turn into deadlines?

#212

Post by perrygeo » Wed, Nov 20, 2024, 4:53 PM UTC

The problem of estimates as they exist in a "Agile" process - they force decisions to be made when the least amount of empirical data is available. Then once work starts and information starts flowing in, you can't change your estimate. The scientific method is explicitly banned! This is often by design; data-driven decisions are incompatible with management-vibe-driven decisions.

At the very least, you need to do a bit of legwork to gather data prior to giving an estimate. Call it design, call it architecture, call it research, call it proof-of-concept, I don't care. Just stop insisting that decisions be made in a vacuum of data. Real results from running code trumps everything.

To be clear, you can produce software without using the scientific method. You can build anything without a data-driven process. But you get what you pay for. The head-in-the-sand approach ignores valuable information and yields poor quality as a result - it doesn't fit the definition of engineering.

Re: When did estimates turn into deadlines?

#213

Post by ethbr1 » Wed, Nov 20, 2024, 4:57 PM UTC

MichaelZuo wrote: post #210

ethbr1 wrote: post #133

Earlier quoted context omitted.

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…

Wouldn’t a hybrid system make more sense? To only assign blame to people/teams when they’ve guaranteed in writing that it would be so and so, avoiding the downsides. And blaming the process when there were no such guarantees?

The issue with any hybrid system is you have to play the incentives out at scale.

E.g. if blame is assigned when there's a written guarantee, why would anyone ever make a written guarantee?

And not trying to be obtuse, but I've only ever seen blameless cultures work in absolute. Compromises let back in all the nasty mal-incentives you see driving unproductive CYA behaviors.

Re: When did estimates turn into deadlines?

#214

Post by ethbr1 » Wed, Nov 20, 2024, 4:59 PM UTC

heelix wrote: post #196

ethbr1 wrote: post #133

Earlier quoted context omitted.

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

100%. It was an eye opening experience. Felt somewhat akin to running an RCA on "Why do people hide mistakes?" Well, because it's in their self interest to do so!

Re: When did estimates turn into deadlines?

#215

Post by jjk166 » Wed, Nov 20, 2024, 5:16 PM UTC

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…

The big issue is when a manager knows the difficulty of the task but not the context it's being done in. A project may be perfectly reasonable to complete in 4 weeks if it's given the priority it deserves, but I know that I'm almost certainly going to get pulled off to do something else so it's going to wind up taking 12 weeks, and then with a very moderate 33% padding giving an overall length of time of 16 weeks, the manager (who has no visibility to the thing which will pull me away) thinks I'm adding 300% padding. Then they say "surely you can do it in less time if we just don't let you get pulled away" and of course you say "well I've been pulled away from all of the past 27 projects over the last 5 years" and they say "don't worry I'll make sure this time is different."

It's not a lack of technical competence, it's a lack of introspection and managerial soft skills.

Re: When did estimates turn into deadlines?

#216

Post by avidiax » Wed, Nov 20, 2024, 5:34 PM UTC

trashtester wrote: post #176

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…

Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device. Also, many engineering teams WILL take any time given to them. But instead of making estimates and plans into hard deadlines (when facing the engineers), managers can make sure the organization is ready for overruns. And as the estimated complet…

> Setting the thermostat to 80F WILL bring the room to 72F faster than if you set it to 72F on most ovens/AC devices, unless the thermostat is located far away from the device.

The thermostat is meant to be far away. This isn't a valid analogy if the thermostat is measuring the temperature of the heater rather than the room.

> Also, many engineering teams WILL take any time given to them.

Agree, engineering teams are not single-stage heaters. They can make more progress toward the goal by working harder (in the short term), or reducing quality, or reducing scope.

But holding hours/week, quality and scope equal, engineering teams aren't going to implement faster because the deadline is sooner. If there is actual slack in the schedule, they will tend to increase scope (i.e. address tech debt, quality of life improvements, plan better).

It might seem that engineers take all the time given to them because most engineering orgs tend to oversubscribe engineering (which makes business sense, since engineering is expensive).

Re: When did estimates turn into deadlines?

#217

Post by rickydroll » Wed, Nov 20, 2024, 5:54 PM UTC

jprete wrote: post #191

oefnak wrote: post #157

Earlier quoted context omitted.

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…

See "We've got you covered" for an analysis of reallocating current US healthcare spending into a general healthcare program that aligns with your thinking.

https://www.penguinrandomhouse.com/books/690632/weve-got-you...

Re: When did estimates turn into deadlines?

#218

Post by mewpmewp2 » Wed, Nov 20, 2024, 6:20 PM UTC

rightbyte wrote: post #200

mewpmewp2 wrote: post #195

Earlier quoted context omitted.

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

I have thought about how it would be fun to have something where people will either openly or blindly estimate and bid. In practice I might be concerned about few things like introducing too much of a competitive culture within the team. Or it could lead to a place where people get too specialized and knowledge doesn't spread around, since everyone will bid on things they have experience with, and so they will be the only one with that experience, which might hurt in the long run. I couldn't actually imagine doing it in my current team. I think people are diligent anyway, and already work more hours than usually would be required. I find it better to just try to protect each other within the team, to drive everyone making higher estimates.

Also doing bidding for those estimates in addition could mean that there might be strong incentives for a lot of corner cutting for certain tasks, etc. People will value short term gains over long term gains when there's such pressure.

Re: When did estimates turn into deadlines?

#219

Post by redleggedfrog » Wed, Nov 20, 2024, 6:49 PM UTC

bdangubic wrote: post #147

redleggedfrog wrote: post #131

Earlier quoted context omitted.

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

That's an interesting scenario you're proposing.

To answer it personally, which of the two, 7 figure bonus or being fired, it'd be I'd quit. If someone is structuring the development of software based on this premise, then they are going to need a different kind of person than me. But I admit I'm probably an outlier here. I don't really work for the money, and my salary is enough, and I don't like undo pressure.

For arguments sake let's say the 7 figures is $1,000,000. To offer that kind of bonus the project is likely going to be a larger one. And I'm assuming my estimate is determining the deadline, so of course I'm making sure it's something I think I can achieve.

But then there are other significant problems with this structure and the likelihood of meeting the deadline, and, more importantly, generating good code and user experience.

- +5% (in ignoring the -5% as no one cares if you're early unless it creates some sort of QA burden) implies a narrow window. On a 6 month project that is ~6 days. Enough that personnel changes or other uncontrollable factors could lead to a missed deadline. One person getting fed up and leaving would be a huge problem.

- The specification would have to be really clear and agreed upon, since there is much at stake.

- Any changes, scope creep, customer requests, could change the development time, and you'd have to have some sort negotiating buffer built in since there is now so much at stake. Otherwise you're going to get literally everything rejected by the developer as they drive towards the deadline (maybe that's what you want, though).

- Is the result worth having? A focus on a deadline, in my experience, tends to shortchange quality. But maybe the deadline is more important than quality.

- And lastly, if that deadline is missed, or worse, something changes the scope of the project and the bonus is not awarded because that led to the deadline being missed, you're going to have some super pissed developers that will not trust such an arrangement in the future.

I suspect you're talking about situations beyond my pay-grade. I've been a meat and potatoes programmer working in e-commerce and integrations mostly, and we don't see 7 figure bonuses. We certainly have had can't miss deadlines that we mostly didn't miss, but mostly those deadlines were due to external factors (API deprecation mostly), or financial considerations, or lastly, arbitrary deadlines set by management. On the latter, those mostly got missed. But that was to be expected as they were not tied to reality.

And I'd second leetcrews comment below of, "...but it's not a sustainable approach for delivering features". Maybe this scenario works once or twice, but it seems like a terrible way to develop software.

But still, an interesting thought experiment.

Re: When did estimates turn into deadlines?

#220

Post by EasyMark » Wed, Nov 20, 2024, 7:14 PM UTC

dtgriscom wrote: post #141

floren wrote: post #3

Earlier quoted context omitted.

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

I do something similar but I use the Indiana version of 3.2 https://www.mentalfloss.com/article/30214/new-math-time-indi...