How to explain to a layperson the variance in programmer rates?

I recently talked to a guy that is looking for developers to build a product idea. He mentioned he has received interest from people but the rates have varied from \$20-120/hr. This project he estimates should take 3-6 months and since he is non-technical, he is confused why there can be so much variance.

I understand how I would choose someone but I am a developer and can gauge other people's work.

How can I explain to him (in a non-biased way, if possible, as I will apply as well) about the variance in rates? Is there any good analogy that would help?

-
Some people are more desperate for work than others. –  JeffO Dec 11 '11 at 1:23

There are some who are just trying to get some work and/or are looking for their first project to prove they can program. Others may be employed or have enough consulting work to charge more money. Better programmers should take fewer hours to complete the same programming task as well as, create solutions that lesser programmers will never come up with. Those charging \$20/hr will dump the project at the first sign of getting a job.

Imagine a record company asking Sting how much he would charge per hour to write a song. Unfortunately, an hour of work is just difficult to quantify what you will get in return.

Suggest they commit to one developer for a very small piece of the project. If they are not satisfied, little has been lost and they'll know better what to look for next time.

-

The best explanation I've heard, was: imagine you have a really hard math problem. Hiring many mathematicians doesn't help to solve the problem. Instead, you would find a really great mathematician who will solve the problem.

Not exactly the analogy you were looking for, but I've found this helpful in explaining to people why you need to hire people who are really good.

-

If this layperson is interested by sport, you can use the analogy with the salaries in his favourite sport. It's possible to have good results without any "star" but the teams with only low-salary players don't win often.

-

I'd go with programmers are people too.

• Some are really busy

• ...and if they say yes to you, will have to turn down other stuff.
Maybe easier, more economically rewarding, stuff
• Some are really bad at doing their working hours math

• ...and never met them.
• ...and can't explain why.
• Some are really incredibly careless

• ...and ship unbelievably shoddy works,
• ...and invoice for debugging.
• Some plan on using a bad set of tools, not knowing any better

• ...they learned using those, but at least to a great extent,
• ...and now they are kinda locked into a blunt-tool-does-it-all nightmare.
• Some are taking jobs they don't know how to do

• ...and invoicing you their self-training.
• ...or setting deadlines to a far, far future
• Some are taking jobs they are very good at (they trained before-hand)

• ...and invoicing you their previous self-training.
• those at least will probably ship on time.
• ...or feel very guilty about not doing so.
• Some will need external help for parts of the task

• Some will resell the whole package to a cheap developer

• ...and want their cut
• ...and will deny they ever did that
• ...and will make life miserable for both you and the actual dev, by playing Chinese Whispers
• Some completely misunderstood the issue

• ...and will it burn, oh if it will, when it becomes evident.
• Some are posing as programmers for a real programmer that couldn't make it there

• they say a a lot of "yes"
• they've already been told the price

-

High variance is nothing unusual, When creating a building, for example, the builder will earn less than the electrician who will in turn get less than the architect.

People with rarer skills will earn more, that's the way with any industry including programming.

-

Variance in salary/charge rate could reflect variance in expertise and quality but this is not always true. Remember that other factors come into play here, for example the geography, whether the person is a full-timer or a part timer and whether the person understands the deliverable in details or not. Add to that the answers provided before. On the other hand, a low price could reflect high level expertise, since some one may think that the work is too easy for them to charge high dollars for it! So, cost per hour is not a good indicator for expertise, although, it is common to charge more if you are experienced or don't really care if you get the job or not (sort of this is it, take it or leave it).

Your friend should examine the developer's reputation, previous work history, chat with him/her and see what challenges they see in this project and how good they can communicate. Chances are he will be able to spot the right person with may be 1 or 2 ties at the most. Again, charge per hours is not enough to measure expertise or competence.

-

Sounds like he's looking at cost per hour. He might want to consider output as well.

-

Competing job opportunities. Some developers (athletes, artists, musicians) have lots of other potential offers that your layperson has to compete against. And some don't (and maybe there's a good reason why).

And some are better at bargaining negotiations (and/or poker), whether or not they have alternate competing opportunities, or are good enough for such.

-