3 ms·

A big part of the problem IMO is the software development community has gravitated toward rate compensation instead of product compensation. A composer is commi

A big part of the problem IMO is the software development community has gravitated toward rate compensation instead of product compensation. A composer is commissioned to deliver a product and is compensated for said product, not for the time he/she worked to create the product. This was real eye opening for me when I did contract/consultant work, even as a 1099. I can understand the enterprise, butts in the seat model of developers being on retainer but for contracting houses I don't get it. If developers don't want to be bound by these metrics they need to get better at forcing the client into contracts for deliverables with clearly defined acceptance criteria. Also, it seems to me that the best way to get proficient and creating and updating these contracts is by having to work twice as long to deliver a work product as was initially estimated.

commandlinefan 8y ago
I'm not very optimistic that we'll ever be able to reach that utopian state, though. After all, the only person in the fixed-bid equation with any incentive to nail down requirements up front is the developer - it's in the best interest of the buyer to be as vague as possible so that they can defer actually making any decisions until they've had a chance to see the finished product, when the consequences of the decisions are most obvious. Then they can turn around and say, "the requirements clearly state that..." or in other words, you're going to be working for free. Once you get up into even five-figure bids (never minds something that might take a year to deliver), the people writing the checks are happy to put more effort into deliberately obscuring the requirements gathering process than actually gathering requirements, just to keep their options open, and they have a legal department that you don't.
- 0x445442 8y ago
  I hear what your saying but there's a whole host of other fields that seem to pull it off. Other than the fact that software is not bound by physical constraints, I really don't see the major differences. I think we're just fighting the "always done this way" mindset.
  - nickjj 8y ago
    A lot of developer contract work doesn't fit into a fixed bid model. What if someone hires you as an ongoing general problem solver? I've had many contracts like this for 4-5 months where they just threw problems at me and expected me to think of a solution and then implement it. This could be anything from little scripts to make development better, ops / deployment improvements, better docs, being a 2nd set of eyes for pair programming, etc.. Something like that isn't really possible to plan out, so paying by the hour makes sense. On the other hand, I do fixed bid pricing on a lot of things when it makes sense. I sometimes even do a hybrid approach where it starts as a fixed bid and ongoing maintenance becomes hourly.
    - nucleardog 8y ago
      Something I'm forced up against frequently at a company that provides fixed bids for projects and refuses to bill anything hourly: How do you determine a fixed bid for fixing or modifying an existing product you're unfamiliar with? If a client comes in and says "one out of every 50 times you load a page in this web app, it renders a blank page, how much is it going to cost to fix?" what do you say? Every hour you spend investigating or familiarizing yourself with the problem is basically just spec work with all the risk that entails. In many cases when you're "fixing" something, the project could be entirely spec work as you spend 8-16 hours determining that the problem is simply a misconfigured setting that will take 5 minutes to flip. Clients very rarely (in my experience, never) specify problems to a degree sufficient to create a concrete scope of work, and they're not going to pay you hourly to do so. If I take my car to a mechanic and say "it makes a funny rattle sound, how much will that cost to fix?" he's not going to give me a fixed bid.
      - nickjj 8y ago
        The more unfamiliar it is, the more inclined I would be to use hourly billing. In your blank page example I would bill by the hour.

commandlinefan 8y ago

I'm not very optimistic that we'll ever be able to reach that utopian state, though. After all, the only person in the fixed-bid equation with any incentive to nail down requirements up front is the developer - it's in the best interest of the buyer to be as vague as possible so that they can defer actually making any decisions until they've had a chance to see the finished product, when the consequences of the decisions are most obvious. Then they can turn around and say, "the requirements clearly state that..." or in other words, you're going to be working for free. Once you get up into even five-figure bids (never minds something that might take a year to deliver), the people writing the checks are happy to put more effort into deliberately obscuring the requirements gathering process than actually gathering requirements, just to keep their options open, and they have a legal department that you don't.

0x445442 8y ago
I hear what your saying but there's a whole host of other fields that seem to pull it off. Other than the fact that software is not bound by physical constraints, I really don't see the major differences. I think we're just fighting the "always done this way" mindset.
- nickjj 8y ago
  A lot of developer contract work doesn't fit into a fixed bid model. What if someone hires you as an ongoing general problem solver? I've had many contracts like this for 4-5 months where they just threw problems at me and expected me to think of a solution and then implement it. This could be anything from little scripts to make development better, ops / deployment improvements, better docs, being a 2nd set of eyes for pair programming, etc.. Something like that isn't really possible to plan out, so paying by the hour makes sense. On the other hand, I do fixed bid pricing on a lot of things when it makes sense. I sometimes even do a hybrid approach where it starts as a fixed bid and ongoing maintenance becomes hourly.
  - nucleardog 8y ago
    Something I'm forced up against frequently at a company that provides fixed bids for projects and refuses to bill anything hourly: How do you determine a fixed bid for fixing or modifying an existing product you're unfamiliar with? If a client comes in and says "one out of every 50 times you load a page in this web app, it renders a blank page, how much is it going to cost to fix?" what do you say? Every hour you spend investigating or familiarizing yourself with the problem is basically just spec work with all the risk that entails. In many cases when you're "fixing" something, the project could be entirely spec work as you spend 8-16 hours determining that the problem is simply a misconfigured setting that will take 5 minutes to flip. Clients very rarely (in my experience, never) specify problems to a degree sufficient to create a concrete scope of work, and they're not going to pay you hourly to do so. If I take my car to a mechanic and say "it makes a funny rattle sound, how much will that cost to fix?" he's not going to give me a fixed bid.
    - nickjj 8y ago
      The more unfamiliar it is, the more inclined I would be to use hourly billing. In your blank page example I would bill by the hour.