←back to thread

When did estimates turn into deadlines?

(domainanalysis.io)
317 points alexzeitler | 4 comments | 19 Nov 24 20:03 UTC | HN request time: 1.005s | source
Show context
redleggedfrog ◴[19 Nov 24 22:06 UTC] No.42188611[source]▶
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 on the team needs to take an hour or so and figure out what this is really going to take." Then you'll get asked to "ballpark it" because that's what managers do, and they get a number that makes them rise up in their chair, and yes, that is the number they remember. And then you do your hour of due diligence, and try your best not to actually give any other number than the ballpark at any time, and then you get it done "ahead of time" and look good.

Now, I've had good managers who totally didn't need this strategy, and I loved 'em to death. But for the other numbnuts who can't be bothered to learn their career skills, they get the whites of my eyes.

Also, just made meetings a lot more fun.

replies(14): >>42189183 #>>42189189 #>>42189248 #>>42189402 #>>42189452 #>>42189674 #>>42189718 #>>42189736 #>>42190599 #>>42190818 #>>42191841 #>>42194204 #>>42194310 #>>42200625 #
aoeusnth1 ◴[19 Nov 24 23:27 UTC] No.42189183[source]▶
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 do, they will see right through this.

replies(12): >>42189220 #>>42189233 #>>42189289 #>>42189291 #>>42189444 #>>42189483 #>>42189664 #>>42189808 #>>42191281 #>>42191732 #>>42194145 #>>42194388 #
mewpmewp2 ◴[20 Nov 24 00:40 UTC] No.42189664[source]▶
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 median or average that I expected the task to complete, they are so that I can be 95% sure it's possible to do it and then some.

replies(1): >>42192549 #
rightbyte ◴[20 Nov 24 10:30 UTC] No.42192549[source]▶
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.

replies(1): >>42193808 #
1. mewpmewp2 ◴[20 Nov 24 13:35 UTC] No.42193808[source]▶
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.
replies(1): >>42194109 #
2. rightbyte ◴[20 Nov 24 14:18 UTC] No.42194109[source]▶
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.

replies(1): >>42196698 #
3. mewpmewp2 ◴[20 Nov 24 18:20 UTC] No.42196698[source]▶
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.

replies(1): >>42198089 #
4. rightbyte ◴[20 Nov 24 21:04 UTC] No.42198089{3}[source]▶
I think any process step that resembles a game might be problematic.

And a major problem with group estimates is that given how much knowledge a person has about the code, the effective time will vary so much.

So dunno. I have no experiance as a team lead or manager.

I would probably not track task time at all as a manager. It would give the illusion of insight. Rather some loose percent worked by project per programmer.