4 ms·

Yes, I understand that. What I mean is, how does it address the problems highlighted in the article? It seems to me there's no fundamental difference for the c

by the_af 3y ago

Yes, I understand that. What I mean is, how does it address the problems highlighted in the article? 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?

tptacek 3y ago
The longer the unit of time, the less pressure there is for either side to micromanage the work, or to avoid time-saving optimizations, or to invoice random conversations that could lead to new business, or to cram multiple clients into a single day when that's not what you want to be doing. 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 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 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.)
- swader999 3y ago
  This makes sense but I've never been taken to task for hours and many of my clients charge me out to their end clients for hours I submit. 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.
  - tptacek 3y ago
    You're free to do your own internal projections about the number of hours your features will take. Simply round them up to the nearest whole number of days, and present that to your customer.
    - swader999 3y ago
      Hourly estimating takes too much time and it never gives useful numbers even with various padding schemes when estimating innovative sw development. Cookie cutter web sites or repetitive work that you've done for multiple clients is easy to fix bid but I don't do that sort of work. 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.
      - tptacek 3y ago
        I don't know what we're arguing about. I don't like hourly estimating either, I'm just saying daily billing doesn't keep you from doing it.
        swader999 3y ago
        Didn't feel like a debate, just trying to increase understanding on both sides. If you follow what I'm saying, I don't ever try to estimate hours anymore, I just use past data on complexity and then translate that to hours if ever required. There's very little time and stress, and effort for estimating. It's incredibly accurate over several features too and it is easy for stakeholders to decide cost vs value of each feature.

by the_af 3y ago

tptacek 3y ago

The longer the unit of time, the less pressure there is for either side to micromanage the work, or to avoid time-saving optimizations, or to invoice random conversations that could lead to new business, or to cram multiple clients into a single day when that's not what you want to be doing. 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 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 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.)

swader999 3y ago
This makes sense but I've never been taken to task for hours and many of my clients charge me out to their end clients for hours I submit. 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.
- tptacek 3y ago
  You're free to do your own internal projections about the number of hours your features will take. Simply round them up to the nearest whole number of days, and present that to your customer.
  - swader999 3y ago
    Hourly estimating takes too much time and it never gives useful numbers even with various padding schemes when estimating innovative sw development. Cookie cutter web sites or repetitive work that you've done for multiple clients is easy to fix bid but I don't do that sort of work. 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.
    - tptacek 3y ago
      I don't know what we're arguing about. I don't like hourly estimating either, I'm just saying daily billing doesn't keep you from doing it.
      - swader999 3y ago
        Didn't feel like a debate, just trying to increase understanding on both sides. If you follow what I'm saying, I don't ever try to estimate hours anymore, I just use past data on complexity and then translate that to hours if ever required. There's very little time and stress, and effort for estimating. It's incredibly accurate over several features too and it is easy for stakeholders to decide cost vs value of each feature.