Clients start haggling on a hour by hour basis sometimes. Some want to review tasks and how long each took and whether the hours add up. Sometimes, it takes so long to figure out the conclusion of the haggling, that you've already lost 2 or 3 hours of non-billable time on the haggling itself.
With weekly billing, the haggling is reduced.
If you do daily or weekly you don’t register time in 15mins increments to later argue with the client.
It seems to me there's no fundamental difference for the context of this article; it's still flat rate vs unit-of-time based work, isn't it?
I've written a lot about this on Hacker News over the years; like, a lot a lot. Here's a starting point:
https://news.ycombinator.com/item?id=6105004
I don't think anybody in our field should ever be billing hourly. Day/week/month/quarter vs. flat rate? We can go back and forth on. Just don't do hourly.
This comment is I think too subtle to lead off with, but it's the essence of where I'm coming from on this:
https://news.ycombinator.com/item?id=4103207
(I have had some moderate success with this approach, which makes this a rare case in which my confidence in arguing something here has at least some colorable basis in reality.)
The other advantage is that hourly tracking gives me data to predict better what new features of similar complexity will cost. Certainly not an amateur capability.
I just say this has a complexity of 1,3,5,8 or 'too big to say'. Each feature is a 1-15 minute conversation to get this number. Then they ask well how much time is that? I then answer "We have three months of velocity data, x points per developer per week accepted into production over the last ten weeks so those five new points for that feature will take one developer 4.1 days to complete with a variance of plus or minus 1.8 days. If you need better precision, we can take a day or two to really break down the work and get the uncertainty to at best a ten percent variance.