Argh. Another post eaten by bad wireless connections (and me not copying to the clipboard before posting). The quick version follows:

* Billing by programmer hours == crazy. Rates should match ability, as programmer ability can vary the time to completion by an order of magnitude or more. A standard rate where team size > 1 is madness.
* If you find yourself stuck in a position where you're billing hours, find out how you bill time given as support to your team/internal support. I had a job where you had 75 hours a quarter (!!) for everything not specifically spent on a certain customer. Whether it was a utility to make faster code next time or internal support, over 75 hours a quarter (less than eight weeks a year!) meant money out of your pocket.

Some jobs expect you to charge this time against your teammate's customer. That makes some sense, but rarely is a customer expecting to contract for, essentially, training time. Some expect you to quietly bill that time against what you were working on in the meantime. That's immoral.

Try to use this to get projects billed in a reasonable way. You can use hours to estimate internally, sure, but let the hours stop there when it comes to billing.

I know, I know, sounds easy enough, but... See, the thing is, managers use overruns on hours so that they can keep soaking the customer when they estimate badly, and that happens awfully frequently. At the same time, if you did get out a good (read: slightly high) estimate, they can always find something to task you with to ensure all those hours get eaten up -- documentation, code review, documentation revision number seventy-two, another code review, etc. That's also immoral, and those together are the problems with hours. Billing by hours doesn't put the customer first, nor adaquately values the hacker doing the work.