I would phrase this as "bill based on your natural work increment".
If you're working at the thrift store putting price tags on shirts, your timeclock is probably in 5 minute increments. If you're a defense contractor bidding on a major combat platform, your minimum increment is probably ten engineers worth of salary. Anything smaller than "the increment" is probably a rounding error, which is a headache for both parties to track.
For independent software engineers and consultants, I can see reason to bill hourly, half-days, days, or weeks -- based on what's "standard" in terms of project size and work flow for you.
Your natural work increment and your fee structure are not the same thing. When you freelance, you aren't being compensated solely for your effort; you are providing much more value than that. Factors that go into freelancers getting paid more include:
* Access to talent on predefined schedule
* Minimal commitment to that talent, instead of a year of salary
* Allocation of that talent to your projects as opposed to some other company's projects
It is a really pernicious meme that developers should consider billing hourly because they work hourly. When you switch from salaried work to freelancing, you need to start thinking of your work product as a product, not simply the output of your brain connected to a keyboard for fixed periods of time. You don't price a product based on its raw cost structure; you price it according to the value it provides to customers.
I don't mean that you should bill hourly if you can measure your work in hours. I mean that you should bill hourly if you want to run the sort of business where you work on six different clients' smallish tasks each day (say, simple web stuff with minimal ramping), like the setup ErrantX described elsewhere.
As you say, this is based on value provided to the customer. If you're working with clients who are going to want you to do $100-$1000 worth of low-complexity work for them in any given month, an hourly fee structure is going to let you serve that client base, while a daily structure would not. If you're working with clients who are going to want you to do $10000+ worth of work for them on a single project, a daily or weekly structure is going to be more convenient for everyone. If you're working for the DoD on military hardware, you might charge 10 figures of development fees and 8-9 figures per unit delivered.
Pick a billing structure based on what's natural for the sort of projects you're doing in the market you're serving.
Ok, but there are a bunch of reasons why I think you should actively avoid "markets best served by hourly work":
* It positions you against the lowest-quality cheapest providers.
* It misaligns your incentives, so that you're penalized for doing a better job.
* It totally hides the cost of ramp-up and ramp-down (if you think clients push back on daily or project rates, wait until you charge them for 2 hours of "getting in flow").
* It forces you to be vigilant about time tracking lest you accidentally undercharge customers.
* Not to mention, with virtually any client worth doing business with, you (the consultant) are much more sensitive to the cost of a project than the customer is; it is a small miracle that the customer can get a programming project completed at all without potentially hiring and then firing 3 different people. So why is all the burden on you? Why is any of the burden on you? Key consulting idea: it's not the customer's money they're spending.
* It inclines you towards finicky accounting, the kind that charges a customer for a 45 minute phone conversation.
* It conditions your customers to take a fine-tooth-comb approach to project plans and invoices.
* Not to mention: it generates more invoices.
* It forces you to negotiate with clients in the worst possible numeric domain: where small deltas to proposed rates disproportionately impact the final cost.
* It obscures the final cost of projects in ways that make clients defensive, so that their immediate thought is "oh shit this is going to add up to lots of hours we better be careful".
* For that matter, it inclines your projects towards the small and away from anything ambitious.
* It impedes your own flexibility, so that you tend to miss opportunities to interleave projects or for that matter take an occasional long lunch.
* It forces you to account for every waking hour of your day in a way that daily rates don't, when we all know that only a small subset of your work hours are truly productive.
* It makes it harder for you to reasonable toss freebie work to your best clients without damaging the expected value of your time; for instance, I can cab over to a client in Chicago and spend 2 hours looking at a design with them for free without creating the appearance that my bill rate is arbitrary.
So why does a daily rate avoid this? It's just a larger unit of measure. It seems to me that you're really advocating charging for the value you provide, so you should quote a price for the project and leave any units of time out of it.
If you're working at the thrift store putting price tags on shirts, your timeclock is probably in 5 minute increments. If you're a defense contractor bidding on a major combat platform, your minimum increment is probably ten engineers worth of salary. Anything smaller than "the increment" is probably a rounding error, which is a headache for both parties to track.
For independent software engineers and consultants, I can see reason to bill hourly, half-days, days, or weeks -- based on what's "standard" in terms of project size and work flow for you.