[Kurtz79]

"So why waste valuable time to do all this, if you know it's not the truth anyway ? The answer is to accept that you will learn things as you go along, and that things take as long as they take, and to rather deal with that."

This maybe is applicable for a company developing new products internally, but for projects delivered to third parties, delivery dates are part of contractual obligations.

Estimates are hard, but it's not like predicting the future with a crystal ball. Good developers in general get better as they gain experience in the domain, and in estimating itself.

Good project managers in general get better at spotting murky requirements that might be causing problems down the line, and try to clarify them early with the customer.

It's not a perfect science either, but it's a necessity in many real-world scenarios.

[dredmorbius]

Contractually obligating pi to be 3, the Earth to be flat, or software features and ship dates to be specified, doesn't make them so.

All you've done is restate the problem as an error on the part of the negotiating process. Not a problem to be dumped on developers.

[paulddraper]

When you buy something from Amazon Prime and it gets there three weeks later, I hope you are as amused by the "negotiating process."

(Yes, I know, the product you build is different than manufacturing, different than construction, different than paperwork, and every other deliverable.)

[dredmorbius]

Commoditised manufacture, inventory management, and shipping are pretty much precisely the opposite of software development.

Or: your entirely counterfactual counterexample rather neatly proves my point.

[paulddraper]

Software development is commoditised. Or at least a lot is. Static web sites, simple mobiles apps, etc. Some individuals or organizations build them over and over with regularity.

[jsprogrammer]

Don't put hard commitments into the contracts then. Why slave yourself to something that you aren't sure you can deliver?

Good developers should ideally only ever do the same thing once, which means that there is very limited utility in trying to improve estimates for a task that you should never perform again.

[Ntrails]

>Don't put hard commitments into the contracts then. Why slave yourself to something that you aren't sure you can deliver?

Because you know full well that the contractual time limits will not, in fact, ever be relevant as you've added some neat tricks so as soon as the spec changes you get to adjust them (and the spec always changes). One assumes therefore that the commitments are simply part of the bidding process as you try to craft a somewhat realistic but very attractive looking bid

[diego_moita]

The secret of a consultant's work is not to craft software, it is to craft contracts.

Evidence : CGI never got burned by their fiasco on delivering Healthcare.gov

[paulddraper]

In general, this is a terrible practice.

"How much is it going to cost to build my house?"

"Er, I'd rather not commit to a price. We'll figure it out later."

[jrs235]

Software development is very different from building physical structures.

"How much is it going to cost to build my house?"

"Give me the blueprints and tell me your finishes."

[Waits on client to provide specs...]

[abduhl]

What's the difference?

"How much is it going to cost to build this application?"

"Give me your specifications for the app."

[Waits on client to provide specs...]

[jsprogrammer]

I'd guess the usage of [Waits on client to provide specs...] in the software scenario is a bit facetious.

Often clients can't produce specs sufficient to build an application. Some clients may produce 'specs' which are incomprehensible, making them impossible to estimate.

The crude part is, that such projects may still go on, and worse, the client may believe that the application is actually being built to the specs.

[abduhl]

Often clients can't produce specs sufficient to build a house/building/pipeline. That's why there is an entire category of firms that exist that are hired by clients to produce these documents.

Guy wants an apartment building, he hires an AE firm and tells them "I want an apartment building" and they say "well what kind of apartment building?" and then goes through the exact same process of defining scope, budget, and schedule that would be done in any other project management field. Lawyers get hired when someone wants to sue someone - "well what do you want to sue them for?" Sourcing managers get hired when someone wants to make something - "well what do we need to buy?"

The fact that the software engineering industry refuses to acknowledge that their industry is not special is a constant source of confusion for anybody who has been doing this in another industry. Why is the software industry special? What makes software so nebulous that scopes cannot be defined and estimates made? The argument that "people don't understand the impact of requests" does not hold water - people don't understand that simply wanting more room in a particular part of their house can cause an entire redesign. That's why you, as the expert, have to explain the impact of their requests clearly rather than just agree to them.

The problem with estimates and scheduling in software engineering isn't a result of work, it is a result of failure by the project management.

[jsprogrammer]

That is not the only alternative.

"$300/hr + expenses; hours and expenses determined by necessity to complete work; work as described represents at least 100 hours effort and $x in expenses"

[diego_moita]

> as they gain experience in the domain

Because "gain experience" means that there are no more "unknown unknowns" for them, anymore.

But, unfortunately that is a luxury you can't afford for too long. Reality has the nasty habit of changing, shit happens and good developers need to get replaced as they burn out and run away from development into more sane activities.