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

231–237 of 237 posts

Re: When did estimates turn into deadlines?

#231

Post by ben_w »

mmcdermott wrote: post #230
ben_w wrote: post #17

Earlier quoted context omitted.

A friend suggests doubling the number and increasing to the next unit — hours become days, days become weeks, etc. I've certainly seen some environments — plural — where a task that should take 1 hour actually takes 2 days, and one that should take 2 days takes 4 weeks.

> A friend suggests doubling the number and increasing to the next unit — hours become days, days become weeks, etc. I don't know. Going from 8 hours => 16 days seems like quite the markup.

The biggest surprise to me was the project managers and leads who refused the opportunity for going from the big numbers to the small one by allowing a faster development architecture.

Re: When did estimates turn into deadlines?

#232

Post by trashtester »

avidiax wrote: post #216
trashtester wrote: post #176

Earlier quoted context omitted.

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…

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

If all your engineers will make use of most of the slack for such purposes, rather than unproductive activities, you've either been very skillful or very lucky in hiring them (or at least their team leads, etc).

A lot of engineers (myself included) will produce more if there is at least a moderate amount of pressure applied towards delivering something useful relatively soon.

Too much pressure can definitely have the reverse effect, as it introduces more long term technical debt than what is saved in the short term. Also, intermittent period of low pressure can lead to innovation that wouldn't happen if the pressure is always constant.

Still, most tech teams I've worked with will tend to become a bit too relaxed (leading to shorter days, longer breaks, more chatter/social media, etc) if they are presented with delivery dates 1 year in the future for tasks that "feel" like it's only going to take 3-6 months.

Which may very well lead to the task taking 15-18 months instead of the 10-12 months it really takes due to those unexpected complications nobody explicitly thought about.

This also transfers to "agile" development, and in many cases "agile" can make these issues even worse, especially for deliverables that require months to years of effort before anything economically self-sustained can be released. (For instance, if you need to replace a legacy system, the new system isn't delivering net benefit until the legacy system can be shut down.)

Re: When did estimates turn into deadlines?

#233

Post by nikau »

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.

What logic is that based on?

Most devices are just bang bang controlled on or off - so setting to 80 or 72 makes no difference.

Some rare invertor devices may use PID to ramp down as they approach the setpoint, but that's not common.

Re: When did estimates turn into deadlines?

#234

Post by trashtester »

nikau wrote: post #233
trashtester wrote: post #176

Earlier quoted context omitted.

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. What logic is that based on? Most devices are just bang bang controlled on or off - so setting to 80 or 72 makes no difference. Some rare invertor devices may use PID to ramp down as they approach the setpoint, but that's not common.

I'm going to assume we're talking about an oven below, but the principle also applies to AC:

A thermostat attached to a device will measure the temperature near the device, which typically is a bit higher elsewhere in the room, even if the sensor is at the air intake.

Also, even when the air temperature in a room reaches 72F, the walls may still be cold. This means that the temperature experienced by a person in the room will be lower than 72F, since the person will be exposed to less infrared radiation than if the room had been at 72F for a longer period of time.

So, if the goal is to reach a stable 72F (as felt by a human), the fastest way is to turn it to maybe 80F, and then turn it down when the temperature feels about right, or even a bit later (due to the thermal mass in the walls, furniture, etc).

If instead, the the temperature is set to 72F from the start, the oven will start to switch on and off quite freqently as air near the sensor reaches ~72F, and the felt temperature in the room will approach 72F assymptotically.

I live in an old house in a place that can get very cold, and I know this first hand.

Re: When did estimates turn into deadlines?

#235

Post by nikau »

trashtester wrote: post #234
nikau wrote: post #233

Earlier quoted context omitted.

> 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. What logic is that based on? Most devices are just bang bang controlled on or off - so setting to 80 or 72 makes no difference. Some rare invertor devices may use PID to ramp down as they approach the setpoint, but that's not common.

I'm going to assume we're talking about an oven below, but the principle also applies to AC: A thermostat attached to a device will measure the temperature near the device, which typically is a bit higher elsewhere in the room, even if the sensor is at the air intake. Also, even when the air temperature in a room reaches 72F, the walls may still be cold. This means that the temperature experienced by a person in the…

For a large room where the vent is far away from the sensor I can get behind that.

For a fan forced oven, not so much.

Re: When did estimates turn into deadlines?

#236

Post by jen20 »

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…

> But it's politically untenable in the US to fix a broken system in any direction people don't like

It’s not even obvious to me that people don’t like the notion of sane, socialized healthcare. They’ve just been trained not to like the name.

Re: When did estimates turn into deadlines?

#237

Post by fastasucan »

trashtester wrote: post #174
Etheryte wrote: post #80

Earlier quoted context omitted.

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.

Here is an approach for estimation that works pretty well (from the point of view of a manager). 1. Ask the dev team to provide an optimistic estimate, and to then multiply by 2 to make it "realistic". 2. On top of that, add another x2 (which can be recalibrated as you learn how accurate this tech team is over time with estimates). Don't tell the developers about this, but make sure your higher-ups understand that th…

>Ask the dev team to provide an optimistic estimate

Why? They are developers not project managers or staticians.

Post reply on HN