5 ms·

Manager here. I ask everyone for estimates. Then I track how long shit actually takes. I find that: - Some folks are scary precise in their estimates. I’d say

Manager here. I ask everyone for estimates. Then I track how long shit actually takes. I find that: - Some folks are scary precise in their estimates. I’d say this is like 10% of engineers. You ask them for an estimate, they tell you, and then it takes exactly that long every single time. In other words, I have confidence that if I ask one of those folks for an estimate, I can take that shit to the bank. - Some folks always overestimate. This is rare. Maybe less than 10% of folks. When I find that someone overestimates, I know that I can take that shit to the bank as an upper bound, which is still useful. - Some folks say they don’t know. That’s fine. Those folks are even rarer, so I don’t have to do anything smart for them. - Most folks underestimate, sometimes hilariously so - they are always one day, or one week, or some other too-short amount of time, away from finishing their multi month effort. That’s fine. Once I know you underestimate, I know that I can take your estimates to the bank as a lower bound. For more than half of the underestimaters, I find that there’s some formula that works: like if Steve says he needs just one more day, he always means he needs five more days. So if suddenly Steve says he needs another week, then I know he probably needs over a month. That’s still useful to me and I’m totally fine if Steve then tells his friends (or HN) how dumb it is that I ask him for estimates. They may be dumb to him but I’ve got my napkin math that turns his BS estimate into something that I can take to the bank. (I don’t actually manage anyone named Steve but I was a Steve as an IC.) So yeah. When I ask you for an estimate, I expect it to be wrong and then I look for patterns in your wrongness. For most people, there’s a pattern that allows me to turn something that looks like a nonsense estimate at first into something I can then plan around. That’s why developers I work with are “expected” to estimate.

vsareto 4y ago
>Some folks are scary precise in their estimates. I’d say this is like 10% of engineers. You ask them for an estimate, they tell you, and then it takes exactly that long every single time. It's possible they are hiding their true skill and sitting inside their comfort zone, so they are really over-estimating based on what they can actually do, but are keeping that truth to themselves. A good reason to do this is to avoid being assigned more work for no real gain and pushing the work-life balance more towards life. This situation annoys some managers when they find out they weren't getting the maximum effort possible from someone for their compensation.
- pstorm 4y ago
  I came here to say the same thing. It's either that or Parkinson's Law [0], usually expressed as: work expands so as to fill the time available for its completion. I find that for myself it is true, when I have more time, I take my foot off the pedal. When I am running late, I work harder to meet the deadline. [0] https://en.wikipedia.org/wiki/Parkinson%27s_law https://en.wikipedia.org/wiki/Parkinson%27s_law
- mumblemumble 4y ago
  This was roughly my first thought, too. It may not be nefarious, though. In many software projects, if you know what you're doing, there's a lot of work that's useful-but-optional that can be delayed to the end stages of the project. So then you front-load all your hard requirements so that you can minimize the risk that you'll miss any of them. Once that's sorted, you can just knock your way down the rest of the to-do list until you run out of time. This is actually how Scrum is supposed to work, and most the Scrum rituals are just a formalized process for doing that in a collective ownership setting. But at some point we forgot that and started confusing the means for the ends, and it all kind of fell apart.
- pizlonator 4y ago
  Nah. The people I’m thinking of are fucking magicians. If they are hiding their true skill then OMFG.
  - engineeringwoke 4y ago
    I am 100% one of these people. Unless something really unexpected comes up, then I choose whether I'm working that morning (which is less than 50%) and will usually finish the work after a few hours, then commit it either at EOD or next morning. I am still considered an over-achiever by a vast margin.
    - pizlonator 4y ago
      Good for you. I don’t mind working with such people. I have zero interest in knowing how much of your 40 hours you actually spent working, only whether you did the thing you said you were going to do. An engineer that is more productive than everyone else but only works 5 hours a week still deserves to be rewarded the same way as an engineer who worked 40 hours but achieved the same result in the same calendar duration. If you really can overachieve while working very little then all it means is that you could have achieved more in your life if you spent more time working. And that’s none of my business.
VFIT7CTO77TOC 4y ago
If your mechanic gave you a 1 month estimate to fix your flat tire, they'd deliver on time every time
- pizlonator 4y ago
  The precise estimaters are doing more than fixing a tire and they are doing it in less than a month. Empirically, these people are often more than average productive. It helps that I also know how to program. So I know that the task in question is hard and I know that the patch they submitted is the real deal.
okdood64 4y ago
> like if Steve says he needs just one more day, he always means he needs five more days. So if suddenly Steve says he needs another week, then I know he probably needs over a month. That is a beyond frustrating even if you have gotten used to adjusting the time in your head. It also probably means it affects other work that Steve is doing and his sanity. (Steve thinks he'll finish Task A in a week, and has already allocated time for Task B in a week's time, but he's not even close to finishing Task A a week later, and now he has to work on both at the same time. Which is fine, we're all expected to multi-task, but if he constantly isn't prepared for this then it's not sustainable.) In these scenarios do you talk to Steve about what is up with his estimation skills and time management?
- pizlonator 4y ago
  It’s usually not person-specific but domain-specific. Like, I’m really good at memory management but whenever I go to write a new malloc or GC I somehow convince myself that I’ll Carmack it in a weekend. And then it takes five months. But if I write a compiler then I’m usually one of those precise estimators. If I tell you a month then it’ll be a month. So, I don’t try to talk to the Steve as if he’s the problem. He’s not the problem. The problem he’s solving is the problem. (Or maybe I just make that excuse for Steve because as I said, I’m a Steve.)
- pizlonator 4y ago
  Right. Requirements staying constant is not a requirement for estimates to be accurate because when requirements change it’s customary to ask for a new estimate.
doctor_eval 4y ago
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?

vsareto 4y ago

>Some folks are scary precise in their estimates. I’d say this is like 10% of engineers. You ask them for an estimate, they tell you, and then it takes exactly that long every single time. It's possible they are hiding their true skill and sitting inside their comfort zone, so they are really over-estimating based on what they can actually do, but are keeping that truth to themselves. A good reason to do this is to avoid being assigned more work for no real gain and pushing the work-life balance more towards life. This situation annoys some managers when they find out they weren't getting the maximum effort possible from someone for their compensation.

pstorm 4y ago
I came here to say the same thing. It's either that or Parkinson's Law [0], usually expressed as: work expands so as to fill the time available for its completion. I find that for myself it is true, when I have more time, I take my foot off the pedal. When I am running late, I work harder to meet the deadline. [0] https://en.wikipedia.org/wiki/Parkinson%27s_law https://en.wikipedia.org/wiki/Parkinson%27s_law
mumblemumble 4y ago
This was roughly my first thought, too. It may not be nefarious, though. In many software projects, if you know what you're doing, there's a lot of work that's useful-but-optional that can be delayed to the end stages of the project. So then you front-load all your hard requirements so that you can minimize the risk that you'll miss any of them. Once that's sorted, you can just knock your way down the rest of the to-do list until you run out of time. This is actually how Scrum is supposed to work, and most the Scrum rituals are just a formalized process for doing that in a collective ownership setting. But at some point we forgot that and started confusing the means for the ends, and it all kind of fell apart.
pizlonator 4y ago
Nah. The people I’m thinking of are fucking magicians. If they are hiding their true skill then OMFG.
- engineeringwoke 4y ago
  I am 100% one of these people. Unless something really unexpected comes up, then I choose whether I'm working that morning (which is less than 50%) and will usually finish the work after a few hours, then commit it either at EOD or next morning. I am still considered an over-achiever by a vast margin.
  - pizlonator 4y ago
    Good for you. I don’t mind working with such people. I have zero interest in knowing how much of your 40 hours you actually spent working, only whether you did the thing you said you were going to do. An engineer that is more productive than everyone else but only works 5 hours a week still deserves to be rewarded the same way as an engineer who worked 40 hours but achieved the same result in the same calendar duration. If you really can overachieve while working very little then all it means is that you could have achieved more in your life if you spent more time working. And that’s none of my business.

VFIT7CTO77TOC 4y ago

If your mechanic gave you a 1 month estimate to fix your flat tire, they'd deliver on time every time

pizlonator 4y ago
The precise estimaters are doing more than fixing a tire and they are doing it in less than a month. Empirically, these people are often more than average productive. It helps that I also know how to program. So I know that the task in question is hard and I know that the patch they submitted is the real deal.

okdood64 4y ago

> like if Steve says he needs just one more day, he always means he needs five more days. So if suddenly Steve says he needs another week, then I know he probably needs over a month. That is a beyond frustrating even if you have gotten used to adjusting the time in your head. It also probably means it affects other work that Steve is doing and his sanity. (Steve thinks he'll finish Task A in a week, and has already allocated time for Task B in a week's time, but he's not even close to finishing Task A a week later, and now he has to work on both at the same time. Which is fine, we're all expected to multi-task, but if he constantly isn't prepared for this then it's not sustainable.) In these scenarios do you talk to Steve about what is up with his estimation skills and time management?

pizlonator 4y ago
It’s usually not person-specific but domain-specific. Like, I’m really good at memory management but whenever I go to write a new malloc or GC I somehow convince myself that I’ll Carmack it in a weekend. And then it takes five months. But if I write a compiler then I’m usually one of those precise estimators. If I tell you a month then it’ll be a month. So, I don’t try to talk to the Steve as if he’s the problem. He’s not the problem. The problem he’s solving is the problem. (Or maybe I just make that excuse for Steve because as I said, I’m a Steve.)
pizlonator 4y ago
Right. Requirements staying constant is not a requirement for estimates to be accurate because when requirements change it’s customary to ask for a new estimate.

doctor_eval 4y ago

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?