zlacker

>>mattjh+(OP)
After owning a product, I've developed a lot of sympathy for the people outside of engineering who have to put up with us. Engineers love to push back on estimates, believing that "when it's done" is somehow acceptable for the rest of the business to function. In a functioning org, there are lot of professionals depending on correct estimation to do their job.

For us, an accurate delivery date on a 6 month project was mandatory. CX needed it so they could start onboarding high priority customers. Marketing needed it so they could plan advertising collateral and make promises at conventions. Product needed it to understand what the Q3 roadmap should contain. Sales needed it to close deals. I was fortunate to work in a business where I respected the heads of these departments, which believe it or not, should be the norm.

The challenge wasn't estimation - it's quite doable to break a large project down into a series of sprints (basically a sprint / waterfall hybrid). Delays usually came from unexpected sources, like reacting to a must have interruption or critical bugs. Those you cannot estimate for, but you can collaborate on a solution. Trim features, push date, bring in extra help, or crunch. Whatever the decision, making sure to work with the other departments as colaborators was always beneficial.

>>notjus+xw
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+kB
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

>>numitu+8d1
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.