3 ms·

How about doing it the other way around? How much value do you think a certain feature is worth? How much time should you spend producing that feature, as rel

How about doing it the other way around? How much value do you think a certain feature is worth? How much time should you spend producing that feature, as relative to its value? Then, figure out a way to ship a viable implementation in that amount of time. There are many techniques for estimating how long software development tasks will take primarily because they all suck. Estimating takes time, and is almost always wrong. Some people even advocate figuring out how off your estimates are, to improve your future estimates, so you can be a better estimator. What? I think it's best to stop estimating and start shipping.

RiderOfGiraffes 16y ago
You're clearly in a different business to mine. Someone comes and asks me how much a feature will cost I'd damn well better be a good estimator, because it's usually a fixed price contract for someone with flow-down penalty clauses. In short, sometimes estimation matters. Knowing when it does and doesn't matter is a different question and a different skill. Perhaps for you it never matters, but before you diss someone as heavily as you just did, I suggest you consider that some people have different circumstances than yours.
- briandoll 16y ago
  There is just so much lost in that phone-tag of a conversation between the actual customer and the actual developer in the scenario I think you're describing. Agile estimating techniques seem to provide a reasonable level of expectation, while placing more importance on collaboration between the product owner and the developers. Once you add development managers, project managers (who are often re-estimating for you, adding or reducing a number to align with some other expectation) and a product owner who's only hearing numbers rather than the details, it's a very lossy conversation. How many estimates have you given where you wish you could have said "but if we just do it like this, it'll only take x% of the time", and how well was that communicated to your client? I just think software estimating as a way of holding a conversation about a product under development is unproductive at best, and often leads to an inferior product .
  - RiderOfGiraffes 16y ago
    I'm sorry, but that meant absolutely nothing to me. Your final line was: > I think it's best to stop estimating and start shipping. My point is that when I need a broad plan of what to implement, how much scope to include, when something will be ready by, and how many people will be required, I need to estimate. Sometimes I need to do that before I get down to the nitty-gritty of the real design, real implementation and real details, so I need some rule of thumb to let me give broad ROM estimates. One of our major customers recently asked for a feature and my sales colleague asked how long it would take. We didn't really know what the customer thought they wanted, so I went into a huddle with my lead programmer and together we sketched a reasonable feature that seemed to match the requirement, and estimated about 4 days of actual coding. I went back and replied that it would be 5 weeks of work on this feature (4 x 6 days) and that, given other commitments, that would be about 3 months elapsed time (one programmer working 1/2 time). So that's 5 weeks NRE on this feature, 3 months to delivery. The feature was priced accordingly, and when the customer upped the priority we put a programmer on it full time. It was delivered to site and signed off 6 weeeks later. Sometimes you need to estimate. So, what was your point? ADDED IN EDIT: I am, by the way, quite serious about that question. For me, in my circumstances, I really, really need to estimate in broad outline and get it roughly right. I'd like to see a clear exposition of why you think what I do is wrong. Could you perhaps write a more considered piece on your blog and link to it?
    - briandoll 16y ago
      I agree that this is a very good topic and I'll flesh out some thoughts and post them soon. I'll email you when it's up. Would love to continue the dialog!

RiderOfGiraffes 16y ago

You're clearly in a different business to mine. Someone comes and asks me how much a feature will cost I'd damn well better be a good estimator, because it's usually a fixed price contract for someone with flow-down penalty clauses. In short, sometimes estimation matters. Knowing when it does and doesn't matter is a different question and a different skill. Perhaps for you it never matters, but before you diss someone as heavily as you just did, I suggest you consider that some people have different circumstances than yours.

briandoll 16y ago
There is just so much lost in that phone-tag of a conversation between the actual customer and the actual developer in the scenario I think you're describing. Agile estimating techniques seem to provide a reasonable level of expectation, while placing more importance on collaboration between the product owner and the developers. Once you add development managers, project managers (who are often re-estimating for you, adding or reducing a number to align with some other expectation) and a product owner who's only hearing numbers rather than the details, it's a very lossy conversation. How many estimates have you given where you wish you could have said "but if we just do it like this, it'll only take x% of the time", and how well was that communicated to your client? I just think software estimating as a way of holding a conversation about a product under development is unproductive at best, and often leads to an inferior product .
- RiderOfGiraffes 16y ago
  I'm sorry, but that meant absolutely nothing to me. Your final line was: > I think it's best to stop estimating and start shipping. My point is that when I need a broad plan of what to implement, how much scope to include, when something will be ready by, and how many people will be required, I need to estimate. Sometimes I need to do that before I get down to the nitty-gritty of the real design, real implementation and real details, so I need some rule of thumb to let me give broad ROM estimates. One of our major customers recently asked for a feature and my sales colleague asked how long it would take. We didn't really know what the customer thought they wanted, so I went into a huddle with my lead programmer and together we sketched a reasonable feature that seemed to match the requirement, and estimated about 4 days of actual coding. I went back and replied that it would be 5 weeks of work on this feature (4 x 6 days) and that, given other commitments, that would be about 3 months elapsed time (one programmer working 1/2 time). So that's 5 weeks NRE on this feature, 3 months to delivery. The feature was priced accordingly, and when the customer upped the priority we put a programmer on it full time. It was delivered to site and signed off 6 weeeks later. Sometimes you need to estimate. So, what was your point? ADDED IN EDIT: I am, by the way, quite serious about that question. For me, in my circumstances, I really, really need to estimate in broad outline and get it roughly right. I'd like to see a clear exposition of why you think what I do is wrong. Could you perhaps write a more considered piece on your blog and link to it?
  - briandoll 16y ago
    I agree that this is a very good topic and I'll flesh out some thoughts and post them soon. I'll email you when it's up. Would love to continue the dialog!