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

71–80 of 237 posts

Re: When did estimates turn into deadlines?

#71

Post by jeltz »

dijit wrote: post #22
ahallock wrote: post #13

Working in smaller steps is how you should build software. Constantly get feedback and re-evaluate what you're working on with other members of the team. Instead of giving an estimate, use t-shirt size. With constant feedback, the whole team is participating in the emergent complexity, instead of being passive and just annoying you with "is it done yet"?

but what if I’m working on something meaningful? I can’t MVP my way to a simulation physics engine, when each feature or partial feature requires weeks of planning, testing, iterating and tweaking- privately, before anything can be delivered to be used. Feedback, implies a working widget.

Feedback does not need to be on a MVP, it can be given before that from your fellow engineers. That said there are tasks which really take a lot of research before even fellow engineers can give feedback.

Re: When did estimates turn into deadlines?

#73

Post by Atheros »

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.

Nonsense. Code is copy-pasteable; other things are not.

One can give very accurate estimates of how long it takes to build a brick wall because building brick walls takes time and labor. You can make highly accurate estimates of how long it takes based on how long it has taken to do the exact same task in the past.

But suppose I laid one brick and then could copy-paste it, then copy-paste that into four bricks, then eight, until I have a wall. Then I can copy-paste the entire wall. Once I have a building I can copy-paste the entire building in five seconds.

The ability to copy and paste an entire building is very valuable but how long does it take to create that copyable template? No one knows because it has never been done before.

Re: When did estimates turn into deadlines?

#74

Post by taurath »

eminent101 wrote: post #50
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…

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.

A big problem when you're a more experienced engineer is when you have your hands in a lot of things and know the relative priority of stuff and how likely it is that something else of importance will pop up. So you anticipate things getting sidetracked over time, and try to make a bit of a longer estimate, usually to give yourself the slack to do other important things without looking like you're falling behind in JIRA.

Giving an "if I had nothing else going on" estimate can be a big trap to fall into - they will only see the number and judge your performance based on that. This dovetails into the problem that untracked but still important work being thankless in low trust environments - not all work can ever be tracked, or else the time to track that work would take as long as doing the work. Examples: literally any emotional labor, time to monitor, time to train, time to document when its not explicitly required, time to solve little problems.

In the environment where none of this counts because its not quantifiable, everyone with knowledge makes themselves into a silo in order to protect perceptions of their performance, and everyone else suffers. I'll go even a little further to say that companies that attempt to have no untracked work are by nature far more sociopathic - thus far there's basically no consequences for sociopathic organizations but I hope one day there will be.

Re: When did estimates turn into deadlines?

#75

Post by turbojet1321 »

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.

You're correct to a degree, but IME it's a discipline issue, not a skill issue as such.

What makes software hard to estimate is not so much the work, but how much requirements, priorities and resourcing change on the fly. I've worked in places that did quite strict scrum: once the sprint was planned and agreed to, we pushed back hard on our business area if they wanted to change anything. For practical reasons we didn't outright ban it, but for example, if they wanted something new done "right now" they had to choose something of roughly the same scope to be removed. If they couldn't do that, we'd cancel and re-plan the sprint. They hated having to make that choice, so most things just ended up at the top of the backlog for the next sprint.

The other part was our own management wanting to take people out of the team mid-sprint to work on something else. We never said no, but did say "this means we have to cancel and re-plan the sprint (and tell our business area)".

Basically, we made the people making the changes take responsibility for the impact on deadlines. Our estimates in that scenario were quite good (within the bounds of the sprint, at least).

Of course, the longer the estimation window the less well this works. The only way to estimate accurately is to constrain scope and resources, which is not actually what management/business want.

Re: When did estimates turn into deadlines?

#76

Post by citizenkeen »

bodge5000 wrote: post #46
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…

Always reminds me of this https://youtu.be/8xRqXYsksFg?si=qlG18BB2nNUmt3ub

Knew what this was without clicking on it.

Re: When did estimates turn into deadlines?

#77

Post by Moru »

dsego wrote: post #23
nextworddev wrote: post #6

Multiply your original estimate by 3, works most of the time

Then you get the dreaded can you explain why it takes so long, or I asked engineer xyz and they gave a different estimate, where is the complexity etc.

If you already asked someone, I'm not needed here so I'm going back to work on project Y that already is late enough.

Re: When did estimates turn into deadlines?

#78

Post by Aeolun »

aoeusnth1 wrote: post #45
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…

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…

> In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent.

The manager need to know how to make the estimate to know is bullshit.

If the manager knows how to make the estimate and what it represents, there is no need to inflate it for them.

Re: When did estimates turn into deadlines?

#80

Post by Etheryte »

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.
Post reply on HN