Live data from Hacker News

When did estimates turn into deadlines?

domainanalysis.io

201–210 of 237 posts

Re: When did estimates turn into deadlines?

#201

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…

I wouldn't advocate "super-inflated" estimates but within reason, there are long-term benefits if you go about it right.

Where I mostly worked, managers cared about deadlines they could tell to external clients, which they really hated to miss. Early on, I didn't realize that, and gave my best guess. If I guessed the correct median, I was missing it 50% of the time, and managers kept getting mad at me.

So I switched to estimates I could meet 90% of the time, and on the slow 10% I worked extra hours to meet my estimate anyway. Managers were happy. If I told them it would be done by Tuesday, it would be done by Tuesday.

But it had enormous benefits beyond that. In almost 90% of cases, I had free time. Sometimes I'd admit to finishing early, but I also used that time to clean up technical debt, automate the tedious parts of my job, or advance my skills. After a while, I could give estimates as short as my old 50% estimates, and still beat them 90% of the time because I'd made my tasks so much easier. Less technical debt also meant the resulting code was less likely to have bugs.

After a while, it seemed to me that all the other devs were overworked and I had it easy. But management gave me raises, and when they got in a jam, I was the guy they called on to bail them out.

Re: When did estimates turn into deadlines?

#202

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…

"then you get it done "ahead of time" and look good"

If you "look good" too often, your estimates will be distrusted. So, just play some videogames and look like you're a genius at estimating.

Re: When did estimates turn into deadlines?

#203

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…

if you need to deal with this, you must present estimates as ranges or distributions. Management needs a value for both concrete, legit purposes like budgets and also for (still legitimate) psychological reasons like building comfort that they know what's going on and they are in control. As you mention, people will anchor on a number and that in a nutshell is how an estimate becomes a deadline. Planning and execution will refine the value right up to the point you ship with a very accurate estimate of "how long do you think this will take?".

Re: When did estimates turn into deadlines?

#204
post #51

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…

> 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. I worked at a place where this management insanity was endemic, which lead to everyone padding all estimates with enough contingency to account for that. Which lad to the design team, and the front-end tea…

> padding out their estimates by 150 or 200% - to avoid the blame storms they'd seen for missing "deadlines".

This is good advice, as devs tend to underestimate.

Re: When did estimates turn into deadlines?

#205
post #191
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…

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 the change might be publicly funded group practices instead of pay per service which has better optics.

Re: When did estimates turn into deadlines?

#206

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…

I'm a junior and practically refuse to give estimates currently because the projects I currently get have no real requirements.

"We'd like to replace an excel table for some calculations with a dialog. Here's the template, how long do you need?" which sounds simple enough turns into:

1- Decypher what the example excel template developed by someone over 10 years even does.

2- Oh, there are actually 10 templates and manual actions that give the end result.

2.5- Oh, btw, we asked an external company about doing this for us a while back and they wanted 1kk euros, crazy right?

3- Oh, we also need to generate, send and track offers via the app with the ability to add comments and upload files related to the offer. We also want the user to be queried about what data he has on hand so that calculations he cannot complete are not offered/he's notified as to what else he needs to proceed.

4- Oh, we also need change tracking/audit logs for everything.

5- Oh, we also need to get data from this place, find a free API and also a way to get data out of this software here.

In comparison to that at my previous job the tasks were way smaller and clearer so I'd essentially give myself deadlines when talking to my manager by saying X and Y should be done by Z, A by B.

The only thing I can think of in this situation is to essentially make internal pseudo contracts regarding requirements but then I'm making a pseudo contract with someone 3 levels in the hierarchy above me who's also the person who can terminate me. It's not like that pseudo contract will be read by anyone besides us so it seems better to display lots of uncertainty. At least if you're senior you have more authority in discussion and don't really have to give a fuck since everyone's looking to hire senior devs + your downgrade is a normal dev position. From junior the downgrade seems to be testing or McDonalds and you get to redo junior.

Re: When did estimates turn into deadlines?

#207
post #137

Earlier quoted context omitted.

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

...which is one of my major (of many) complaints about all "scaled agile" frameworks: the promise is that you put all this planning effort in we won't blow up your plan for the next 4/6/n sprints; you get stability and predictability, and can actually shave a yak or boil the ocean, things that are hard to progress with just a 2 week window. Who has ever seen an org with the discipline to NOT do this? Executives are rewarded for the "action imperative" and quick course corrections. They want big, bankable delivery dates AND agile responsiveness to fundamental goal changes. Good luck.

Re: When did estimates turn into deadlines?

#208
post #84

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.

Ime, as a junior dev/ops person, there is almost always scope creep and adding padding grants you room to account for the new idea your supervisor/ user thought of when being midway into development. As far as I can tell, my supervisor also assumes my estimates should be padded more because sometimes you might need wait on human i/o for longer than planned (holidays/ sick leave/...).

one thing that I like, that can help, is to add explicit things in the spec that it will NOT do. If you keep this "types" of functionality you can shut down a lot of scope creep: "we need to send an email alert after the job is done." gets answered "we can do that in a future iteration because this says the feature will not include any alerting or notifications, just log to a file and finish".

Re: When did estimates turn into deadlines?

#209

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

Yeah, it would certainly be cheaper if those uppity poors just died instead.

[deleted]

Re: When did estimates turn into deadlines?

#210
post #133
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…

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?

Post reply on HN