Live data from Hacker News

When did estimates turn into deadlines?

domainanalysis.io

61–70 of 237 posts

Re: When did estimates turn into deadlines?

#61
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 literally impossible to know what you don't know. Sometimes you discover things in the process of your work that couldn't have reasonably been accounted for on first estimate, and it is not good practice to always give an estimate that assumes a 5x difficulty multiplier for some unforeseen reason.

Yes, if this is an "every time experience" then there could be a skill issue or possibly some other undiagnosed or unrecognized systemic factor

Re: When did estimates turn into deadlines?

#63

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"?

Agile pretty much throws out estimating anything bigger than a sprint. Even then, points don’t mean time and velocity can be wild for a mature team.

Re: When did estimates turn into deadlines?

#65

The article is about modernization projects, which have soft deadlines because ostensibly the legacy software is still running while you're developing the replacement. There's always budget pressure, and promises may have been made, and users may be hoping for new features and eliminated frustrations... but if the replacement is a day late, it really wouldn't matter much. Conversely, if you're trying to launch a spac…

One technique is to run the modernization project, but use maintenance of the legacy software to keep the business going. Such maintenance could be for keeping up with hardware changes, OS upgrades, new features, and so forth.

I've seen projects run in parallel like this for 10+ years.

Re: When did estimates turn into deadlines?

#66
Sadly, estimates are a negotiation. Whoever provides a number first generally loses because of "The Wince".

"What's your estimate?" "I'm not sure." "Just ballpark it."

"Well, when would you want it by?"

This is the trap that new managers will fall into every time. If they give you an answer? Bingo. You give them "The Wince":

You suck air between your teeth, and with a frown say, "Oh, that's completely unrealistic. Where in the world did you get that number from??" Then you provide a number that's many multiples higher, or offer a reduced amount of work: "Oh, gosh. We'd only be able to get X feature done in that amount of time, and only if we got lucky and cut feature Y from the other project."

Regardless, whatever you do, don't be the first to provide a number. It takes a little bit to get the feel for it, like poker or buying a car.

Time is money, even in a big corporation. Treat it as such: It's a zero sum game.

Re: When did estimates turn into deadlines?

#67
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.

No, it is a funding issue. Nobody wants to pay software engineers for actually doing prestudies to learn enough to do a proper estimate. They want a good estimate but do not want to pay for it.

Re: When did estimates turn into deadlines?

#68

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

Heuristics I'd learned was "double the time and bump the unit". So: 2 hours -> 4 days, 1 week -> 2 months, etc. (I'm not sure where this turned up, but it's a long time ago, going on three decades.) The other option is to carefully track tasks, relevant dimensions, estimates, and actual performance, and see if there's any prediction modelling which can be derived from that. Problem is that this a classic instance of…

> (I'm not sure where this turned up, but it's a long time ago, going on three decades.)

That means it was 1.5 years (wall clock) ago right?

I like this method.

Re: When did estimates turn into deadlines?

#69
post #27

"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. Thank heavens, reality does not operate like this." That happens all the time with insurance. I'm surprised at the confident tone in "reality does no…

[flagged]

Re: When did estimates turn into deadlines?

#70

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…

Some of the best career advice I got was very early on at my first gig - I had a designer tell me, over a cup of sake, that I should just inflate all my estimates by 60%. 30% to cover the stuff I hadn’t thought of, 30% to cover what they hadn’t thought of.

That sounded insane to me… nearly two decades later, with plenty of remote freelance and full time onsite team experience under my belt… and I fully agree. It’s always going to take significantly longer, and if you pretend it’s not, it’s going to come down on your head, like it or not. Always better to underpromise and overdeliver than the other way around.

Post reply on HN