3 ms·

> management is right to ask for estimates. True, but there needs to be common understanding that they are estimates, and if the projects take consistently lon

by a1369209993 7y ago

> management is right to ask for estimates. True, but there needs to be common understanding that they are estimates, and if the projects take consistently longer, it means the dev is bad at estimating, not bad at writing software[0]. Also, if you get a median time, you'll have, by definition, half the projects taking longer than that; a mean, mode, or 90th estimate will still have plenty of high points; and if you want 100th percentile, you don't even need to ask the developer: "sometime in the next century, probably". 0: They can be that, too, but that's a independent flaw from being bad at estimating.

7532yahoogmail 7y ago
The issue often is that management will not crush programmers if wrong. Managers aren't stupid. This isn't a competence issue primarily. This is a trust and openness issue mainly. So the estimates were wrong? What do people believe about why they were wrong and how will people react? If that decends into defensive behavior ... Read the book.
- hinkley 7y ago
  The people who call them estimates aren't the problem. The people who substitute the word 'commitment' are. You promised, and it didn't happen, so you are a bad person.
beefalo 7y ago
Being good at estimating is an important skill for a developer. You are the one with the knowledge of what needs to be done to deliver a project and to be a good engineer you should be able to deliver a reasonable estimate so a decision can be made on what to invest in. If your guidance leads is wrong and leads to a bad investment, then it is not a misplaced judgement for you to bear some of the blame.
- desipis 7y ago
  "You are the one with the knowledge of what needs to be done to deliver a project" I think you're missing the point. Nobody has that knowledge prior to the project being complete. The only exceptions are very small projects or projects that are just rolling out pre-established boiler-plate solutions. Any reasonably complex and reasonably sized software system contains far more uncertainty than humans are capable of thinking through.
adinisom 7y ago
On top of that, people assume estimates are normally distributed. In my experience there's much more skew -- surprises are rarely in your favor. This means any given "good" estimate is either unlikely since it's in the tail of the distribution or overly optimistic if in the bulk.

7532yahoogmail 7y ago

The issue often is that management will not crush programmers if wrong. Managers aren't stupid. This isn't a competence issue primarily. This is a trust and openness issue mainly. So the estimates were wrong? What do people believe about why they were wrong and how will people react? If that decends into defensive behavior ... Read the book.

hinkley 7y ago
The people who call them estimates aren't the problem. The people who substitute the word 'commitment' are. You promised, and it didn't happen, so you are a bad person.

beefalo 7y ago

Being good at estimating is an important skill for a developer. You are the one with the knowledge of what needs to be done to deliver a project and to be a good engineer you should be able to deliver a reasonable estimate so a decision can be made on what to invest in. If your guidance leads is wrong and leads to a bad investment, then it is not a misplaced judgement for you to bear some of the blame.

desipis 7y ago
"You are the one with the knowledge of what needs to be done to deliver a project" I think you're missing the point. Nobody has that knowledge prior to the project being complete. The only exceptions are very small projects or projects that are just rolling out pre-established boiler-plate solutions. Any reasonably complex and reasonably sized software system contains far more uncertainty than humans are capable of thinking through.

adinisom 7y ago

On top of that, people assume estimates are normally distributed. In my experience there's much more skew -- surprises are rarely in your favor. This means any given "good" estimate is either unlikely since it's in the tail of the distribution or overly optimistic if in the bulk.