The Curious Nature of Hourly Rates

There are some services for which I think the model of charging based on an hourly rate is appropriate. Software development is not one of them.

Consider: some services fit the hourly model to a T. These are jobs where the hours spent are directly proportional to the value realized by the hirer. It makes sense that getting the hour long massage costs roughly double what the 30 minute session does. Or manning a reception desk. When somebody needs to be there, every hour that a body is there that creates value and fulfills a need of the hirer.

But software development runs counter to this notion. We programmers are pretty much always hired to solve a real problem stemming from a real need, not to provide hours of coverage hunched over a keyboard, and certainly not to provide extended enjoyment for the client by virtue of working longer hours (the massage therapist might hear the phrase “hey, that’s nice, why don’t you do that a little longer?”, I don’t think a programmer ever has).

No, in software development it’s virtually always the opposite: the longer a project drones on, the more painful it is. Just ask any stressed-out looking project manager who keeps getting excuses and pushed back deadlines from her development team.

But doesn’t more hours mean more quality?

Maybe, but that correlation is sketchy at best. To realize a given set of features, a pro can often do it both better & faster: the number of hours spent becomes an argument against quality, not for. (I’m much more apt to trust that a WordPress install got done right by someone else if it took them 15 minutes rather than 3 hours.)

Programmers can (and should) be hired on the overall demonstrable quality of their work, and a review of their portfolio plus a mutual understanding of the level of thoroughness/quality that is called for (throw-away prototype or enterprise level masterpiece?) keeps the fixed price model honest. (Because yes, without that mutual understanding a developer could hack the fixed-price model by racing through a project and cutting corners, to say nothing of whether or not he’ll be hired again).

Alignment of Priorities

If we can assume that a contractor is guaranteeing satisfaction (and we probably should, right?), than a faster execution of a fixed-price project is in the best interests of both parties. The client gets what they need sooner, and the effective hourly rate of the contractor is higher. When an accurate sense of the quality to be expected and a correlate price tag are established, the fixed price model creates this nice alignment of priorities between contractor and client.

By contrast, hourly creates a misalignment of priorities of client and contractor: the contractor gets rewarded for dragging their feet and making problems out to be more complex. Not a huge amount of course, because in the logical extreme they’d get dumped sooner or later. But it’s just too easy to milk the clock and divert energy from actually solving the problem, to instead convincing ones self and others that it’s more difficult than not.

Effective software development is all about fewer smart hours as opposed to longer hard hours. Pricing for it should probably then reflect that, and by the same token programmers should probably strive to avoid the Curse of the Hourly Wage.

I also prefer fixed-price, except for troubleshooting a complex issue. Finding out what needs to be done to solve the issue, may take unpredictably long, and is usually 99% of the work. The change itself, may end up taking 5 minutes.

I’m with you there in the case when it’s work on a system that I didn’t build. In that case I’ll probably spend 10 minutes poking around to see if I can’t name a price that I’m willing to be held to. If I can’t, I’ll either reluctantly offer up an hourly rate to fix it (with a cap), or pass on the opportunity.

If it’s a system I DID build, that’s 100% on me–fortunately I can trust the solution will not come with hidden pitfalls (and if it did, I’d learn something and be a better programmer for it).

This is interesting an interesting topic, there’s actually a movement in the legal profession to move away from hourly rates. The articles that my wife, a lawyer, keeps pointing to make similar arguments to this post.

As someone who is a programmer currently and who has a past in custom framing I will say this about the hourly rate.

The hourly rate protects the worker from risk, at the expense of the client.

This is important. For typical jobs an hourly rate makes no sense. A worker should have a rough idea about how long a typical task will take. They’ve done them before, many times. As a framer, we’d quote jobs and have no problem turning a per job profit. However, whenever we ventured into the unknown, weird jobs that we’d never done before, we were very clear that we charged an hourly rate.

You can really find yourself screwed if something takes a lot longer than it looks like upfront if you only charge a flat rate. What’s worse is when there is some dispute as to what was requested, and the client claims XY or Z was implied by the contract. If these things require far more effort than an hourly rate can really CYA.

This all said. I really do expect clients to be happier with flat pricing, and encourage it for cookie cutter type jobs. Just make sure you’re charging how it makes sense based on the job.

I always do hourly because I’ve never been involved in a project where the exact requirements and acceptable solution are known upfront. And things always change as they see the solution being built. I also put a term in contracts saying that they can (at their entire discretion) not pay me at all if unsatisfied with the work. (I’ve always been paid and usually given bonuses.)

Another way of phrasing things is that hourly is good when there is uncertainty about the solution (from the customer) and fixed price is good for certainty when they know exactly what it is they want.

When I decided to start up my modest consulting company this was in the forefront of my mind. I read your article and heard many of the same arguments I make against the hourly model. I think you are spot on and in the end, fixed-bid project based work will make for greater profit per hour and more satisfied clients.

Wrong. I have never been on a project where the specs didn’t change. I was working for one client and he gave me an incredibly short job, 4 hours or less and I told him that. Finished it easily in that time and turned it over to the client. ‘Uh, yeah this is what we asked for, but it now that I see it, it doesn’t do what we need…..

Similar on any project any size, the client doesn’t know what they want – or what will fill their need until they see it. But maybe your just better at guessing the clients needs.

It is really surprising to see such a statement from an experienced person. Software development is complex beyond the comprehension of the person commissioning the work, but often things get overlooked by the consultancy as well.
In other articles you write about clients changing the requirements and generally not having too much clue.
True – in an ideal world, you’d get frozen, well-crafter requirements and you could estimate the work accurately.
But this is real world and requirement do change, often for a valid business reason (perhaps integrating with MySpace is not such a priority as it was a few years ago, when the spec was written) and you’d have to draw a whole new contract each time, possibly even sue.
Since most coders prefer to write code than draw legal battles over the scope of the project, it is much easier for both sides to charge for time spent – in such an approach it is in the best interest of the client to get finished sooner rather than later, so they will be somewhat forced to provide input and validation – otherwise they’ll have to keep paying and have an unfinished product…

@Lech
Interesting! I never considered the whole drawing up a new contract/legal battles aspect, and it suggests that my approach to Spec’ing out projects might have something to it more useful than I realized.

My convention is to break a project down into clear line items of features at a level of granularity much like you suggest (i.e. “Integrating with MySpace”). I assign a price tag to each one, and the sum total is our contract price. I roll with real world changes such as you describe simply by scratching out line items that turn out not to be wanted (provided I’ve not yet built them). We mutually know how much that reduction should affect the price, and you’re right: we’d rather code than draw legal battles, so of course I’m not going to fight them if they want to take out a piece of the original contract.

And for new requirements that pop up? No problem, I scope and bill those out a la carte style. By the time we get there, we’ve usually got a solid rapport and trust, so no new contracts or signatures are required–I’ve never been burnt by this approach, and on the contrary clients seem to find it really workable and refreshing.

I disagree about WordPress. Three hours is more what I would expect. I would be more worried about a 15-minute install which probably doesn’t include:

-my.conf optimization
-extra security precautions
-off-site backups that are actually off-site
-disabling plugins that don’t need to be active
-making sure images/posts that were posted during propagation weren’t lost on the old server
-matching permalinks with the previous host
-moving you to a server that’s geographically close to your target market
-recommening obvious changes that could double your ad revenue overnight
-nginx optimization

Have to agree with Roger – fixed pricing makes no sense in an Agile environment, where it’s best practice to regularly communicate with the client on changing requirements.

Fixed pricing works for static products or services. C’mon everybody knows that software dev CANNOT be tangible…or have you forgotten about the perils of waterfall? Your pricing seems incompatible with agile, that is all.