It's a common practice that programming job is billed in hours, or its variants ( such as billed in man-months, but they are still the same, so please don't nitpick over it. ). This is exceptionally popular among agilists, who believe that the alternative, fix price quote is problematic and lead to dire consequences, for both the software development shops and the clients.
Before I start off maybe I should summarize why fix price is bad. IT projects, as we know it, are notoriously hard, not purely because writing code is hard, but because the business requirements are always unclear, because the commissioners often don't know what they want until they have a working software. Now, business always welcome fix-price projects because the notion of fix-price seem to be able to contain the financial risk by avoiding the projects from going spirally out of control. The problem is that any IT shops who don't have infinite financial backups can't afford to do fix-price projects under never-ending requirement changes. To protect both parties, pages and pages of requirements, violation orders and documents are written. And these are waste because they are not, strictly, a part of the delivery.
Fix-price projects often result in a lot of wastes, and because of the heavy baggage, it's not so easy to change the projects direction once they are started. This means that if the business owner finds that the business environment changes, or that the IT projects are heading into nowhere, there isn't anything they can do to the software projects except to cancel them and declare the investment as failure.
It is under this light that agile programming is born. You specify what you want, I do that, I show it to you, and you feedback your opinion, and I refine. Everything is done in a lightweight manner; I develop the most important feature early, and you get back your investment as soon as possible. The waste is kept to the minimum, the mistakes can be corrected fast because the duration of iteration is short. We don't really know how the software will look like in, say one year time; all we know is that the software is solving the clients problem from day one, gradually, instead of meeting the specifications that the clients won't like anyway.
It's clear that only bill-per-hour approach can work in this case.
But is it really a good approach? One thing for sure, it's good for software developers because it protects them from being skinned alive by never-ending changes. But the project owners do have some qualms about it.
First, how do project owners know that the billable hours are well-spent? There is a 10 times ( or probably more) difference in productivity gap between good developers and bad developers, and probably no one is able to tell the difference between who's the good developers and who's the bad. This is this risk, the risk that the project owners might end up paying a suboptimal developer the optimal rate, that the project owners have to take.
Second, the amount of work done can be a source of dispute. Should a developer bill for the time he spends on researching? Most project owners will instinctively say no, because of the belief that "the developers should already know what they are doing before they charge", if they are not then they should pick up the necessary knowledge and skills on their own. But programming is unlike other assembly job where you can know the amount of time needed for sure. There are a lot of components and libraries out there that the developers can reuse in their work. If project owners frown on the time spent on researching and testing those components, the developers could just go off their own way and reinvent the wheel and rewriting the whole framework, which will cost many times more.
But if a developer bills on research time, this means that he would charge the job cheaper if he gets to do the same job again because he no longer needs to research. The first project owners, as shrewd as they are, would certainly feel that they are mis-fortunate just because they are the first one who venture into the uncharted territory and thus will ask the developer to eat the research cost himself. The poor developer, who wants to save money for the project owners in the first place, are now being taken advantage of.
Third, no matter how you put it to them, business owners don't like to have liability. What's the difference between liability and cost? If the charge is one-time, then it's cost, if it's recurring, then it's a liability. The reason why fix-price is so popular is that it's a cost, not liability. The bill-per-hour project will create the impression that a software project is spiraling out of control because no one knows when the investment can stop. Now, you may say that bill-as-we-go-along should be OK because the project will pay for itself along the way. But under this optimism there lies an assumption: that the projects can generate tangible benefits, or revenue in a short time. There are lot of times when the business or operation stumble even though the software behind them are perfectly done. Code is not everything in an endeavor. Not the mention the possibility that the payback time maybe longer than the project period. Furthermore it ties the software developer to the business risk, a risk that the software developer has no inclination to share.
As a software developer, I wish every single project owner will understand the reality of software development ( and their fickleness) and adopt bill-per-hour approach. But before I can expect that, maybe the software development community should address their concern first.
