zlacker

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

>>chrisf+(OP)
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.

>>chrisf+(OP)
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.

>>chrisf+(OP)
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.

>>chrisf+(OP)
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...

>>piyuv+n2
When customers ask when feature X will be ready, they sure have an idea of done in their mind.

>>AlotOf+e3
> 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.

>>piyuv+n2
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.

>>rainco+l3
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.

>>chrisf+(OP)
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.

>>PxldLt+x4
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.

>>chrisf+(OP)
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.

>>FINDar+ye
The real problem is software teams being given deadlines without being consulted about any sort of estimates. "This needs to be done in 60 days." Then we begin trading features for time and the customer winds up getting a barely functioning MVP, just so we can say we made the deadline and fix all the problems in phase 2.

>>icedch+os
OK, so that sounds fine. Software delivers value to customers when it's better than nothing some of the time. Even if it barely functions then they're probably happier with having it than not, and may be willing to fund improvements.

>>chrisf+M3
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.

>>chrisf+(OP)
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

>>AlotOf+e3
The date is just a useful fiction to:

- Create urgency

- Keep scope creep under control

- Prioritize whatever is most valuable and/or can stand on its own

If you just say “I don’t know” and have no target, even if that’s more honest, the project is less likely to ever be shipped at all in any useful form.

>>numitu+OB
Software engineering isn't some magical, special branch of engineering in which no one piece of software resembles another, no well-studied steps can be replicated, and the design of which is equivalent to rocket science.

If you're truly creating such unique and valuable software that it is to be compared to the world's engineering megaprojects in its challenge then perhaps it is beyond being beholden to a budget. Who am I to say?

But 99.9% of this industry isn't doing that and should probably be able to estimate their work.

>>chrisf+rY
I’m not talking about difficulty; I’m talking about uniqueness—uniqueness for me personally. There are people who spend their whole lives designing bridges. I, on the other hand, have been writing software for 15 years, and almost every task I encounter is unlike the previous one. I’m not saying it’s difficult, but solving it requires gaining new experience that will be useless for future tasks. Sometimes, I have to do something similar to a previous task, but in 90 percent of cases, I first need to create documentation on how it currently works, figure out how to turn a task description consisting of a 15-word headline into a set of concrete actions, and then test it.