Comment by chrisfosterelli
4 hours ago
I agree. Software engineering is basically the only industry that pretends this is professionally acceptable. Imagine if government staff asked when a bridge would be done or how much it would cost and the lead engineer just said "it's impossible to estimate accurately, so we wont. It's a big project tho".
Estimating in software is very hard, but that's not a good reason to give up on getting better at it
Incorrect analogy. Bridge construction is a clearly algorithmic process. All bridges resemble each other, and from an engineering perspective, designing one is not rocket science. Construction itself is a set of well-studied steps that can be easily calculated. If I were to write my operating system 100 times, I could give an estimate accurate to within 10%, but every task I’ve ever done in life is unique, and I have nothing to compare it to except intuitive judgments. Returning to bridges: there is 1% of projects that are unique, and their design can take decades, while construction might not even begin
Government contractor's estimation is based on what number is politically acceptable, not how much the project would realistically take. 90% of public projects were overbudget [0].
But you're pretty spot on, as 'professionally acceptable' indeed means politically acceptable most of the time. Being honest and admitting one's limit is often unacceptable.
[0]: https://www.strategy-business.com/article/Why-do-large-proje...
Yes, my claim is absolutely not that they're good at it haha.
Estimation is a real problem in a lot of industries, including ours, and I think that's probably common ground here -- I suppose my differing position is that I think the solution is to get better at it, not to refuse to do it.
I've been on projects where I've seen the budget explode and projects where I've seen the budget kept tight and on track. The latter is very hard and requires effort from ALL sides to work, but it's almost always achievable.
I actually empathize a little bit more with megaprojects because generally the larger the budget the harder it will be to keep on track in my experience. Most estimates we're asked to give in our day jobs are not even multi-million dollar estimates.
Also I'm using budget and estimate interchangeably but these are of course different things -- that's one of my nitpicks is that we often treat these as the same thing when we talk about estimating being hard. A lot of individual estimates can be very wrong without affecting the ultimate budget.
Contractor estimates are just as prone to schedule slippage and cost overruns as anything estimated by software engineers. I doubt anyone's ever argued that giving wrong estimates is hard or impossible. Only that approximately correct ones are, and other industries seem to struggle with that just as much as software. Authors don't finish books by deadlines, so fans are left in the cold. Tunnels take twice as long and cost twice as much. Renovations take a year instead of 3 months and empty your bank account.
Saying "I don't know" is arguably more honest, even if it's not useful for budgets or planning.
> Contractor estimates are just as prone to schedule slippage and cost overruns as anything estimated by software engineers
I completely agree. That's why I chose that example: They're also awful at it, especially these days in North America in particular. But any contractor that tried to put in a bid claiming "it'll be done when it's done and cost what it costs" would not be considered professionally competent enough to award a multi-million dollar budget.
When the government asks how much project X costs they find ten companies that promise the moon and then deliver a wheel of cheese for five times the estimated cost.
They miss estimates all the time though? It’s an observable fact
There is a bridge in my town that is finally nearing completion, hopefully, this year. It was estimated to be completed 2 years ago.
This changes when it’s a project that has fewer unknowns, where they’ve built the same thing several times before. The same is true in software.
Not a good analogy. Once you build a bridge, it’s done. Software nowadays is never “done”, and requirements constantly change. It’s more akin to building a rope bridge and trying to upgrade it to accommodate cars while it’s in active use.
Sounds like you don't have a good process for handling scope changes. I should know, the place I'm at now it's lacklustre and it makes the job a lot harder.
Usually management backs off if they have a good understanding of the impact a change will make. I can only give a good estimate of impact if I have a solid grip on the current scope of work and deadlines. I've found management to be super reasonable when they actually understand the cost of a feature change.
When there's clear communication and management decides a change is important to the product then great, we have a clear timeline of scope drift and we can review if our team's ever pulled up on delays.
I feel like some people in this thread are talking about estimates and some are talking about deadlines. Of course we should be able to give estimates. No, they're probably not very accurate. In many industries it makes sense to do whatever necessary to meet the estimate which has become a deadline. While we could do that in software, there often isn't any ramifications of going a bit overtime and producing much more value. Obviously this doesn't apply to all software. Like gamedev, especially before digital distribution.
I think it's obvious that all software teams do some kind of estimates, because it's needed for prioritization. Giving out exact dates as estimates/deadlines is often completely unecessary.
2 replies →
When customers ask when feature X will be ready, they sure have an idea of done in their mind.
Sure, so extract the customer's definition of done as part of requirements analysis process and write it down. Get them to agree in writing, including the explicit exclusion of other things that aren't part of their idea of done.
Ever heard of Big Dig in Boston, for example? Or the Joint Strike Fighter?
Estimations in government contracts are as ridiculous as in software. They just pretend to be able to estimate when things will be done, when, in fact, the contractors are as clueless.
Not being able to say "it is impossible to estimate", does not mean your estimate will be correct. That estimation is usually a lie.