[HN Gopher] When did estimates turn into deadlines?
___________________________________________________________________
When did estimates turn into deadlines?
Author : alexzeitler
Score : 67 points
Date : 2024-11-19 20:03 UTC (2 hours ago)
(HTM) web link (domainanalysis.io)
(TXT) w3m dump (domainanalysis.io)
| baxtr wrote:
| I learned something important early in my career: the first
| number you put out will be remembered.
|
| Unfortunately it's often true. People keep saying: "but didn't
| you initially say X?"
|
| "Sure I did, but I have new knowledge" won't always work.
|
| A nasty side-effect is that people who are aware of this shy away
| from giving you numbers.
| floren wrote:
| > Kirk: Mr. Scott. Have you always multiplied your repair
| estimates by a factor of four?
|
| > Scotty: Certainly, sir. How else can I keep my reputation as
| a miracle worker?
| dhosek wrote:
| There's a whole generation of developers who have
| internalized this.
| darekkay wrote:
| > the first number you put out will be remembered
|
| This is called anchoring effect, a psychological bias.
| NikkiA wrote:
| Sometime around 1956 at a guess.
| nextworddev wrote:
| Multiply your original estimate by 3, works most of the time
| loloquwowndueo wrote:
| Montgomery Scott recommends 4 instead.
| ben_w wrote:
| 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.
| rectang wrote:
| Multiply by p -- it's more accurate.
| dredmorbius wrote:
| 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 modelling in
| which the model itself affects the domain (as with economics
| and sociology, contrasted with astronomy and meterology where
| this isn't the case), such that estimates incorporating past
| performance data will incorporate the fact that the prediction
| model is being used.
| dsego wrote:
| 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.
| dspillett wrote:
| > _When did estimates turn into deadlines?_
|
| In my personal experience: the first time I gave what could be
| construed as an official estimate.
| OutOfHere wrote:
| When I give an estimate, I always reiterate that it's just an
| estimate that is based on limited and incomplete information, and
| that the real number can be more or less. If they don't like it,
| they're free to put someone else on the project.
| redleggedfrog wrote:
| 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.
| snakeyjake wrote:
| In 1505 Michelangelo gave an estimate of five years to finish the
| tomb for Pope Julius II.
|
| Due to small side projects like the painting of the Sistine
| Chapel ceiling it took around 40.
|
| Failure to meet the deadline informed by the estimate meant that
| the scale of the project was massively reduced because: Pope
| Julius II had died prior to completion, there were changes
| requested by the customer (both Julius and his heirs), supply
| chain issues, contract renegotiations, labor disputes, shortages
| of qualified workers, and money running out due to the long
| duration of the project.
|
| So, since 1505 at least?
|
| The funny thing is that the pope isn't even interred there.
| ahallock wrote:
| 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"?
| dijit wrote:
| 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.
| caseyy wrote:
| Yes, a lot of managers don't understand that you can't see
| some work on screen immediately. Especially in my corner of
| the industry which is games.
|
| There is this expectation in many game companies now that
| everyone must demo their work on screen every sprint, and it
| works well for artists and designers who run these companies.
| But how do you demo an implementation of a data structure
| with, let's say, pre-caching for fast search? How do you demo
| doing a bug fixing pass on failed functional tests? How do
| you show in gameplay a new Lua function library your game
| designers requested?
|
| So eventually programmers give into this mismanagement. They
| don't do deep systems bug fixes, performance improvements,
| code quality passes or really any code quality work - not
| even code reviews. These things take time and are sometimes
| actively argued against by producers with claims to the
| effect of "if it doesn't make a big impact on screen, it's
| not worth doing". Good luck shipping a game with this... but
| I suppose more than a few AAA companies do count on that
| luck.
| kanisae wrote:
| I normally only commit to "We will give an update in X
| (minutes/hours) to make sure we understand the problem first.
| Then start giving estimated timelines in ranges with specific
| call outs for updates and possible changes to the timeline.
|
| I've found that most management just want to be involved in the
| process and have definite times set for updates and can handle
| timeline changes as long as information is coming at regular
| intervals.
| rogerbinns wrote:
| My technique is to give an estimate with error bars. Something
| like 6 weeks plus or minus 2. That then leads into discussion as
| to what is unknown/undefined leading to the uncertainty.
| Sometimes the error bars are larger than the estimate because I
| know there will be endless feature creep and UI revisions for
| something like "analytics". And sometimes the number could be
| negative like 6 weeks plus or minus 8. That is when the
| functionality already exists (eg the data is already there - you
| can already load it into Excel and a pivot table) and could be
| sufficient.
| dhosek wrote:
| At my very first job out of college,1 the VP who led the
| division that I was part of invited me into his office (I think
| there was someone else from the team, but this is 34 years ago
| so who knows) and talked about a little game he had encountered
| about estimates. He gave us a list of 20 things to estimate
| with 95% confidence (the only one I remember was the weight of
| a 747), all given as a range. If we did it right, we would get
| 19 of the 20 correct. The point was to set the range large
| enough that you could be confident about the answer.
|
| I kept that as a practice when I did freelancing work, always
| giving my estimates as a range rather than a single number. It
| would be nice if agile(ish) practices incorporated this in the
| estimation process.
|
| [?]
|
| 1. Technically, my second job since I had a short temp job
| doing some cataloging work at a local used bookstore between
| leaving school and starting at that company.
| avidiax wrote:
| 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 nomenclature and understanding to go
| up the chain for this to work. If someone turns your "feature X
| engine" milestone into "feature X complete" with the same
| estimate, you are screwed.
|
| ------
|
| There is a related problem that I've seen in my career:
| leadership thinks that deadlines are "motivating".
|
| These are the same people that want to heat their home to a
| temperature of 72F, but set the thermostat to 80F "so it will do
| it faster".
|
| I was once in a leadership meeting, where the other participants
| forgot that I, lowly engineer, was invited to this meeting.
| Someone asked if we should accept that deadline X was very
| unlikely to be met, and substitute a more realistic deadline. To
| which the senior PM responded that "we never move deadlines!
| Engineering will just take any time given to them!"
|
| Engineering, in that case, gave the time back when I left that
| team.
| LeifCarrotson wrote:
| 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 space probe and the
| planets are no longer in the right positions for the required
| gravity assist, your spacecraft will not get where it needs to
| go. Or if you're a little $100M/yr toolmaker, and Ford asks you
| for a die for the 2026 F150 production line, to be delivered by
| March, and the contract states you owe a $20,000 per MINUTE
| penalty if you're late...you don't wait until February to say
| something surprising happened and it's not going to be ready. You
| don't sign on that dotted line unless you know for certain that
| you can do it.
|
| Ford or NASA won't bat an eye when you tell them that a quote is
| going to cost $XX,XXX. They won't be surprised when they give you
| an ECO and you say that it's going to take 3 weeks and $8,000 to
| deliver a part that everyone knows you can probably make by hand
| in 30 minutes, they know that you're hedging against those
| deadlines, and pricing in the acceptance phase and inspection
| phase and contingency plans and everything else that makes their
| deadline-heavy industry function.
|
| But if you tell someone at OP's modernization group that due to
| incomplete information you think that the 30-minute task to
| change the text of that button will take "no more than 3 weeks
| and $8,000" they'll laugh you out the door. Optimistic estimates
| get rewarded, pessimistic estimates get discouraged, accurate
| estimates are irrelevant, and in the end you're constantly behind
| schedule and no one's really surprised.
| tartoran wrote:
| Not only that, in the name of efficiency where I work estimates
| are actively being pushed down and no spillovers are allowed.
| I've been in crunch like mode for over a year with no
| recuperation at all. I kept on hoping it will get better but it
| seems it's getting worse. On top of it we're all rotated to
| different areas of the product all the time with no recourse.
| Though I'm still running along I feel absolutely spent
| mentally...
| tyingq wrote:
| _" 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 not operate like this"_. Not
| just car/home insurance either...health insurance also. They do
| often negotiate to a reasonable place, but not always.
| kelseyfrog wrote:
| > 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?
|
| Well yeah, because there's not an inherent power imbalance like
| there is in employment.
|
| Part of this imbalance results in the ability for managers to
| employ Taylorization upon their directs. The majority of the time
| Taylorization hinders workers but management loves it because
| they can have more control in outcomes. What ends up happening
| though, is that an shadow work plan ends up getting established
| that management has less control over unless they want to drive
| out top talent by employing technocratic solutions to social
| problems.
___________________________________________________________________
(page generated 2024-11-19 23:00 UTC)