6 ms·

And they probably got the estimates wrong for those unique projects.

by UK-AL 10y ago

jacques_chester 10y ago
So to revisit an earlier question: do you think they should have not estimated? That all other professions should refuse to render estimates because -- gasp -- they might be wrong?
- UK-AL 10y ago
  I'm not saying you should refuse to estimate, I'm saying giving an accurate estimate is verging on the impossible. You can attempt to do it, but people shouldn't expect it to be accurate. I'm just saying they are probably way out, and probably arn't that useful compared to other methods of building software. A lot businesses people who get this, then ask why bother if they are going to be really inaccurate? Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. Or even better do the implement and feedback cycle continuously. If you are not happy on the progress of a feature, cancel it. Because you doing things in small intervals, and then adjusting. It won't go wildly of the tracks, before realising you have to adjust or cancel it.
  - jacques_chester 10y ago
    > Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. I absolutely agree with you. I think we're closing on the key difference, which is the scope of the estimation. I am accustomed to estimating the smallest self-contained unit of user-facing value. I'm used to doing it weekly. I'm used to being in a room with my fellow engineers to do a simple points-based estimate of complexity, with projected dates derived from the velocity of the past 3 weeks. I am used to PMs who understand that sometimes we hit iceberg stories, but that most of the time, the projections are good into the next few months. What I don't have to do is build a magical estimate of the next three years. If I was asked, I would try to based on historical data and research, but the bands would be extremely wide. Thinking about the analogy that we often make back to construction, the problem is that classical project management is essentially an estimate of an integral. There is a discrete endpoint, and we can estimate (and re-estimate) leading up to that end point. Funds are committed in large chunks and the cheque-signers need high confidence to proceed. But software is never finished, only abandoned. Estimation has to be differential and constantly updated. If the software is developed to be releasable at all times, commitment can be incremental and early abandonment due to negative feedback is advantageous. I'm not saying anything new here. But I understand better where you were coming from.
- wvenable 10y ago
  Other professions base their estimates on the blueprints or the plan. You plan out a bridge and then you base on the estimates on that. Software development is construction of the plan. And all industries also estimate how long planning will take but it's a vastly more significant for software as that's the entire thing.
  - jacques_chester 10y ago
    > And all industries also estimate how long planning will take but it's a vastly more significant for software as that's the entire thing. Which means that we're doing it more often, so we have more data and experience to call on when estimating. And it means it's more important to estimate the design task, since it's vastly more significant.
    - wvenable 10y ago
      My point is that estimating the planning (which for software dev is the software dev) isn't necessarily a solved task in any industry. So making such comparisons is meaningless.
      - jacques_chester 10y ago
        And my point is that there is no such thing as a "solved" task for estimating. They're estimates. They're not called "certains", "definites" or "numerical solutions" because they are none of these things.

And they probably got the estimates wrong for those unique projects.

by UK-AL 10y ago

And they probably got the estimates wrong for those unique projects.

So to revisit an earlier question: do you think they should have not estimated? That all other professions should refuse to render estimates because -- gasp -- they might be wrong?

UK-AL 10y ago
I'm not saying you should refuse to estimate, I'm saying giving an accurate estimate is verging on the impossible. You can attempt to do it, but people shouldn't expect it to be accurate. I'm just saying they are probably way out, and probably arn't that useful compared to other methods of building software. A lot businesses people who get this, then ask why bother if they are going to be really inaccurate? Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. Or even better do the implement and feedback cycle continuously. If you are not happy on the progress of a feature, cancel it. Because you doing things in small intervals, and then adjusting. It won't go wildly of the tracks, before realising you have to adjust or cancel it.
- jacques_chester 10y ago
  > Instead focus on small intervals, work out what you should try to build in those intervals. Implement. Gather feedback. Repeat. I absolutely agree with you. I think we're closing on the key difference, which is the scope of the estimation. I am accustomed to estimating the smallest self-contained unit of user-facing value. I'm used to doing it weekly. I'm used to being in a room with my fellow engineers to do a simple points-based estimate of complexity, with projected dates derived from the velocity of the past 3 weeks. I am used to PMs who understand that sometimes we hit iceberg stories, but that most of the time, the projections are good into the next few months. What I don't have to do is build a magical estimate of the next three years. If I was asked, I would try to based on historical data and research, but the bands would be extremely wide. Thinking about the analogy that we often make back to construction, the problem is that classical project management is essentially an estimate of an integral. There is a discrete endpoint, and we can estimate (and re-estimate) leading up to that end point. Funds are committed in large chunks and the cheque-signers need high confidence to proceed. But software is never finished, only abandoned. Estimation has to be differential and constantly updated. If the software is developed to be releasable at all times, commitment can be incremental and early abandonment due to negative feedback is advantageous. I'm not saying anything new here. But I understand better where you were coming from.
wvenable 10y ago
Other professions base their estimates on the blueprints or the plan. You plan out a bridge and then you base on the estimates on that. Software development is construction of the plan. And all industries also estimate how long planning will take but it's a vastly more significant for software as that's the entire thing.
- jacques_chester 10y ago
  > And all industries also estimate how long planning will take but it's a vastly more significant for software as that's the entire thing. Which means that we're doing it more often, so we have more data and experience to call on when estimating. And it means it's more important to estimate the design task, since it's vastly more significant.
  - wvenable 10y ago
    My point is that estimating the planning (which for software dev is the software dev) isn't necessarily a solved task in any industry. So making such comparisons is meaningless.
    - jacques_chester 10y ago
      And my point is that there is no such thing as a "solved" task for estimating. They're estimates. They're not called "certains", "definites" or "numerical solutions" because they are none of these things.