News for hackers. Stuff that matters.
Re:Yes, Estimate Software Projects by bsder on Sunday October 20, 2019 @08:48PM (#21308435)
> 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 problem is that management always hates the accurate number.

And that's where the dysfunction sets in.

While everybody else rolls things up "normally", I almost always roll up an "accurate" timeline and try to inform people up front. It rarely wins me friends, but it sometimes protects my team when things are going haywire later.

Re:Yes, Estimate Software Projects by knightofmars on Monday October 21, 2019 @08:46AM (#21311622)
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 look bad." It was one of those moments that reinforced my belief that the "image game" and reality are in conflict and people who enable the "image game" are one of the biggest problems in software estimation.
Re:Yes, Estimate Software Projects by s_gourichon on Tuesday October 29, 2019 @04:56PM (#21391920)
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?

Re:Yes, Estimate Software Projects by nerdponx on Monday October 28, 2019 @09:28AM (#21376753)
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.