I think hourly billing is bad for two reasons, even though I do it all the time:
* It just limits the amount of money you can make. People have a strange psychological approach to hourly figures; once you hit a certain rate that they consider alarmingly "high," which is a metric that varies immensely, their eyes just sort of glaze over and they go, "ooof!" But if you give them a fixed bid that assumes x hours and comes out to an equivalent hourly rate that is ${quite high}, they seem to be just fine with that - in my experience, this is often true even if you itemise it and declare the expected hours. Some sort of fixed bid leaves a lot more room for padding in case things don't go as expected, and, if you're lucky, more profitability.
* Programming workflow just isn't linear like that. We've all read Joel Spolsky's "Human Task Switches Considered Harmful." In addition to that, programming problems are often solved in strangely noncontiguous, out-of-band ways, like coming up with solutions to a vexing encumbrance in the shower.
The point is that billing should attempt to reflect the actual workflow as closely as possible, and the workflow of a programmer just doesn't go like an auto shop's. If you have a 20 hour project, doing 5 hours here, going off to do something else, and coming back to it and doing another 5 hours doesn't mean the project is 50% done - at least, from a practical perspective.
Being a very small business myself with no credit facility and no savings or cash buffer whatsoever coupled with relatively high living expenses inherited from my employed days, I face the additional issue of severe cash flow constraints when I attempt to float long projects that pay hourly. I describe this more extensively in this comment: http://news.ycombinator.com/item?id=746517
For me - as for many freelance programmers and contractors - I think the right choice is some sort of flat weekly billing, and splitting up any project of nontrivial size into smaller, manageable and well-defined milestones. If you can get away with it.
I think it's pretty fair to say that you often can't do a linear, 1:1 relationship between time spent toward project and money paid. One caveat is the one I pointed out above. The other, more generally, has to do with the fact that at 100% completion code acquires orders of magnitude more economic utility than when it's 90% complete. At 90%, it's just a useless blob of code as far as most customers are concerned. At 100% it's a finished deliverable that does what they want - or thought they wanted, whatever. So, usually there's a bigger balloon payment at the tail. It's not realistic to expect that when you have 7/8ths of the project done, you'll have 7/8ths of the money in hand. There are other reasons for this as well; see the link to my other comment above. But I think one should strive to get as close to that possible, insofar as it's possible to measure % completion to any degree whatsoever.
* It just limits the amount of money you can make. People have a strange psychological approach to hourly figures; once you hit a certain rate that they consider alarmingly "high," which is a metric that varies immensely, their eyes just sort of glaze over and they go, "ooof!" But if you give them a fixed bid that assumes x hours and comes out to an equivalent hourly rate that is ${quite high}, they seem to be just fine with that - in my experience, this is often true even if you itemise it and declare the expected hours. Some sort of fixed bid leaves a lot more room for padding in case things don't go as expected, and, if you're lucky, more profitability.
* Programming workflow just isn't linear like that. We've all read Joel Spolsky's "Human Task Switches Considered Harmful." In addition to that, programming problems are often solved in strangely noncontiguous, out-of-band ways, like coming up with solutions to a vexing encumbrance in the shower.
The point is that billing should attempt to reflect the actual workflow as closely as possible, and the workflow of a programmer just doesn't go like an auto shop's. If you have a 20 hour project, doing 5 hours here, going off to do something else, and coming back to it and doing another 5 hours doesn't mean the project is 50% done - at least, from a practical perspective.
Being a very small business myself with no credit facility and no savings or cash buffer whatsoever coupled with relatively high living expenses inherited from my employed days, I face the additional issue of severe cash flow constraints when I attempt to float long projects that pay hourly. I describe this more extensively in this comment: http://news.ycombinator.com/item?id=746517
For me - as for many freelance programmers and contractors - I think the right choice is some sort of flat weekly billing, and splitting up any project of nontrivial size into smaller, manageable and well-defined milestones. If you can get away with it.
I think it's pretty fair to say that you often can't do a linear, 1:1 relationship between time spent toward project and money paid. One caveat is the one I pointed out above. The other, more generally, has to do with the fact that at 100% completion code acquires orders of magnitude more economic utility than when it's 90% complete. At 90%, it's just a useless blob of code as far as most customers are concerned. At 100% it's a finished deliverable that does what they want - or thought they wanted, whatever. So, usually there's a bigger balloon payment at the tail. It's not realistic to expect that when you have 7/8ths of the project done, you'll have 7/8ths of the money in hand. There are other reasons for this as well; see the link to my other comment above. But I think one should strive to get as close to that possible, insofar as it's possible to measure % completion to any degree whatsoever.