←back to thread

"No, it's less effort than that"

(smartguess.is)
388 points replyifuagree | 1 comments | 21 Oct 23 04:43 UTC | HN request time: 0.204s | 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 #
1. nonameiguess ◴[21 Oct 23 12:00 UTC] No.37966081[source]▶
Estimate high is the mathematically most valid thing to do in the face of uncertainty. This is more or less the fundamental theorem of finance. Expected rate of return increases with risk as compensation for the risk. Project planning should be following the same principle. If you're uncertain of traffic conditions, you leave earlier to be safe. If you're uncertain of future work unknowns, you estimate longer completion time to be safe.

If management is pushing for lower estimates, it's typically going some reason along the lines of:

- Someone higher up gave them a fixed budget or a fixed deadline and they can't exceed that.

- They're expecting market conditions to reward earlier delivery more than higher quality.

- They don't understand the problem domain.

- They do understand the problem domain but don't understand limiting factors like tech debt or organizational process hurdles the developers face that preven them from hitting timelines they would hit under ideal conditions.

If it's one of the latter two, they need to have a come to Jesus moment with themselves because you can't run a team if you don't understand what they do, how they do it, and what obstacles they face.

If it's one of the former two, great, communicate that, but then whoever is ultimately accepting or using your product needs to understand the basic release models that you can either get a complete set of well-defined features or you can get a specific release date but you can't get both, except by luck. And you need to have an organizational culture that isn't going to punish developers if they don't get lucky and meet only one of those goals.

Companies purchasing labor output don't get to violate the basic constraints of being a consumer. If you've got a fixed budget, fine, but you get what you pay for.