

Should Programming Work be Billed in Hours? - nsoonhui
http://itscommonsensestupid.blogspot.com/2009/08/should-programming-work-be-billed-in.html

======
abalashov
I think hourly billing is bad for two reasons, even though I do it all the
time:

* It just limits the amount of money you can make. People have a strange psychological approach to hourly figures; once you hit a certain rate that they consider alarmingly "high," which is a metric that varies immensely, their eyes just sort of glaze over and they go, "ooof!" But if you give them a fixed bid that assumes x hours and comes out to an equivalent hourly rate that is ${quite high}, they seem to be just fine with that - in my experience, this is often true _even if you itemise it and declare the expected hours_. Some sort of fixed bid leaves a lot more room for padding in case things don't go as expected, and, if you're lucky, more profitability.

* Programming workflow just isn't linear like that. We've all read Joel Spolsky's "Human Task Switches Considered Harmful." In addition to that, programming problems are often solved in strangely noncontiguous, out-of-band ways, like coming up with solutions to a vexing encumbrance in the shower.

The point is that billing should attempt to reflect the actual workflow as
closely as possible, and the workflow of a programmer just doesn't go like an
auto shop's. If you have a 20 hour project, doing 5 hours here, going off to
do something else, and coming back to it and doing another 5 hours _doesn't
mean the project is 50% done_ \- at least, from a practical perspective.

Being a very small business myself with no credit facility and no savings or
cash buffer whatsoever coupled with relatively high living expenses inherited
from my employed days, I face the additional issue of severe cash flow
constraints when I attempt to float long projects that pay hourly. I describe
this more extensively in this comment:
<http://news.ycombinator.com/item?id=746517>

For me - as for many freelance programmers and contractors - I think the right
choice is some sort of flat weekly billing, and splitting up any project of
nontrivial size into smaller, manageable and well-defined milestones. If you
can get away with it.

I think it's pretty fair to say that you often can't do a linear, 1:1
relationship between time spent toward project and money paid. One caveat is
the one I pointed out above. The other, more generally, has to do with the
fact that at 100% completion code acquires orders of magnitude more economic
utility than when it's 90% complete. At 90%, it's just a useless blob of code
as far as most customers are concerned. At 100% it's a finished deliverable
that does what they want - or thought they wanted, whatever. So, usually
there's a bigger balloon payment at the tail. It's not realistic to expect
that when you have 7/8ths of the project done, you'll have 7/8ths of the money
in hand. There are other reasons for this as well; see the link to my other
comment above. But I think one should strive to get as close to that possible,
insofar as it's possible to measure % completion to any degree whatsoever.

------
pj
I think tools are an important part of the equation.

Say you are paying someone to demolish your concrete driveway. Would you pay
someone with a jack hammer who can get the job done in an hour the same rate
you'd pay someone with a sledgehammer, which will take 8 hours? The task is
the same. The value of the completed project is the same.

But if the jack hammer owner charges a fix bid billed for half the hourly rate
of the sledge hammer owner, he spends an hour and gets paid for four.

In a fixed bid contract, the jack hammer could charge 50% more than he would
estimate the demolition (originally billed at half the hourly rate of the
sledge of 4 hours) at 6 hours and still make more money and spend less time:
6x as much money and spend 1/8th as much time completing the job. If his
estimate was _way_ under actuals and it ends up taking him _twice_ as long (2
hours) as he originally thought it would take, which was 1 hour, he still
makes triple the hourly rate for two hours of work (6 hour billed estimate, 2
hours of work) than the guy with the sledge hammer!

The use of tools that accelerate task completion, in this case an 8x
improvement (jack over sledge) enables the jackhammer operator to
underestimate the labor times and still make more money at lower times to
completion. Plus, the driveway owner gets his demolished driveway in 25% of
the time that it would have taken with a sledgehammer and that is _still_ at a
project overrun of 100%!

But the world doesn't understand equations like this or really accept the
value of advanced technologies. I use technology to build custom software
products that are way more advanced than what typical developers use, so I can
build them 10x faster and charge half the rate and still make more money!

I know a local case where a company is paying a guy to use Perl to build a
data driven website using files -- instead of an SQL Database. he's been
working on the website for over 5 months and it still isn't finished and it
has already reached the maximum of its flexibility. It's already going to have
to be re-architected to enable the features the client wants now. If the local
company had gone with _our_ company, which uses a flexible sql based
infrastructure, then the project would have been completed in about 2 weeks
and still have lots of flexibility to go! New features would be easy to add.

Now, the programmer is coming to us asking to use our technology to help him
complete his project!

So, I love the current state of the software world. Frustrated customers
paying too much for projects that typically fail are a great market segment.

~~~
pmichaud
What tool do you use?

~~~
pj
Qrimp

~~~
pmichaud
Interesting -- I'd like to talk to you about it in more detail, if you have a
moment. I'd shoot you an e-mail, but none is listed!

------
BigZaphod
For my latest contract gig, I decided to try a slightly different approach
than tallying and billing hourly or guessing at a fixed-cost. We're going with
a "retainer" model which more or less makes me into an unofficial employee,
but the idea is that they get X number of hours per week of my time. Deadlines
and such are attempted to be met within those constraints.

The upshot of this is that they have a clear and known rate of expense. If the
project doesn't appear to be progressing fast enough, they could increase the
hours per week they pay for, hire more help, hire someone else, or wait
longer. :)

The tricky part is getting into a deal like this without them trying to attach
things like, "ok, you work 20 hours a week on our project - but if it's not
done by the 3rd, we don't pay you." or whatever. But if you can avoid that and
get them to think of you as an employee and not just a code factory, it works
out.

------
cgs
Bill by the project. You can use your hourly rate to estimate the fixed cost.
The more projects you do, the more accurate your estimate will become. Over
time you develop your own time-saving methods, such as pulling code out into
reusable libraries you can use on your next project. Say you do a project that
takes you 50 hours and you charge $5,000. If you get another similar project
but this time you know it will only take 25 hours, are you going to charge
$2,500 for it? Hell no! Charge as much as the market will bear, but set some
kind of a minimum threshold for yourself. Here's an old article relating to
technical writing, but I think it still applies to software development:
<http://www.writerswrite.com/journal/jan98/kent.htm>

~~~
jamesbritt
"You can use your hourly rate to estimate the fixed cost"

Only if you know how long it will take. Which assumes you know what you are
going to build, which assumes the client _really_ knows what they want.

If you are doing a more agile project, you expect new requirements to come up,
current requirements to drop out, things to change along the way. But you
almost certainly have no solid idea how long it might take.

A mixed approach might be to make a big project into a series of smaller
projects (e.g., well-defined and doable in 1-2 weeks), and bill each at a
fixed price.

------
patio11
I have never quite gotten billing in hours. The value of a project is utterly
uncorrelated with them. The number of hours to accomplish X goes down as the
skill of the individual goes up.

What sane model is it that says hiring average people to do unimportant work
should cost more than hiring experts to do things that really matter for the
business?

~~~
BigZaphod
That's why as skill increases, the hourly rate should, too. If a company is
looking to get something done faster and are willing to pay for it, they can
hire the more skilled/faster professional. If that's less important to them,
they hire the slower and/or sloppier but cheaper alternatives. You have to be
willing to increase your rates if you're getting better/faster.

If you're an employee, that's why you should be able to expect raises and
bonuses and the like. The assumption is that you're getting better and better
at what you do and therefore becoming more implicitly valuable. If you feel
yourself getting more and more skilled but the company refuses to reward you,
you should leave for someone else who values that skill - which is basically
the same thing as raising your hourly rates if you're independent.

------
jokull
Day rate is the way to go. No time tracking, include an hour break for
chatting and eating.

------
bmelton
Billing by the hour is the only effective way I have found to eliminate scope
creep. Being able to say "Well, sure, I CAN do that, but it's going to cost an
additional 4-6 hours" is simply the easiest (and most well received) method of
indicating that they are asking for something not initially agreed to.

Obviously, it helps to have a contract/requirements
documentation/specification/etc., to point to, but it's rare that you run into
a document detailed enough to cover nuances like whether or not this element
should be blue or light blue after clicked upon.

~~~
pj
If you billed fixed rate and the client changes the requirements, then you
change the fixed rate.

Say you estimate the cost at $10,000 and they want you to make a change, you
say, "Okay, but this change wasn't included in the $10,000 so we will have to
estimate how much the change will cost and add it to the bill. If you want us
to do that, let us know."

This is why you have to outline the requirements before you do a fixed bid.

Instead of saying it's going to take 4-6 more hours, you say it's going to
cost $400-600 more dollars, assuming you estimate at $100/hr. If it really
takes you 1 hour, then you still make $400-600, but it only takes an hour so
your hourly rate just went from $100 an hour to at least $400 an hour.

If you're a highly productive programmer and use the right tools, then a fixed
bid can come out in your favor if you estimate projects using the hourly rates
and estimates that not so productive programmers use.

~~~
jamesbritt
'Say you estimate the cost at $10,000 and they want you to make a change, you
say, "Okay, but this change wasn't included in the $10,000 so we will have to
estimate how much the change will cost and add it to the bill. If you want us
to do that, let us know."'

Sometimes it's really that simple. Other times, you end up debating whether
something is a 'change', or 'clarification', or some replacement, or whatever.

The upside of fixed bid is that you can do quite well when the process is
well-defined and everyone is reasonable. The upside of hourly is that you get
to offload assorted issues (i.e. prolonged requirements gathering, change
requests, and ad-hoc requirements finessing) and focus on the work.

For every person I hear advocate fixed-bid, I hear another advocation hourly,
and each swears experience is on their side.

------
TrevorJ
Where I work we bill fixed bid and then go hourly if there is a scope change
above and beyond that. It's the best of both worlds.

------
access_denied
No, to answer the original question. But I've heard it ties well to agile dev
methods.

