3 ms·

> 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

> 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

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.