5 ms·

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 e

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.

diego_moita 11y ago
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
Ntrails 11y ago
>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
paulddraper 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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.
        11y ago
- jsprogrammer 11y ago
  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 11y ago

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

Ntrails 11y ago

>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

paulddraper 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
      - 11y ago
jsprogrammer 11y ago
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"