In software development, a developer is usually paid either annually (by fixed salary) or by the hour. For the most part, it seems like this works. However, I've seen industries where professionals are paid for the task. For instance, in agriculture a worker is paid per bushel. In sales, a worker is paid by commission most commonly.

Would it be possible to pay a developer by delivered item? How could we calculate what a single "item" of software would be? Would this incentivize more efficient development? Would it be more/less fair to the developer, or the employer? Would this be similar/different from a "results-only-work-environment"?

3 Answers 3


What you're looking for is story points. Breaking down functionality into discrete deliverables would help when the client wants more control over the budget and/or schedule for the project (for example, if you want this project delivered in 6 months, we can only fit X number of story points, here is your list let's prioritize according to what you absolutely need in the system).

In practice it takes a very experienced developer/team to deliver to this level and make it useful for the client.

  • this is a slipperly slope, because Story Points are estimates and can be wildly off when more details come to light as implemenation happens. 5 point stories can become 30 point stories over night, this is expected. Tying compenensation to the number of points will only cause big stories to get short changed and implemented in the quickest amount of time with quality suffering.
    – user7519
    Dec 12, 2011 at 21:01
  • Yes there are difficulties in that arena. It all boils down to trust and partnership. It's a difficult situation here in America where the prevailing assumption is that the other guy is trying to screw you over. In the end, you end up going back to T&M or Waterfall development where everything has to be cemented before a line of code is written. Dec 12, 2011 at 21:20
  • Funny story, I was working with a group who wanted me to do some development for them. After a lot of foot shuffling, I said "Hey I can just work for equity on this project". Even then, there was a bunch of hemming and hawing and I just said forget it. After a year of prepping for the project and trying to convince them that I was in it to win it for them, there was still some fundamental mistrust that I just couldn't deal with anymore. Dec 12, 2011 at 21:23
  • It has nothing to do with trust or the lack thereof, Story points were never designed for this application, there is absolutely no relation between stories of different points only stories of the same point values should be compared. Basing a compensation plan on this would just make all the stories 100000 point stories so the developers could pad the estimates and not lose out or game the system, it would be a disaster!
    – user7519
    Dec 12, 2011 at 22:45
  • The idea of story points is that over time you can measure a team's velocity in terms of story points. Taking the idea of gaming the system out of the conversation, it is possible to make a good estimate of how much work can be done within a consistent time box. Again if you know your velocity from trends, and you have honestly assigned points to more features, you can estimate to some degree of accuracy how much work can be completed in an upcoming equal timebox. Dec 12, 2011 at 23:44

Here is your thought experiment re-worded; Imagine a system metric that would not be completely contrived and completely gamed by a system that would do nothing but produce the worst product imaginable, and attach monetary gain to it.

Real World Example: from the not to distant past

Pay by the line of code == lots of lines of code as a goal

Do you really want someone paid this way?

  • I don't think that's what he's getting at. See my response. Dec 12, 2011 at 20:57

www.TopCoder.com sounds like it fits your description.

It assigns a task, and developers code to "win". If yours is the best, you get paid a predefined amount of money. Take away the win/lose competition idea, and you have a fixed bid for a specific small-ish task.

  • Crowd-sourcing at its finest. But the end result is that your code looks like 500 different people worked on it. Dec 12, 2011 at 21:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.