A conversation with a client (who may be reading this now) prompted me to think over my payment structure.

My current rates for consulting are almost all hourly, even though I greatly dislike charging hourly rates: first, they’re predicated on the amount of time I’ve worked rather than what I’ve produced (and I’ve never held myself to a proficiency standard that said mere effort without results was ok). Second, they penalize me for working quickly. Charging by “lines of code” has similar problems, for conciseness instead of time: I can write one line of Perl that does what may take 10 in C++, for instance, but that one line may take as long as the 10 did to write.

I used to charge per-project rates. Unfortunately, aside from the difficulty of estimating an entire project in advance, my past experience has demonstrated why it is a truism never to accept a per-project rate that is less than four times what you think the project is worth: extra features.

It is common for features out of the initial requirements specification to crop up midway through a project. On a fixed budget, you are placed in the difficult position of refusing to implement the features (which annoys your clients), modifying your estimate (which might be difficult or impossible), or performing the extra work for free (which isn’t fair to you).

The model I’m now considering is a milestone-based model, under which milestones are set with particular deadlines and fees. From the time a milestone is agreed upon to the milestone’s completion or deadline, features leading up to it are frozen. Additional features can be requested, but these become part of the next milestone and factor into the cost estimate. This way, the client gets what he wants, you get compensated for the extra features, and your development time remains predictable. Everyone’s happy.