I am a programmer and am paid by the hour, as are many other programmers. I have worked on projects that were paid a fixed price. Both seem to be a bit unsuitable.
These models do not reward good programming style. Do you know other models of payment that are better suited for programming tasks?
IMHO fixed pay is more encouraging for good programming, because you are not encouraged to "waste" time to get paid more. On the other-side it doesn't discourage bad programming.
But note that fixed pay doesn't harm good programmers, while hourly is great for bad programmers, and not that good for good ones.
I prefer being paid by the hour. With fixed price work, there are always nasty surprises that appear after the price has been agreed. Unless you're paid for a detailed investigation / specification phase first, it's very hard to work out exactly how much to charge for fixed price work.
I prefer the "bonus system" of pay. You get a basic pay per hour and if you are fast, efficient, etc. you get a bonus.
This is very closely related to this question.
There is a third way, which is salaried and a fourth which is retained (i.e. a fixed number of hours in a week/month/quarter regardless of the work).
I confess I find it a bit strange that there seems to be a question of quality. I would presume as a client that I was going to get good quality/practices from you regardless of the deal we strike - otherwise I won't do any business with you at all - and certainly not a second time.
Furthermore as a developer I find it alarming that anyone would consider compromising quality because of the hourly rate. Not only is that disingenuous it is also commercial suicide. Your reputation is derived principally from your quality, not your cost.
So for me this is a question about risk. The risk to you of a fixed price contract is that you under-estimate the effort and/or manage the requirements badly and end up on what amounts to a very low hourly rate by the time you are done.
The risk of an hourly rate is that no customer in their right mind will give you an open-ended commitment and will likely haggle on rates once you get around the amount of their original budget. Remember that they have a budget, they are not going to think about their engagement in terms of hourly rates unless they have you on a retainer.
Ed: The question changed after I posted my answer and (understandably) the implication of low quality seems to have been withdrawn.
What is the best pay model for programmers?
That's easy: give me all your money and unlimited time! :)
Fixed price works best for small/well defined deliverables.
The agile approach to this would be fixed price per iteration/sprint. This approach gives the benefit of a "small" deliverable which is defined before work begin. It would also leave the option for either party to pull the plug after a certain amount of delivered value.
The only perfectly fair way to bill would be by business value created, but that is impossible to quantify, so hours are almost always used.
I do not agree with the statement that fixed price encourages good programming. If you set up a project where the budget and schedule are fixed, the only thing that can slide is the quality, and it does.
Another way to look as fixed bid is that if you come in ahead of schedule, your client paid for more development than they received. On the other hand, if it is late, then the client is upset because it's late. In both cases, the client has a reason to be unhappy.
Fixed bid is the best method of billing if there is a huge lack of trust between parties. So, we avoid it.
I also disagree with the statement that nobody in their right mind would grant permission for open-ended hourly development. In fact, almost all of our clients have us do that for them, and the reason is that there is a large amount of trust between parties. Establishing that trust initially is an investment, and maintaining it requires a lot of communication, but it's way better than having fixed bids and bickering over every change that inevitably crops up.
So, my opinion on the best way to bill is per hour, plus trust. Even though hours are an imperfect measure, at least this way all time gets spent doing development instead of negotiating fixed contract terms.
In my recent projects I've tended towards a fixed fee negotiated around as detailed and clear a specification as I can get. This is followed by adjustment and refinements based on my daily rate. At the start of the project my daily rate is known to the client.
I deliver the application to the agreed specification for the agreed fee, then negotiate and quote for adjustments and additions to the functionality or design, based upon my daily rate.
It feels like the best of both worlds to me. The client knows they'll get something useful and how much that will cost - I know where the initial finish line is and have planned how much I should be paid to get there. Any extra stuff is a separate issue, negotiated as such.
The other benefit of this, with new clients, is that you can establish trust and confidence in your ability in the first phase and avoid the potential 'open ended' hourly rate scenario.
A note on billing and pedantry: Invoicing your clients for communications such as telephone conversations with them about the very service you are providing to them and for which they are paying is a Very Bad Idea. Do not do it. Unless you are prodigiously talented, you will go out of business. I have seen it suggested elsewhere on SO that you should invoice for 'everything'...
If you feel you're 'wasting time' with admin and comms tasks like this, build it into your rate. Most clients I've spoken with would be (and have been) appalled when contractors have tried to do this.
A note on doing stuff for 'free': Yes and no. Mostly no. "Can you make the title of the detail page bold?" - yes. Just do it. Who are you, Scrooge? "Can you add these three fields and build a new fieldset in the edit form for XYZ" - Errr...no.
This is, of course, just my opinion and I can see the danger of scope-creep (a bit like this reply!) and the possibility of a client hiding major changes behind a succession of little "could you justs". I guess it comes down to trust - this time in the other direction. I've found with most clients, implementing trivial adjustments for no charge builds goodwill and eases the process of getting paid well for the stuff you do charge for.
What was it now?... "Promise less, deliver more" Yes. That'll do.
It depends a lot on the sort of work you are doing and how the contract is structured in terms of IP ownership. If a company hires you to produce an application and they will own all of the code and IP when you are done, often it is best to simply get paid for your time. You can either structure open ended work, some sort of fixed budget, some sort of estimate, whatever. You can structure the job in a lot of different ways.
If you intend to own the IP and perhaps productize all or part or you intend to use work that you have already developed or productized, then you will generally want to fix a price for a well defined deliverable and deliver the work.