Yes, Estimate Software Projects • Hacker News Board

Re: Yes, Estimate Software Projects

#91

Post by Scarblac » Mon, Oct 21, 2019, 6:19 PM UTC

cynusx wrote: post #74

spoondan wrote: post #71

Earlier quoted context omitted.

I’ve never met anyone that assumed a time estimate was a, “hard deadline,” but every time deadlines are questioned, someone says, “You’re assuming it’s a hard deadline.” Can I convince you this isn’t a productive response? Nowhere in the comment you responded to is there an implication that deadlines are “hard” (can’t be changed or have consequences for missing them). That’s for one simple reason. Everybody knows the…

My point is that there is a difference between giving an estimation of time and a commitment to deliver over a certain time. The parent assumes that just giving the estimate is the same as making the commitment. The distinction between hard and soft deadlines is not relevant to my argument.

Theoretically, a perfect estimate means you'll be under it 50% of the time and over it 50% of the time. No bias.

Still management definitely feels something has gone wrong when you say at least half the projects will be over estimate.

Re: Yes, Estimate Software Projects

#92

Post by jasonpeacock » Tue, Oct 22, 2019, 1:16 AM UTC

mobjack wrote: post #43

jasonpeacock wrote: post #29

This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices. They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines. Then they admit that "delays are normal and expected" - so…

When you keep stakeholders updated early, you force them to make hard decisions about their product so you know what to prioritize. It makes everyone focus on what is most important. Are those features really necessary for the release? Can we change the requirements to accomplish the goal easier? Is it important enough that we should delay it? Without a deadline, engineers waste time working on stuff that is fun and…

> Without a deadline, engineers waste time working on stuff that is fun and interesting to them and not the hard stuff that is needed to ship a product across the finish line.

Why is the threat of a deadline required to ship product?

Re: Yes, Estimate Software Projects

#93

Post by davidjnelson » Tue, Oct 22, 2019, 4:34 AM UTC

Too wrote: post #89

davidjnelson wrote: post #41

Earlier quoted context omitted.

Interesting. Who made the decision to switch and who pitched it to execs? In my experience an executive is the only one who can make this decision. Extremely curious how this worked out.

It should be up to the team to decide the process that works best for them. FWIW that's what agile manifesto says also. Agile is not equal to scrum btw.

I hear ya. “Should be” and “is” are quite different though ;-)

Have you worked for companies where teams choose their preferred project management styles? If so, which companies?

Re: Yes, Estimate Software Projects

#94

Post by lasereyes136 » Tue, Oct 22, 2019, 8:44 PM UTC

The problem isn't estimates per se but how estimates are used:

1. A commitment that can't change

2. Manipulated to pressure people into work unreasonable hours

3. If something will take "too long", estimates will conflate level of effort with duration and be used, again, to manipulate people into doing unreasonable things

4. Used to cover up a failure to manage projects well

Re: Yes, Estimate Software Projects

#95

Post by nerdponx » Mon, Oct 28, 2019, 1:28 PM UTC

bsder wrote: post #78

nilkn wrote: post #54

Earlier quoted context omitted.

As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go. Some folks tend to think that if a plan is produced but not followed exactly, then it wasn’t worth producing the plan. But actually having produced the…

> As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go. I always despise these kinds of exercises. We know how to roll up estimates correctly with statistics--even moreso if we have historical data. The pr…

The problem is that management always hates the accurate number.

The "always" part isn't true in my experience. In fact, it's not even mostly true for me. Maybe I've just been lucky.

Re: Yes, Estimate Software Projects

#96

Post by s_gourichon » Tue, Oct 29, 2019, 8:56 PM UTC

knightofmars wrote: post #87

bsder wrote: post #78

Earlier quoted context omitted.

> As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go. I always despise these kinds of exercises. We know how to roll up estimates correctly with statistics--even moreso if we have historical data. The pr…

A co-worker and I were asked to write up an estimate for a new project. We sat down, walked through the components (best we could at the time) and came up with an estimate (which was likely smaller than the actual given the unknowns). We provided the estimate to leadership. They decided not to do the project. Next, I hear from the head of engineering, "You can't go giving huge estimates to leadership. It makes us loo…

Yes. Let's rephrase the idea a little more formally.

Few hypotheses are necessary for a thought experiment that reproduces the issue.

Given a project:

* some people/teams produce accurate estimates

* some people/teams produce overly optimistic estimates

If decision-maker is not aware, it can easily conflate optimistic estimate with a more efficient team (or just more enticing).

If the possibility of overly optimistic estimates are not taken seriously, the more accurate team can seem just less efficient / lazy / trying to charge more for the same work / etc. For example if the decision-maker is actually a client comparing several suppliers.

Extra risk if decision-making is diluted among many people (harder to get clear and consistent view).

This puts the teams in a competition similar to the prisoner's dilemma. Honest estimates get punished, treacherous estimates are favored. No wonder so many projects are over-budget, when they are not too over-budget to complete at all.

The only actual hypothesis here is: "decision-maker conflating optimistic estimates with better value". It seems very common. If decision-maker doesn't fall into this trap, the problem disappears, right?

What can we do to shift the equilibrium? A manifesto?