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

131–140 of 237 posts

Re: When did estimates turn into deadlines?

#131

Post by redleggedfrog »

bdangubic wrote: post #86
eminent101 wrote: post #50

Earlier quoted context omitted.

So many bold claims in this comment and little to no justification. For what it's worth I've seen pretty much the opposite. I don't know about competent vs. incompetent engineers. But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates.

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 you can respectfully lay these numbers out to a manager in the form of, "This will probably take 1 to 3 days," or for bigger stuff, "2 to 3 weeks", and so on. And the manager can take the sum of all this and say, "The soonest it can probably be done is 3 months, but most likely it'll be 4, with a small chance of a bit longer", or whatever, you get the idea. And then the mangers can set the deadline as they see fit. Now, for some reason, many managers just look at the first number and are done - that's the due date. And then after that they get deer in the headlights treatment, so the worst case becomes the best case. That's on them. If they don't understand that software estimation isn't an exact science they're in the wrong field.

As for software development being special, I really hope that what I've described above is like other engineering disciplines, and we're not special. I don't want to be special, I want to be an engineer, like those who work with aircraft or bridges and what not. I feel like in those fields the concept of estimation is a little more respected. But I'm probably wrong. :^)

I'll mention I've been a professional software developer since the early 90's, not that experience equals veracity. But I've had good success using the system above, and even though the bad managers to good managers was pretty even during that time, the company experienced outstanding success during my tenure (20 years!). In the end, bad managers never last. Good managers, who take reasonable estimates to their superiors, succeeded, where managers who brought "It'll be done July 1st" got doubted because their superiors know it really doesn't work that way.

Re: When did estimates turn into deadlines?

#132

Post by halfcat »

milesvp wrote: post #93
jappgar wrote: post #54

A lot of ink has been spilled on this topic. The solution is simple: get better at estimating. Software engineers act as if they're the only ones in the world who are asked to estimate and then held accountable. It's a skill issue.

> It's a skill issue. Maybe. Sort of. Skill hints at the problem, but it's more of an experience issue. More experienced developers can give pretty reliable estimates for work they've already done. The catch is, how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it. So where does that…

> how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it

I heard someone summarize this as saying, a surgeon may perform the same surgery over and over for decades, while if a programmer does something more than a few times, it becomes an app (or library, etc).

In a sense, unless we are building the same thing we've built before, we are, by definition, always operating at the limit of our abilities.

Re: When did estimates turn into deadlines?

#133

Post by ethbr1 »

likium wrote: post #129
ethbr1 wrote: post #87

Earlier quoted context omitted.

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…

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 productivity boost and agility created by honesty was a huge net win.

Re: When did estimates turn into deadlines?

#134

Post by weitendorf »

cplat wrote: post #124
weitendorf wrote: post #116

> Can you imagine if the insurance company started arguing with the repair shop, asking them—no—telling them that they would only pay the $18,000 and not the additional $20,000 because that was the original estimate? Does that sound ridiculous to you? It does to me, too. No, actually, this sounds quite realistic and in many cases even reasonable. Medical insurance does this literally all the time. Insurance companies…

This is a very good comment and does reflect my experience. As engineers, we're the only people who can estimate something close enough, and it becomes our job to do that while taking into account the risks. Our bad assumption is in thinking that only the final output matters, regardless of when and where it is delivered. Like saying that it only matters if the train arrives at the station, regardless of when it does…

Thank you! And yeah, I think a lot of software engineers miss the forest for the trees in assuming that estimates are "only estimates", in what is implicitly assumed by others (who may not have as much context) when eg communicating dates, and in the assumptions they make regarding constraints that may not actually be constrained (eg the ability to add more people to the project or partially release/launch it with reduced scope, with the remainder to be added later). It's like, people forget that a few weeks of one engineer's time costs their employer tens of thousands of dollars, and that multi-quarter/multi-person projects literally are $1mm-$10mm+ endeavors.

A lot of less experienced engineers also are just bad at estimating and don't do a good job clarifying blockers/risks/etc when participating in planning poker with a scrum master/manager, who may also not be very good at their jobs. Obviously a lot of what I wrote is overkill for "you said this was only one story point but it actually took you two days!" but I think this environment being most SWE's first/only exposure to estimation causes them to take the opposite lesson than what they should (that estimation is awful/bullshit, it doesn't matter if you blow past it/everybody always blows past it, you will be argued with if you estimate something as too high, you are incentivized to excessively overestimate to keep your workload low / prevent people getting angry). But that's really only a productive mindset to have when the stakes are low.

I do think leaders, from executives to managers/tech leads/"scrum masters", should be more in the habit of proving estimates/deadlines for risks and ranges than they are. A lot of the time these things become games of telephone were eg an engineer comes up with a plan with all the risks identified and detailed completion dates, and then their manager converts that into a single date given to the CEO as a reasonable deadline. That said, if you actively communication the current ETA and risks proactively throughout a project you also end up with a convenient paper trial and give people multiple opportunities to correct miscommunication.

Re: When did estimates turn into deadlines?

#135

Post by skirmish »

the8472 wrote: post #49
jph wrote: post #44

Estimates are tricky because different manager roles and different personalities bias toward totally different/incompatible concepts of what an estimate actually means. The author's article is conflating realistic and pessimistic estimates: - Realistic e.g. tech managers and people who favors agile/lean/XP/etc. - Optimistic e.g. sales managers and people who want to promote. - Pessimistic e.g. risk managers and peopl…

Sounds like they need curves (probability distributions), not point estimates.

I once tried to give interval range estimates, the manager said "I cannot work with that, give me a single number". (And when I gave a single number, he said "that is much too long" and tried to negotiate it down to 10 times shorter). Happy to be out of there.

Re: When did estimates turn into deadlines?

#136

Post by magicalhippo »

In my experience, there are two different reasons for why I get asked for estimates.

There's the cases where it's used to roughly schedule work, or to prioritize features. My boss wants to know roughly how much is on our plates, so he can plan for known upcoming work.

Then there's the cases where it's more of a XY situation, where the boss is asking for estimates because in reality they've got a customer on the hook but they won't sign unless we can implement some functionality before go-live, or something along those lines. Typically that'll be a hard deadline, as customer will either have to switch to us or pay another year of licensing, and the boss wants to know if I can deliver.

I try to suss out if it's the latter, and if I'm unsure I will simply ask why they want the estimate.

If that's the case and it'll be a struggle to make the deadline, I'll try to help figure out if we can perhaps solve the core issue some other way. Perhaps a temporary solution that the client can live with for a week or two extra while we finish the proper solution, or perhaps we just simplify our proposed solution, enabling us to leverage existing infrastructure, and that turns out to be good enough for the customer.

Re: When did estimates turn into deadlines?

#137

Post by Izkata »

genghisjahn wrote: post #101
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…

What helped me was to track Sprint Volatility in addition to Sprint Velocity. We had our over all capacity, let's say 40 points and that would go up or down some based on people leaving the team, joining the team, etc. It's just an average of how much a team can get done in a given sprint. Velocity was gauged as points per person per day. Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket ou…

> 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 should be in the backlog, not the sprint, and only affect what the next sprint is going to be, not the current one.

Re: When did estimates turn into deadlines?

#138

Post by jappgar »

halfcat wrote: post #132
milesvp wrote: post #93

Earlier quoted context omitted.

> It's a skill issue. Maybe. Sort of. Skill hints at the problem, but it's more of an experience issue. More experienced developers can give pretty reliable estimates for work they've already done. The catch is, how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it. So where does that…

> how often do you ask an engineer to do something they've already done? The beauty of software, is that you don't solve the same problem over and over, because if you did, you'd automate it I heard someone summarize this as saying, a surgeon may perform the same surgery over and over for decades, while if a programmer does something more than a few times, it becomes an app (or library, etc). In a sense, unless we ar…

That's a narrow view of what surgery entails and also a grand interpretation of what professional programming actually looks like.

Re: When did estimates turn into deadlines?

#139

Post by [deleted] »

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…

[deleted]

Re: When did estimates turn into deadlines?

#140

Post by roenxi »

koyote wrote: post #115
eminent101 wrote: post #50

Earlier quoted context omitted.

So many bold claims in this comment and little to no justification. For what it's worth I've seen pretty much the opposite. I don't know about competent vs. incompetent engineers. But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates.

> 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 issues that might cause it to blow out by 3 months until someone has demonstrated that all the unknown unknowns are also resolved by doing it quickly. That is just basic evidence based planning.

Post reply on HN