4 ms·

I just don’t accept that accurate estimates are actually possible unless: - the requirements are well written and complete - they never change - the duration

I just don’t accept that accurate estimates are actually possible unless: - the requirements are well written and complete - they never change - the duration of the project is very short - the number of interruptions is minimal - there are no other priorities - it’s a simple change to an existing, well defined system If all of the above is true then sure, it’s possible to come up with accurate estimates. But most of the time accuracy problems are not (only) due to the inability of the engineer to estimate, but also the overall uncertainty of the requirements and productive time available. The narrative around estimates is that the engineer is responsible for things being late, but in several places I’ve worked, it’s largely the externalities that cause estimates to be wrong. When I was able to control these factors, my team and I were able to make good estimates most of the time. But it’s really rare to be able to control them.

pizlonator 4y ago
There is no narrative around estimates that engineers are responsible for things being late. Strictly speaking I don’t think any of your conditions have to be true for estimates to be accurate, though obviously all of those things help. I’m reporting empirical results here based on my experience. Your theory doesn’t change the facts of my experience.
- doctor_eval 4y ago
  > There is no narrative around estimates that engineers are responsible for things being late. This is a strange thing to say since I read the article as being exactly about how the engineer becomes responsible for things being late. Otherwise why is the engineer "pressured to work unpaid overtime to meet that estimate" > I’m reporting empirical results here based on my experience. Your theory doesn’t change the facts of my experience. Well, your experience is totally different from mine. I've certainly had my feet held to the fire when a project has been delivered late due to changing management requirements and inappropriate prioritisation of management meetings over deliverables. I've seen others do it, and maybe I've even been guilty of doing it myself. But we all have different experiences. I was just sharing mine. > I don’t think any of your conditions have to be true for estimates to be accurate What would be most interesting to me would be your view on how estimates can remain accurate when requirements change. How can that even happen?
  - pizlonator 4y ago
    Of course estimates shouldn’t remain the same when requirements change. If you told me the same estimate after I changed requirements on you then this would tell me that I should probably ascribe a high error bar to any estimate you make.
    - doctor_eval 4y ago
      But you said that "I don’t think any of your conditions have to be true for estimates to be accurate" and one of my conditions was that the requirements should be correct and shouldn't change. And the point I was trying to make was that - in my experience - is that often requirements changes that are a huge driver for estimates going wrong. If you're lucky, you work in an environment where a changed requirement automatically results in re-estimation at the customer's cost. But in the places I work, the requirements are often not well stated in the first place, so they are subject to interpretation, and it is very difficult to estimate reliably in such an environment. And for whatever it's worth, that's been my experience for the whole of my long career. As engineers we're forced to quote against crappy requirements, and as management we're forced to accept crappy requirements in order to win the gig. But all too often engineering is blamed for late delivery of something that sales shouldn't have sold in the first place.

pizlonator 4y ago

There is no narrative around estimates that engineers are responsible for things being late. Strictly speaking I don’t think any of your conditions have to be true for estimates to be accurate, though obviously all of those things help. I’m reporting empirical results here based on my experience. Your theory doesn’t change the facts of my experience.

doctor_eval 4y ago
> There is no narrative around estimates that engineers are responsible for things being late. This is a strange thing to say since I read the article as being exactly about how the engineer becomes responsible for things being late. Otherwise why is the engineer "pressured to work unpaid overtime to meet that estimate" > I’m reporting empirical results here based on my experience. Your theory doesn’t change the facts of my experience. Well, your experience is totally different from mine. I've certainly had my feet held to the fire when a project has been delivered late due to changing management requirements and inappropriate prioritisation of management meetings over deliverables. I've seen others do it, and maybe I've even been guilty of doing it myself. But we all have different experiences. I was just sharing mine. > I don’t think any of your conditions have to be true for estimates to be accurate What would be most interesting to me would be your view on how estimates can remain accurate when requirements change. How can that even happen?
- pizlonator 4y ago
  Of course estimates shouldn’t remain the same when requirements change. If you told me the same estimate after I changed requirements on you then this would tell me that I should probably ascribe a high error bar to any estimate you make.
  - doctor_eval 4y ago
    But you said that "I don’t think any of your conditions have to be true for estimates to be accurate" and one of my conditions was that the requirements should be correct and shouldn't change. And the point I was trying to make was that - in my experience - is that often requirements changes that are a huge driver for estimates going wrong. If you're lucky, you work in an environment where a changed requirement automatically results in re-estimation at the customer's cost. But in the places I work, the requirements are often not well stated in the first place, so they are subject to interpretation, and it is very difficult to estimate reliably in such an environment. And for whatever it's worth, that's been my experience for the whole of my long career. As engineers we're forced to quote against crappy requirements, and as management we're forced to accept crappy requirements in order to win the gig. But all too often engineering is blamed for late delivery of something that sales shouldn't have sold in the first place.