6 ms·

In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The engineers who are most likely to be under-

In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks. Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who do, they will see right through this.

Moru 2y ago
It is however a logical follow up of the managers behaviour. If they try to hold the estimate as deadline, the estimate will be larger next time. If manager doesn't see this coming, the manager needs to work on some people skills.
eminent101 2y ago
So many bold claims in this comment and little to no justification. For what it's worth I've seen pretty much the opposite. I don't know about competent vs. incompetent engineers. But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates.
- gjvc 2y ago
  But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates is the essence of this thread
- taurath 2y ago
  A big problem when you're a more experienced engineer is when you have your hands in a lot of things and know the relative priority of stuff and how likely it is that something else of importance will pop up. So you anticipate things getting sidetracked over time, and try to make a bit of a longer estimate, usually to give yourself the slack to do other important things without looking like you're falling behind in JIRA. Giving an "if I had nothing else going on" estimate can be a big trap to fall into - they will only see the number and judge your performance based on that. This dovetails into the problem that untracked but still important work being thankless in low trust environments - not all work can ever be tracked, or else the time to track that work would take as long as doing the work. Examples: literally any emotional labor, time to monitor, time to train, time to document when its not explicitly required, time to solve little problems. In the environment where none of this counts because its not quantifiable, everyone with knowledge makes themselves into a silo in order to protect perceptions of their performance, and everyone else suffers. I'll go even a little further to say that companies that attempt to have no untracked work are by nature far more sociopathic - thus far there's basically no consequences for sociopathic organizations but I hope one day there will be.
- c0balt 2y ago
  Ime, as a junior dev/ops person, there is almost always scope creep and adding padding grants you room to account for the new idea your supervisor/ user thought of when being midway into development. As far as I can tell, my supervisor also assumes my estimates should be padded more because sometimes you might need wait on human i/o for longer than planned (holidays/ sick leave/...).
  - skeeter2020 2y ago
    one thing that I like, that can help, is to add explicit things in the spec that it will NOT do. If you keep this "types" of functionality you can shut down a lot of scope creep: "we need to send an email alert after the job is done." gets answered "we can do that in a future iteration because this says the feature will not include any alerting or notifications, just log to a file and finish".
- bdangubic 2y ago
  I think general problem on HN is that you can't say something "bold" without people going "nuts" - especially when it comes to estimating work. In my experience (been hacking since the '90's before it was cool) great developers are great at estimating things. And these are not outliers, all except 1 great developer I've had pleasure of working with over these years has never been "off" on estimates by any statistically significant margin. but you say anything like that here on HN and it is heresy. My general opinion is that developers LOVE making everyone believe that software development is somehow "special" from many other "industries" for the lack of a better word and that we simply cannot give you accurate estimates that you can use to make "deadlines" (or better said project plans). and yet most developers (including ones raising hell here and downvoting any comment contrary to "popular belief") are basically doing sht that's been done million times before, CRUD here, form there, notification there, event there etc... It is not like we are all going "oh sht, I wonder how long it'll take to create a sign-up form." I think we have (so far) been successful at running this "scam" whereby "we just can't accurately estimate it" because of course it is super advantageous to us. and WFH has made this even worse in my opinion - given that we can't provide "accurate estimates" now we can simply pad them (who dare to question this, it is just an estimate, right? can't hold me to the estimate...) and then chill with our wifes and dogs when sh*t is done 6 weeks earlier :)
  - mewpmewp2 2y ago
    It really depends on what you are working on. When I did agency type of work, building things you have built before, from scratch, it's easy to estimate. E.g. some sort of e-commerce website from scratch. On the other hand, working in a large corp, with massive legacy systems, unknown domain knowledge and dependency on other teams, it becomes near impossible. What might have been a 2 hour task in agency, might either be completely impossible during our lifetime unless the whole company was built from scratch or take 2 years. You might need 6 other teams to agree to make some sort of change, and you first might have to convince those teams, and then 2 teams will initially agree to it, then pull out in the last moment, or realize they can't do it.
    - bdangubic 2y ago
- koyote 2y ago
  > I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates I have the same anecdotal experience with a possible explanation: Inexperienced engineers often don't see the greater picture or the kind of edge cases that will probably need to be handled ahead of time. I've often had the following type of conversation: Engineer: "I think that would be a day's work" Me: "This will need to interact with team X's package. Have you accounted for time spent interacting with them?" Engineer: "Oh no, I guess two days then" Me: "Will this account for edge case 1 and 2?" Engineer: "Ah yes, I guess it would be three days then" Me: "Testing?" Engineer: "Maybe let's say a week?" On the other hand experienced devs might have their judgement clouded by past events: "Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue
  - roenxi 2y ago
    > "Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue This is software though, if X has actually been done before then it doesn't need to be done again. It is already done. Task X clearly had the potential to blow out by 3 months, and they are now working on task Y that is similar to X. It is a reasonable position to assume that there are other as-yet-unknown issues that might cause it to blow out by 3 months until someone has demonstrated that all the unknown unknowns are also resolved by doing it quickly. That is just basic evidence based planning.
    - lesuorac 2y ago
      I've always found that finding a similar scope problem and how long it took is the best predictor of how long the new problem is going to take.
ebiester 2y ago
The managers are often just as trained in this by the organization. If I'm in a "commitment" organization, I'm sure as hell telling them all to pad their estimates. The punishment for a commitment culture is inflated estimates.
tivert 2y ago
> Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who do, they will see right through this. I think a manager who doesn't know the difference between and estimate and a deadline is one who "[doesn't] know what the fuck is going on," and that's the kind of manager the GP uses this strategy with.
- tonyedgecombe 2y ago
  I think a lot of them know the difference, they just don't care. The estimate is a tool to beat you with.
- jjk166 2y ago
  The big issue is when a manager knows the difficulty of the task but not the context it's being done in. A project may be perfectly reasonable to complete in 4 weeks if it's given the priority it deserves, but I know that I'm almost certainly going to get pulled off to do something else so it's going to wind up taking 12 weeks, and then with a very moderate 33% padding giving an overall length of time of 16 weeks, the manager (who has no visibility to the thing which will pull me away) thinks I'm adding 300% padding. Then they say "surely you can do it in less time if we just don't let you get pulled away" and of course you say "well I've been pulled away from all of the past 27 projects over the last 5 years" and they say "don't worry I'll make sure this time is different." It's not a lack of technical competence, it's a lack of introspection and managerial soft skills.
Aeolun 2y ago
> In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The manager need to know how to make the estimate to know is bullshit. If the manager knows how to make the estimate and what it represents, there is no need to inflate it for them.
switchbak 2y ago
It's exactly this kind of prideful ego centric attitude that these managers rely on to get folks to commit to unrealistic estimates, then work nights and weekends (and cut corners) to fulfil.
mewpmewp2 2y ago
I've been considered high performer everywhere I went, only when I was beginning I usually gave very low and naive estimates, experience has taught me otherwise. Of course it will also depend on who and why I'm giving those estimations to. Usually there are just too many unknowns that higher estimate is justified to avoid having to explain why you didn't make it by certain deadline. The estimates I give are not median or average that I expected the task to complete, they are so that I can be 95% sure it's possible to do it and then some.
- rightbyte 2y ago
  Ye and this is the problem with management using estimates as deadline. When I was naive and believed that Agile was not a sinister micromanagement toolkit to mess with programmers, I tried to explain to people that about half of our estimates should overshoot and half undershoot or they are biased and that there should be more overshoots since there is no upper bound on how much time a task can take if the estimate is wrong. Ye. No. The burndown chart shouls be as straight as possible.
  - mewpmewp2 2y ago
    Yeah, and even if it is not being done as of moment, there is always a possibility of someone clueless from leadership deciding it is a good idea to check how many story points you have completed by some rough statistical analysis, in which case people who put higher estimates and completed those tickets will look better.
    - rightbyte 2y ago
      Ye. The manager need to be a programmer and involved in the project to be able to evaluate the participants. I guess 'estimation poker' is a way to counteract the obvious strategy to coast and look competent. In poker you can also look good by underbidding your peers and then snatch the easy ones to look good while the scapegoats look bad. The strategy need some social status or incubent code knowledge relative to the team though, to get the good tasks.
qaq 2y ago
This can only hold water in reasonably small orgs. In large orgs you often have to coordinate with large number of teams to get something delivered. Those teams have changing priorities that can impact when they complete their tasks. Your teams priorities can be shifted too to fight some fire. So this small estimate has no value because it has 0 correlation to the overall delivery date higher ups can commit to for the overall project.
disambiguation 2y ago
Yeah but missing estimates makes you look super duper incompetent by comparison.
watwut 2y ago
> The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks. Definitely did not seen this. Under performers are underestimating or just do wild random guesses. Under performance is most likely to be in the form of "making small estimate, try to make it technically, but then it has about millions of problems". Big estimates require courage and confidence - under performers usually do not have either. They are too scared to estimate high.
DennisP 2y ago
I wouldn't advocate "super-inflated" estimates but within reason, there are long-term benefits if you go about it right. Where I mostly worked, managers cared about deadlines they could tell to external clients, which they really hated to miss. Early on, I didn't realize that, and gave my best guess. If I guessed the correct median, I was missing it 50% of the time, and managers kept getting mad at me. So I switched to estimates I could meet 90% of the time, and on the slow 10% I worked extra hours to meet my estimate anyway. Managers were happy. If I told them it would be done by Tuesday, it would be done by Tuesday. But it had enormous benefits beyond that. In almost 90% of cases, I had free time. Sometimes I'd admit to finishing early, but I also used that time to clean up technical debt, automate the tedious parts of my job, or advance my skills. After a while, I could give estimates as short as my old 50% estimates, and still beat them 90% of the time because I'd made my tasks so much easier. Less technical debt also meant the resulting code was less likely to have bugs. After a while, it seemed to me that all the other devs were overworked and I had it easy. But management gave me raises, and when they got in a jam, I was the guy they called on to bail them out.
- interactivecode 2y ago
  Being reliable is very valuable for the company. Better for you, better for the company. Unrealistic deadlines is bad for everyone involved. Especially for day to day work
Lanolderen 2y ago
I'm a junior and practically refuse to give estimates currently because the projects I currently get have no real requirements. "We'd like to replace an excel table for some calculations with a dialog. Here's the template, how long do you need?" which sounds simple enough turns into: 1- Decypher what the example excel template developed by someone over 10 years even does. 2- Oh, there are actually 10 templates and manual actions that give the end result. 2.5- Oh, btw, we asked an external company about doing this for us a while back and they wanted 1kk euros, crazy right? 3- Oh, we also need to generate, send and track offers via the app with the ability to add comments and upload files related to the offer. We also want the user to be queried about what data he has on hand so that calculations he cannot complete are not offered/he's notified as to what else he needs to proceed. 4- Oh, we also need change tracking/audit logs for everything. 5- Oh, we also need to get data from this place, find a free API and also a way to get data out of this software here. In comparison to that at my previous job the tasks were way smaller and clearer so I'd essentially give myself deadlines when talking to my manager by saying X and Y should be done by Z, A by B. The only thing I can think of in this situation is to essentially make internal pseudo contracts regarding requirements but then I'm making a pseudo contract with someone 3 levels in the hierarchy above me who's also the person who can terminate me. It's not like that pseudo contract will be read by anyone besides us so it seems better to display lots of uncertainty. At least if you're senior you have more authority in discussion and don't really have to give a fuck since everyone's looking to hire senior devs + your downgrade is a normal dev position. From junior the downgrade seems to be testing or McDonalds and you get to redo junior.

Moru 2y ago

It is however a logical follow up of the managers behaviour. If they try to hold the estimate as deadline, the estimate will be larger next time. If manager doesn't see this coming, the manager needs to work on some people skills.

eminent101 2y ago

So many bold claims in this comment and little to no justification. For what it's worth I've seen pretty much the opposite. I don't know about competent vs. incompetent engineers. But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates.

gjvc 2y ago
But when it comes to experience, I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates is the essence of this thread
taurath 2y ago
A big problem when you're a more experienced engineer is when you have your hands in a lot of things and know the relative priority of stuff and how likely it is that something else of importance will pop up. So you anticipate things getting sidetracked over time, and try to make a bit of a longer estimate, usually to give yourself the slack to do other important things without looking like you're falling behind in JIRA. Giving an "if I had nothing else going on" estimate can be a big trap to fall into - they will only see the number and judge your performance based on that. This dovetails into the problem that untracked but still important work being thankless in low trust environments - not all work can ever be tracked, or else the time to track that work would take as long as doing the work. Examples: literally any emotional labor, time to monitor, time to train, time to document when its not explicitly required, time to solve little problems. In the environment where none of this counts because its not quantifiable, everyone with knowledge makes themselves into a silo in order to protect perceptions of their performance, and everyone else suffers. I'll go even a little further to say that companies that attempt to have no untracked work are by nature far more sociopathic - thus far there's basically no consequences for sociopathic organizations but I hope one day there will be.
c0balt 2y ago
Ime, as a junior dev/ops person, there is almost always scope creep and adding padding grants you room to account for the new idea your supervisor/ user thought of when being midway into development. As far as I can tell, my supervisor also assumes my estimates should be padded more because sometimes you might need wait on human i/o for longer than planned (holidays/ sick leave/...).
- skeeter2020 2y ago
  one thing that I like, that can help, is to add explicit things in the spec that it will NOT do. If you keep this "types" of functionality you can shut down a lot of scope creep: "we need to send an email alert after the job is done." gets answered "we can do that in a future iteration because this says the feature will not include any alerting or notifications, just log to a file and finish".
bdangubic 2y ago
I think general problem on HN is that you can't say something "bold" without people going "nuts" - especially when it comes to estimating work. In my experience (been hacking since the '90's before it was cool) great developers are great at estimating things. And these are not outliers, all except 1 great developer I've had pleasure of working with over these years has never been "off" on estimates by any statistically significant margin. but you say anything like that here on HN and it is heresy. My general opinion is that developers LOVE making everyone believe that software development is somehow "special" from many other "industries" for the lack of a better word and that we simply cannot give you accurate estimates that you can use to make "deadlines" (or better said project plans). and yet most developers (including ones raising hell here and downvoting any comment contrary to "popular belief") are basically doing sht that's been done million times before, CRUD here, form there, notification there, event there etc... It is not like we are all going "oh sht, I wonder how long it'll take to create a sign-up form." I think we have (so far) been successful at running this "scam" whereby "we just can't accurately estimate it" because of course it is super advantageous to us. and WFH has made this even worse in my opinion - given that we can't provide "accurate estimates" now we can simply pad them (who dare to question this, it is just an estimate, right? can't hold me to the estimate...) and then chill with our wifes and dogs when sh*t is done 6 weeks earlier :)
- mewpmewp2 2y ago
  It really depends on what you are working on. When I did agency type of work, building things you have built before, from scratch, it's easy to estimate. E.g. some sort of e-commerce website from scratch. On the other hand, working in a large corp, with massive legacy systems, unknown domain knowledge and dependency on other teams, it becomes near impossible. What might have been a 2 hour task in agency, might either be completely impossible during our lifetime unless the whole company was built from scratch or take 2 years. You might need 6 other teams to agree to make some sort of change, and you first might have to convince those teams, and then 2 teams will initially agree to it, then pull out in the last moment, or realize they can't do it.
  - bdangubic 2y ago
koyote 2y ago
> I've seen the inexperienced ones giving super low estimates and the experienced people giving larger estimates I have the same anecdotal experience with a possible explanation: Inexperienced engineers often don't see the greater picture or the kind of edge cases that will probably need to be handled ahead of time. I've often had the following type of conversation: Engineer: "I think that would be a day's work" Me: "This will need to interact with team X's package. Have you accounted for time spent interacting with them?" Engineer: "Oh no, I guess two days then" Me: "Will this account for edge case 1 and 2?" Engineer: "Ah yes, I guess it would be three days then" Me: "Testing?" Engineer: "Maybe let's say a week?" On the other hand experienced devs might have their judgement clouded by past events: "Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue
- roenxi 2y ago
  > "Last time we did something with X it blew out by 3 months" - Ignoring the fact that X is now a solved issue This is software though, if X has actually been done before then it doesn't need to be done again. It is already done. Task X clearly had the potential to blow out by 3 months, and they are now working on task Y that is similar to X. It is a reasonable position to assume that there are other as-yet-unknown issues that might cause it to blow out by 3 months until someone has demonstrated that all the unknown unknowns are also resolved by doing it quickly. That is just basic evidence based planning.
  - lesuorac 2y ago
    I've always found that finding a similar scope problem and how long it took is the best predictor of how long the new problem is going to take.

ebiester 2y ago

The managers are often just as trained in this by the organization. If I'm in a "commitment" organization, I'm sure as hell telling them all to pad their estimates. The punishment for a commitment culture is inflated estimates.

tivert 2y ago

> Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who do, they will see right through this. I think a manager who doesn't know the difference between and estimate and a deadline is one who "[doesn't] know what the fuck is going on," and that's the kind of manager the GP uses this strategy with.

tonyedgecombe 2y ago
I think a lot of them know the difference, they just don't care. The estimate is a tool to beat you with.
jjk166 2y ago
The big issue is when a manager knows the difficulty of the task but not the context it's being done in. A project may be perfectly reasonable to complete in 4 weeks if it's given the priority it deserves, but I know that I'm almost certainly going to get pulled off to do something else so it's going to wind up taking 12 weeks, and then with a very moderate 33% padding giving an overall length of time of 16 weeks, the manager (who has no visibility to the thing which will pull me away) thinks I'm adding 300% padding. Then they say "surely you can do it in less time if we just don't let you get pulled away" and of course you say "well I've been pulled away from all of the past 27 projects over the last 5 years" and they say "don't worry I'll make sure this time is different." It's not a lack of technical competence, it's a lack of introspection and managerial soft skills.

Aeolun 2y ago

> In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The manager need to know how to make the estimate to know is bullshit. If the manager knows how to make the estimate and what it represents, there is no need to inflate it for them.

switchbak 2y ago

It's exactly this kind of prideful ego centric attitude that these managers rely on to get folks to commit to unrealistic estimates, then work nights and weekends (and cut corners) to fulfil.

mewpmewp2 2y ago

I've been considered high performer everywhere I went, only when I was beginning I usually gave very low and naive estimates, experience has taught me otherwise. Of course it will also depend on who and why I'm giving those estimations to. Usually there are just too many unknowns that higher estimate is justified to avoid having to explain why you didn't make it by certain deadline. The estimates I give are not median or average that I expected the task to complete, they are so that I can be 95% sure it's possible to do it and then some.

rightbyte 2y ago
Ye and this is the problem with management using estimates as deadline. When I was naive and believed that Agile was not a sinister micromanagement toolkit to mess with programmers, I tried to explain to people that about half of our estimates should overshoot and half undershoot or they are biased and that there should be more overshoots since there is no upper bound on how much time a task can take if the estimate is wrong. Ye. No. The burndown chart shouls be as straight as possible.
- mewpmewp2 2y ago
  Yeah, and even if it is not being done as of moment, there is always a possibility of someone clueless from leadership deciding it is a good idea to check how many story points you have completed by some rough statistical analysis, in which case people who put higher estimates and completed those tickets will look better.
  - rightbyte 2y ago
    Ye. The manager need to be a programmer and involved in the project to be able to evaluate the participants. I guess 'estimation poker' is a way to counteract the obvious strategy to coast and look competent. In poker you can also look good by underbidding your peers and then snatch the easy ones to look good while the scapegoats look bad. The strategy need some social status or incubent code knowledge relative to the team though, to get the good tasks.

qaq 2y ago

This can only hold water in reasonably small orgs. In large orgs you often have to coordinate with large number of teams to get something delivered. Those teams have changing priorities that can impact when they complete their tasks. Your teams priorities can be shifted too to fight some fire. So this small estimate has no value because it has 0 correlation to the overall delivery date higher ups can commit to for the overall project.

disambiguation 2y ago

Yeah but missing estimates makes you look super duper incompetent by comparison.

watwut 2y ago

> The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks. Definitely did not seen this. Under performers are underestimating or just do wild random guesses. Under performance is most likely to be in the form of "making small estimate, try to make it technically, but then it has about millions of problems". Big estimates require courage and confidence - under performers usually do not have either. They are too scared to estimate high.

DennisP 2y ago

I wouldn't advocate "super-inflated" estimates but within reason, there are long-term benefits if you go about it right. Where I mostly worked, managers cared about deadlines they could tell to external clients, which they really hated to miss. Early on, I didn't realize that, and gave my best guess. If I guessed the correct median, I was missing it 50% of the time, and managers kept getting mad at me. So I switched to estimates I could meet 90% of the time, and on the slow 10% I worked extra hours to meet my estimate anyway. Managers were happy. If I told them it would be done by Tuesday, it would be done by Tuesday. But it had enormous benefits beyond that. In almost 90% of cases, I had free time. Sometimes I'd admit to finishing early, but I also used that time to clean up technical debt, automate the tedious parts of my job, or advance my skills. After a while, I could give estimates as short as my old 50% estimates, and still beat them 90% of the time because I'd made my tasks so much easier. Less technical debt also meant the resulting code was less likely to have bugs. After a while, it seemed to me that all the other devs were overworked and I had it easy. But management gave me raises, and when they got in a jam, I was the guy they called on to bail them out.

interactivecode 2y ago
Being reliable is very valuable for the company. Better for you, better for the company. Unrealistic deadlines is bad for everyone involved. Especially for day to day work

Lanolderen 2y ago

I'm a junior and practically refuse to give estimates currently because the projects I currently get have no real requirements. "We'd like to replace an excel table for some calculations with a dialog. Here's the template, how long do you need?" which sounds simple enough turns into: 1- Decypher what the example excel template developed by someone over 10 years even does. 2- Oh, there are actually 10 templates and manual actions that give the end result. 2.5- Oh, btw, we asked an external company about doing this for us a while back and they wanted 1kk euros, crazy right? 3- Oh, we also need to generate, send and track offers via the app with the ability to add comments and upload files related to the offer. We also want the user to be queried about what data he has on hand so that calculations he cannot complete are not offered/he's notified as to what else he needs to proceed. 4- Oh, we also need change tracking/audit logs for everything. 5- Oh, we also need to get data from this place, find a free API and also a way to get data out of this software here. In comparison to that at my previous job the tasks were way smaller and clearer so I'd essentially give myself deadlines when talking to my manager by saying X and Y should be done by Z, A by B. The only thing I can think of in this situation is to essentially make internal pseudo contracts regarding requirements but then I'm making a pseudo contract with someone 3 levels in the hierarchy above me who's also the person who can terminate me. It's not like that pseudo contract will be read by anyone besides us so it seems better to display lots of uncertainty. At least if you're senior you have more authority in discussion and don't really have to give a fuck since everyone's looking to hire senior devs + your downgrade is a normal dev position. From junior the downgrade seems to be testing or McDonalds and you get to redo junior.