Forecast, don't guesstimate your software projects
> And here’s the brutal question: what good are estimates if they hardly ever align with reality? You could have spent that time on building software.<p>No one has ever been able to answer this question for me.<p>In my experience the accuracy of estimates is highly variable. Experienced developers who know each other and the system they're working on well tend to offer more realistic estimates, but even on the most smoothly run teams it's still fundamentally guesswork.<p>From my perspective it seems like the only real effect of estimating units of work is making developers resent people outside their team. Sure, it gives product people a number they can say when they get harassed about when something will be done, but it's no more accurate than one they could have just made up on their own.<p>I don't think I see any fundamental difference between estimating and what this author calls forecasting in this respect. It does seem like generating these metrics could consume less time than meeting to make up estimates, but it's not obvious to me that it always would be.<p>What real value does this add to any business? Any product or business people here? I'm genuinely curious what the purpose of estimating is. It feels like nobody is winning. Product and business people get annoyed by missed "estimates" because what they really want is to know the future, which is impossible. Developers resent being asked to predict the unpredictable. Not to mention I don't know any programmers who prefer talking about doing stuff over actually doing stuff -- all the meetings that come with management styles that include things like estimates feel like an enormous waste of money.<p>Who is winning here?