[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.

[jrs235]

You can ask an architect or a builder how much it is going to cost to build your house. They will ask for blueprints and finishes. If the person asking doesn't have specs then the builder or architect will often offer to help them create them... For a price. Most people that want software developed want to know how much it will cost to develop software without having to invest time or money in first developing the specs. The issue is that people who what software developed either don't know too get or don't want to pay for blueprints, then they complain when things go off the rails whether cost, delivery date, or quality... They fail at managing risks themselves (by not minimally getting specs first).

[jrs235]

"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."

The problem with estimates in software engineering is that few want to pay for them. (Which hinders the formation and demand for the category of firms to produce specs.)

[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"