←back to thread

"No, it's less effort than that"

(smartguess.is)
388 points replyifuagree | 5 comments | 21 Oct 23 04:43 UTC | HN request time: 1.132s | source
Show context
zeroCalories ◴[21 Oct 23 09:45 UTC] No.37965404[source]▶
Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.
replies(7): >>37965441 #>>37965475 #>>37965710 #>>37965713 #>>37965717 #>>37966081 #>>37969203 #
Buttons840 ◴[21 Oct 23 10:48 UTC] No.37965710[source]▶
> Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.

Developers have to push for higher estimates because management has an incentive to underestimate to make life easier.

See what I did there? There's a fallacy in both statements: one side's actions are portrayed as greedy pursuit of "incentives" while the other side's actions are portrayed as a natural and logical counter to those incentives.

replies(1): >>37966096 #
zeroCalories ◴[21 Oct 23 12:03 UTC] No.37966096[source]▶
You're reading too much into the morallity. Furthermore how is it a fallacy?
replies(1): >>37966336 #
1. em-bee ◴[21 Oct 23 12:40 UTC] No.37966336[source]▶
it's a fallacy in that it implies that one side is right and the other is wrong. (or one side is fair and the other is greedy)
replies(1): >>37968686 #
2. zeroCalories ◴[21 Oct 23 17:17 UTC] No.37968686[source]▶
My argument is not assigning blame, but explaining why the article will not convince many managers. It works assuming either side can be greedy or fair.
replies(1): >>37970220 #
3. em-bee ◴[21 Oct 23 20:36 UTC] No.37970220[source]▶
many projects everywere are failing their estimates. so the idea that developers overestimate the time it takes to complete a project is not supported by statistics.

Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.

this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:

management pushes for lower estimates, because they believe that developers intentionally overestimate, therefore this article will not convince them

my response to that would still be the same though. statistics don't support that developers overestimate. on the contrary, one might even be motivated to claim that projects failing their estimates is caused by these managers.

replies(1): >>37972659 #
4. zeroCalories ◴[22 Oct 23 03:45 UTC] No.37972659{3}[source]▶
> many projects everywere are failing their estimates. so the idea that developers overestimate the time it takes to complete a project is not supported by statistics.

Can you cite your own statistics? But even granting your assertion, it still would not matter because in the end the project will be done sooner the more pressure is put on, so it's better to underestimate and plan for delays than to over estimate. Managers often have two different deadlines for projects: the official deadline, and the real deadline. They simply don't tell their reports the real deadline. At many tech companies it's not unusual that a team will only make 70%-90% of their OKRs, and if they consistently make 100% they are said to be too conservative in their ambitions and encouraged to do more.

> this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally:

I believe my intention was clear from the other responses I got that understood what I was saying. But that's not just what management believes, I also believe that, so your version would not be a better expression of what I meant.

replies(1): >>37976318 #
5. em-bee ◴[22 Oct 23 15:40 UTC] No.37976318{4}[source]▶
a quick search on failing software projects suggest a 70% failure rate. over budget (which i see as a proxy for taking longer than estimated) seem to be above 50%.

here is one source that appears to be neutral:

https://blog.gitnux.com/software-project-failure-statistics/

another that suggests one third of completed projects have cost or time overrun:

https://www.bcs.org/articles-opinion-and-research/a-study-in...