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...
When did estimates turn into deadlines?
21–30 of 237 posts
Re: When did estimates turn into deadlines?
#22Working 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"?
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.
Re: When did estimates turn into deadlines?
#23Multiply your original estimate by 3, works most of the time
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.
Re: When did estimates turn into deadlines?
#24[deleted]
Re: When did estimates turn into deadlines?
#25I 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.
> 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?
There’s a whole generation of developers who have internalized this.
Re: When did estimates turn into deadlines?
#26Working 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"?
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.
[deleted]
Re: When did estimates turn into deadlines?
#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 not operate like this". Not just car/home insurance either...health insurance also. They do often negotiate to a reasonable place, but not always.
Re: When did estimates turn into deadlines?
#28My 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…
At my very first job out of college,¹ 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.
Re: When did estimates turn into deadlines?
#29> 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.
Re: When did estimates turn into deadlines?
#30I definitely relate to the basic issue of estimates with my one-person consulting projects. The bit they didn't mention is: who pays for the cost of the inspections and analysis? In software, it can take a long time to analyse the requirements and the solution, in order to come up with an estimate (or fixed quote), and I find it awkward trying to get paid for that time.