Search This Blog


Saturday, August 8, 2009

Should Programming Work be Billed in Hours?

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. 


MarkK said...

I have at both side of ordering software. And I think what you forget to mention in your article is the needed trust between software developers and the ones who order the software. As soon as you have trust, it doesn't matter if you charge by hour or you do fixed price - customers knows you would not charge him more than it actually costs.

What is tricky, is how to build this trust :)

Soon Hui said...

Hi MarkK,

Great insight, but business doesn't operate on trust.

Shimon Amit said...

Trust is the foundation of every healthy economy. And if I don't have trust, I will not do business with you. Period.

BorisG said...

Trust +1
Very important part of business.

The whole economy almost crashed because lack of trust.

Yeah, business does operate on trust.

Soon Hui said...

Yeah, business does operate on trust.

Even if it does, what does that lead us to? Should programming work be billed in hours, or not?

BorisG said...

Give a clear estimate with items not more than 16hr a task.

If you're a good estimator, up the tasks with 1 hour

If you think you might hit a reef, double the hours for a task.

If you're a bad estimator and tend to underestimate, double all tasks.

Write a clear work statement and agreement about liabilities and responsibilities for each party.

This way for you it's hour based and for business owner it's a fixed price.

Dennis Gorelik said...

That's a good explanation why common practice in software development is to charge hourly.

So, is there any better way?

jason gorman said...

I've found that billing for each acceptance test passed in an iteration/small delivery works very well. Non-functional/quality acceptance tests also need to be explicitly agreed. In both cases, executable tests work best. Tools like FIT or Story Runner help with functional tests. Metrics, code analysis and performance tools can help automate some non-functional tests.

Lars Thorup said...

In our company we now have experience from two commercial projects using a new kind of agile contract.

The contract defines the following elements:

* Scope described loosely in a few paragraphs, a kind of vision statement
* An hourly price, that is 10-50% below what is normal for pure time-and-material
* A set of milestones, which will lead to payment of a fixed amount. The simple criteria that tells that a given milestone has been reached, is whether the software is deployed in production.
* A development process following agile practices
* A suggested time frame for the overall project and for each milestone
See my blog entry on Collaborative Agile Contracts for details.

Thomas said...

Pretty good writeup, another problem is that the public sector ALWAYS seem to demand fixed costs project (which in according to the CHAOS report in ~60% of the cases means budgets cracking with an average of 189% and in 16 percent of the cases are not even finished at all)

For those interested in this subject, there might be some interesting things in the Lego Process Manifesto :) - which can be found here

PS! The video is a teaser and doesn't go into details, but the document itself goes into a lot of these issues, especially in regards to Agile ...

Travis Dunn said...

The choice for the client is obvious here: fixed if you're uncertain about a developer's qualifications or trustworthiness, but if the relationship is stronger then hourly billing is optimal.

The other issue which isn't being discussed here is how much the nature of a project can influence decisions of billing. In the cost vs. liability scenario, it seems to me that both parties would want to identify and select the billing plan that works best for the project at hand.

Soon Hui said...

Hi Dunn,

I afraid the software community at large also doesn't know under what situation, which model is applicable.

This is something that we have to figure out.

Chris Graham said...

Excellent article.

There's another very important facet not yet discussed. Provider time and resources are finite. If the provider has multiple clients, and is likely to be taking on new clients, being tied into commitments where the client wants the commitment to be elastic can be a problem.
For example- imagine a provider working on an hourly basis is working on one project, which grows and grows - and the schedule unexpectedly over-runs into the planned time for a new future commitment that was scheduled previously. The provider could hire/train more people - but this takes time, investment, and is a big risk (who knows when the ongoing project might finish), or the provider can choose to let someone down - either someone who has already had their project scheduled, or the client who thinks the project is completely elastic.

Fixed-price contracts reduce risk here by managing expectations - providing the provider more time to plan capacity. Of course it doesn't completely remove the problem, but at least the provider can say "okay, I can schedule this new phase of development in in a months time".

Anonymous said...

That's too bad. I got fired because of over budget hours.

-mika- said...

Billing by hour is not real if you cannot miss the estimate. It is just fixed price then. But unlike normal fixed price contracts that are negotiated between salespeople, hourly estimates are more often negotiated with programmers.

Our salesman and CEO have put a strict upper limit on how many hours a programmer can negotiate. This is because programmer's estimates are usually too optimistic and there really is no possibility to miss the estimate and charge the real hours.

If estimates go through sales/support people, they usually add something like 100% overhead.

Michael Langford said...

Hourly gives more *control*

Fixed fee gives fewer uncertainties.

Ideally, you want fixed fee for a core, then hourly for customizations.

The part the client has to see to understand is fixed, then the client can spend money till the cows come home tweaking.