
Why we bill by the hour - soundsop
http://squeejee.com/articles/50-why-we-bill-by-the-hour
======
JoelSutherland
As always, it depends.

On the product end of things a fixed price makes a lot of sense. Squeejee
builds custom web applications...billing hourly for that is a no brainer.

Much of everything else is a hybrid. I would expect that I could get a
reasonably accurate estimate for painting my house based on the experience of
a painter. With a fixed set of requirements and a familiar problem domain, I
would think Squeejee could do the same.

~~~
subwindow
The house painting analogy fails because in software development, you only
have a vague idea of how big the "house" is.

No painter would give an estimate for painting a house, sight unseen, with
only vague descriptors. But yet that's exactly what fixed-bid contracting is
for software development.

~~~
JoelSutherland
Clearly the house painting analogy fails. All analogies do. My point was that
the two extremes are fixed-bid and hourly.

For the sake of a client, a programmer with some expertise should be able to
give a reasonable estimate based on a set of requirements.

I would say your house painter analogy fails as well. Fixed-bid contracting
for software development is nothing like painting a house sight unseen, with
only vague descriptors. Analogies aren't really the point though...

------
subwindow
One of the most harmful results of fixed-bid contracting is that it gives
offshore developers a huge advantage. It'll take them three times as long and
they'll ship a worse product, but the "shipped" cost will still be lower. You
don't see the hidden costs like maintainability and poor code quality until
afterwards.

~~~
scylla
The advantage is equally huge for time & materials. $25/hr vs $75/hr. Do you
think management anticipates that it will take three times as long?

~~~
modoc
Absolutely true. The advantage is the same regardless of billing model.

I've found you can't compete against off-shore outfits on price if you want to
keep making money. So don't even try. Your competitive advantage is quality,
communication, and responsibility.

You can deliver high quality product, designed for extension/enhancement in
the future, and can communicate clearly with the client, and understand what
they want (without them having to create a 50 page requirements document
covering every tiny detail), and after the delivery they can call you up, and
speak to the same person they talked to before, on the phone, and you'll take
personal responsibility and pride in your deliverable. That costs more. End of
story.

You won't get every client, but trust me, the ones that just care about the
lowest $ figure above all else, aren't the clients you want to have anyway.

------
brasmusen
All of my current client projects are hourly. I typically give them an
estimate so they have a ball park figure and then bill hourly and update them
as the project progresses. This seems to work out really well.

The only downside that I see so far is that as you get better as what you do
you tend to get quicker as well, which in an hourly arrangement means you make
less. You can always raise your rates as your experience grows but for
previous clients it can be hard to explain.

~~~
tstegart
If you get quicker, doesn't that give you time for more projects?

~~~
sokoloff
Sure it does, but if you're working hourly, you're still making the same total
$, working the same hours, just over more projects.

For me, while I do love coding, my side projects truly are a means to an end
($$ to put in a home theater, or take a trip, or do whatever else I want to
do).

Hidden in your question is the kernel of why fixed-bid is better when your
skills (in terms of lower hours-expended for a finished-system) are better
than your competition, and you can sell it.

Now, all that said, I'm wrapping up a fixed-bid (~$25K) side project where
scope creep is killing me on my (effective) hourly rate. It's still fun; I'm
learning a lot about things I don't do in my "day job" and I'm almost
certainly going to get more work from this client if I want it, but I made the
mistake of bidding fixed-price with some assumptions about the scope that were
ludicrously off. (My fault, not the client's, and I'm eating it. If the work
weren't fun, it would be an extremely bitter taste...)

I'm still in favor of the fixed-bid (as it makes the sales job much easier),
but watch scope creep.

One last important point: if you are bidding fixed because you are a great
coder and a poor salesman, your lack of sales/negotiation skills may be an
issue when the client thinks something was in scope and you think it's out of
scope. If this is a possibility, figure out your strategy ahead of time, or
you'll end up doing the feature "for free".

------
modoc
Fixed bids aren't so bad. The trick is learning to do really good estimates.
Figure out how much information/requirements you need in order to create an
estimate, and get that data first. Document what YOU understand the scope of
work to be (separately from the provided requirements) and make that the basis
for your fixed bid.

Many customers will prefer a higher priced fixed bid, rather than a lower
prices hourly based estimate, because they can budget for it (or get budget
for it) without worrying about overruns. Many less scrupulous development
firms (or people who just can't estimate very well) end up billing well over
the initial estimate when doing hourly invoicing, and many customers have been
bitten by that before.

In my experience smaller client will be more likely to go for the hourly
approach, due to the initial estimate being lower, and feeling like they have
more control over the costs during the course of the project. Larger companies
almost always work with fixed size budgets approved on a project by project
basis, and so having a fixed cost (even if it's potentially higher) is key for
their internal budgeting and resourcing. Plus it protects against the overruns
hourly project can bring. I've never seen a Fortune 500 outsource a full
development project on an hourly basis. It's almost ALWAYS fixed price, just
due to how they handle their own budgets.

The trick, imho, to good fixed price cost estimating is to get the best
requirements you can up-front, and restate them yourself in your SOW, broken
out by task groupings instead of however the client structured them. Clarify
any potentially nebulous requirements/tasks yourself, and let the client know
if they want to change the way you've filled in the gaps, they can do so, but
you will need to submit an addendum to the invoice for any changes they make
(unless otherwise agreed upon - i.e. same effort swaps of un-developed areas).
Once you have the overall task list figured out, do your internal task
breakdown and estimates. Then, pad your estimates out by perhaps 50% (this
depends on how good you are at estimating, and how many times you've done
task/feature X before).

If I have a task doing something that I haven't done before (i.e. some sort of
crazy-cool ajax front-end wizardry (I'm a back-end guy)), I'll pad that out a
bit more, since I'm likely to run into a snag or two along the way. If it's
something I've done 100 times before (i.e. user
registration/login/logout/forgot password flows), I don't need to pad that,
since I can estimate that pretty exactly.

Also, don't worry if your padding seems high, or your SOW price seems too
high. The client always has the option of doing an hourly approach instead.
It's up to them. The more projects like this you do, the better you'll get at
estimating, and it becomes second nature.

------
ii
That's the main reason why languages like C++ and Java are so popular. Getting
paid for amount of time or amount of code makes succinct and simple solutions
less interesting for developer.

As we all know, succinctness = power. Everybody lose in the long run when
developers are not motivated to solve the problem in less time with less code
and as simple as possible.

I'm amazed that some people treat it as something "so basic".

~~~
modoc
Did you just say that the reason C++ and Java are popular is developers don't
want to spend clients money writing everything from scratch (in what?
assembler? fortran? C?) in the most simplified way possible?

I don't even know where to start with that. Using existing code libraries for
common tasks means less development time/cost, higher quality code (the code
has been tested by thousands of people over months or years), and easier
enhancement/extension in the future (the code already solves for many common
enhancements and/or is built in a modular/configurable/etc... manner and so
on).

Writing your own "super-awesome-optimized-magic"
ORM/Internationalization/Transaction Management/Caching/Encryption/MVC
framework/XML parser/etc... is generally a bad idea for you and your client.

~~~
ii
No, I just say that getting paid for amount of time motivates developers to
write complex and bloated code in complex and bloated languages. There was
nothing about "writing from scratch" or libraries available.

Example: client wants new feature -- if my language and my platform let me do
it in one line of code it's bad for me if I get paid for time, thus people
choose languages and platforms where even trivial things can be written with
some bloat.

------
ryanwaggoner
I wish more clients realized this and were comfortable with such an
arrangement. It does require a great deal of trust in your developer, though.

------
huherto
I agree.

Though the customer may be afraid that the developer can just start piling
hours without real productive work. Still, I think the customer has the
possibility of asking for a replacement of the consultants if he does not see
good results. Later on in the project may be harder but still possible.

~~~
jmtulloss
I think their answer to that was the short development cycles. If they're not
the team you want, you'll see that in two weeks instead of 6 months.

~~~
modoc
That's assuming the client can tell the difference. Most non-technical clients
won't have a clue how long something should take.

------
pkaler
Billing by the hour may be way too granular for some projects. Contractors
should also consider day-rates. It can be a good compromise between hourly
billing and fixed bids.

------
DanielBMarkham
I'm in favor of T&M (Time and Materials) work for software development, simply
because the universe of solutions is so broad.

Having said that, the argument put forward in this article is nowhere near
complete. Yes, when you're getting paid by the hour the client has his foot on
the gas pedal, but in reality he's already sunk a big hunk of money on you,
from his standpoint on a long project it can easily look like throwing good
money after bad.

Yes, agile techniques make clients happy faster. But it all depends on where
the risk is. And there is a difference between the client and the users. If
the users have a hard time making up their mind what they want? Then the
software process becomes part of a business decision support system. The team
interviews multiple stakeholders and facilitates negotiation and conflict
resolution.

You might say "that's not software work," but that's the real world with real
humans in it. In that case, it could be easy for the client to see bills every
week or two for what he thinks is just a lot of talking, From his standpoint,
he just wants the coding done -- and of course the users should be happy.
(grin)

Because it is so complex hourly is the most straightforward way of working.
I've been watching this scene for many years, though, and I have the sneaking
suspicion that fixed price bids are what separate the men from the boys when
it comes to delivering technology solutions -- mainly because the
profitability can swing wildly from rolling-in-the-bucks to sucking-wind.

~~~
cdr
You lost me past the first sentence.

~~~
DanielBMarkham
Bill by the hour, unless you want lots of bucks. If you do, suck it up and
learn to go fixed price. I never had the guts to do it.

Hourly billing is not perfect. There are lots of ways to screw it up too. The
author should have told you that.

Work any better? I've been told I ramble. Hope that helps.

~~~
hhm
One way to screw hourly billing: you feel compromised to stay in a project
until it's closed, but the project hasn't a close date, so it might never be
properly closed. But you might actually want to get out of it to do some other
interesting or more expensive work, and if your client feels like it, he/she
might never really free you from your project. That's one danger of hourly
billing for hourly beginners.

~~~
DanielBMarkham
My first "pro" hourly gig ended up going week-to-week with no end in sight. We
were doing a great job, but the VP who was paying us was fighting with another
VP over who owned the program. After 2 months I had enough and left. A year
later the team was still there.

------
sosueme
in the squeejee factsheet pdf one of the projects listed is WildFire Viral
Business Marketing Application www.sparkwildfire.com

except the url that gets copied into the clipboard on winxp foxit pdf readed
is www.sparkwildire.com

I have no idea why.

------
ojbyrne
This is so basic, I'm amazed it still needs to be said. But I understand why
it needs to be said (lots of idiots in the world).

