8 ms·

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual

I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone on the team needs to take an hour or so and figure out what this is really going to take." Then you'll get asked to "ballpark it" because that's what managers do, and they get a number that makes them rise up in their chair, and yes, that is the number they remember. And then you do your hour of due diligence, and try your best not to actually give any other number than the ballpark at any time, and then you get it done "ahead of time" and look good. Now, I've had good managers who totally didn't need this strategy, and I loved 'em to death. But for the other numbnuts who can't be bothered to learn their career skills, they get the whites of my eyes. Also, just made meetings a lot more fun.

aoeusnth1 2y ago
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".
- 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.
bodge5000 2y ago
Always reminds me of this https://youtu.be/8xRqXYsksFg?si=qlG18BB2nNUmt3ub https://youtu.be/8xRqXYsksFg?si=qlG18BB2nNUmt3ub
- citizenkeen 2y ago
  Knew what this was without clicking on it.
bigiain 2y ago
> I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. I worked at a place where this management insanity was endemic, which lead to everyone padding all estimates with enough contingency to account for that. Which lad to the design team, and the front-end team, and the backend team, and the QA team, all padding out their estimates by 150 or 200% - to avoid the blame storms they'd seen for missing "deadlines". Then the Project managers added those all ups and added 150 - 200%. Then the account managers and sales teams added 150 - 200% to the estimated costs before adding margins and setting prices. Which ended up in literally around 1 million dollars a month to maintain a website which could _easily_ have been handled by a full time team of 8 or 10 decent web and full stack devs. Hell, apart from the 24x7 support requirement, I reckon I know a few great Rails or Django devs who could have done all the work on their own, perhaps with a part time of contracted graphic designer. That all lasted a handful of years, until the client worked out what was going on, and my company management flew the whole thing into the mountain, with ~100 people losing their jobs and their owed entitlements (I was out about $26K that day.)
- ethbr1 2y ago
  This is literally the endgame. And the only cure is instead building a company that's tolerant of mistakes while still aspiring to excellence. The one I've worked at which got the closest had a corporate culture that failures were atrributable to processes, while successes were atrributable to individuals/teams. Of course that had its own negative side effects, but on the whole it made the company a lot more honest with itself. And consequently got better work out of everyone.
  - likium 2y ago
    Just curious if the processes got tuned/adjusted as a result? And what were the negative side effects?
    - ethbr1 2y ago
      Absolutely! That was one of the common productive outcomes: this policy / approach is screwed up, and we could do it better. Negative side effects were about what you'd imagine. Some low performers unjustly shielded themselves. Safeguards were overbuilt as proof "something" was changed to prevent a failure repeat. Executive promotion criteria could get squirrelly. Etc. But on the whole, I think the individual/team productivity boost and agility created by honesty was a huge net win.
mock-possum 2y ago
Some of the best career advice I got was very early on at my first gig - I had a designer tell me, over a cup of sake, that I should just inflate all my estimates by 60%. 30% to cover the stuff I hadn’t thought of, 30% to cover what they hadn’t thought of. That sounded insane to me… nearly two decades later, with plenty of remote freelance and full time onsite team experience under my belt… and I fully agree. It’s always going to take significantly longer, and if you pretend it’s not, it’s going to come down on your head, like it or not. Always better to underpromise and overdeliver than the other way around.
Etheryte 2y ago
The hallmark of a bad manager who doesn't know they're a bad manager: "Why can't you just give me a number?" Inexperienced managers or people backfilling for someone else I can completely understand, they're not comfortable with the uncertainty they're dealing with. However in any other circumstance I think it's inexcusable.
- jimmydddd 2y ago
  But you have to remember that the manager is going to be asked for an estimate by his boss. He can't just say some time between "1 day and 10 years." In the real world, you have to be able to give some sort of estimate and help the poor guy do his job.
  - xedrac 2y ago
    And thus we get to the root of the problem. As as business executive, why not simply track how long your big projects tend to take, rather than try and dictate how long they should take?
    - mewpmewp2 2y ago
      How can you tell what is worth doing if you don't know how long it might take?
      - zelphirkalt 2y ago
        You make projections instead of estimates. You split the work that needs to be done into many tasks and project from past experiences. You cannot rely 100% on any estimates either, and all you are doing by demanding estimates is creating stress and making people less productive. The meta work imposed by that in itself will make a project take more time, as everyone will be padding their estimates.
        mewpmewp2 2y ago
        What is the difference between a projection and an estimate?
andai 2y ago
Reminds me of Hofstadter's Law: It always takes longer than you think, even when you take into account Hofstadter's Law. We could say, always say it will take longer than you think? Though by this principle, it seems that "overestimates" are likely to be actually accurate? Joel Spolsky wrote about his time estimation software which recorded the actual time required for completion, and then calculated for each person a factor by which their estimates were off, and this factor was consistent enough that it could be reliably used as a multiplier to improve estimation accuracy. > Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected, because the estimate didn’t account for bug fixing, committee meetings, coffee breaks, and that crazy boss who interrupts all the time. This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6} https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
- ethbr1 2y ago
  Doesn't the article say that for experienced developers, the scaling factor tended to be converge on an average for each individual, even if variable for any particular task? And Joel sidesteps the unknown-unknowns problem in that piece, by discussing boiling down tasks to <1 day chunks. But what if you need to build a prototype before you sufficiently understand the project and options to decide on an approach? Where does that time get estimated? The more projects I work on, the bigger of a fan of spiral development [0] I become. Because, at root, there are 2 independent variables that drive project scheduling -- remaining work and remaining risk. This estimation problem would drastically simplify if it allowed for "high confidence, 30 days" and "low confidence, 5 days" estimates. And critically, that could drive different development behavior! E.g. prototype out that unknown feature where most of the remaining technical risk is. Trying to instead boil that down to an un-risk-quantified number produces all the weird behaviors we see discussed elsewhere in the comments. [0] https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model
- conception 2y ago
  I’m more of a Parkinson’s Law person: "Work expands so as to fill the time available for its completion.” Things take longer but if you over-estimate the project won’t come in significantly any earlier.
genghisjahn 2y ago
What helped me was to track Sprint Volatility in addition to Sprint Velocity. We had our over all capacity, let's say 40 points and that would go up or down some based on people leaving the team, joining the team, etc. It's just an average of how much a team can get done in a given sprint. Velocity was gauged as points per person per day. Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points. I would snapshot the sprint each day, so each day I could see how many tickets got removed/added. The end result being I could show my manager, look, when volatility is low, we almost always finish the sprint. When the volatility is high, we don't, it doesn't matter if we are over/under velocity because we don't have the time to properly plan and get clarity on asks. Have our product team think more than two weeks out and we'll deliver. That worked to a degree.
- nunez 2y ago
  Jitter in agile; I love it.
- Izkata 2y ago
  > Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points. Isn't the entire point of a sprint that, once planning at the start of the sprint is over, you can't change what's in it by reprioritizing? All of product's reprioritizing should be in the backlog, not the sprint, and only affect what the next sprint is going to be, not the current one.
  - wolpoli 2y ago
    In official scrum, the development team could choose to accept substitution. It looks like the GP's case, they are obligated to accept substitution.
    - genghisjahn 2y ago
intelVISA 2y ago
Problem is anything non-trivial can't be estimated: deadlines are useful to timebox the process and keep it accountable with a follow-up to see if it's worth continuing. Otherwise it becomes "just trust me bro" which is equally unfair in the opposite direction.
- veunes 2y ago
  "Just trust me" approaches can be just as damaging as rigid demands for precise estimates
deleted 2y ago
[deleted]
groby_b 2y ago
One way to get the point across is by stopping to pretend estimates are precise. Instead of giving a single fixed estimate, give one with error bars. "3 months, plus minus 4 weeks". Most engineers know their estimates have error bars, but have somehow been bludgeoned into forgetting to mention them. It's also helpful from the management side - the size of the error bars makes it immediately clear how confident folks are in the estimate. It allows reasoning about risk. It allows things like "OK, currently we have 30% error bars either way - what are the biggest contributors to that? Can we knock one or two of those out when we spend a few days investigating?" It's beyond me why we, as a supposed engineering profession, are unable to talk about risk, probabilities, and confidence intervals. And that isn't just on managers.
- smegger001 2y ago
  >It's beyond me why we, as a supposed engineering profession, are unable to talk about risk, probabilities, and confidence intervals. And that isn't just on managers. Because management quits listening after hearing "3 months," and bad management heard "3 months minus three weeks" and goes "okay 2 months it is".
  - groby_b 2y ago
    Outside of cartoons and a couple of rather bad environments, that's just plain made up nonsense. Management in most places is rather interested in getting planning right, not making up numbers and then failing at achieving them. They often lack the training to get it right (both because we have non-engineers as managers, and because we give shit management training to the engineers that become managers), but "management quits listening" is just an excuse. I'm in this thing for ~4 decades now, at a good number of companies of all sizes (3-200,000) and I've seen the "not listening and insisting on made up numbers" exactly once. I see however a lot of engineers refuse to even attempt to make reasonable estimates.
veunes 2y ago
I think "good managers" create environments where estimates are treated as collaborative tools rather than promises etched in stone
InsideOutSanta 2y ago
"then you get it done "ahead of time" and look good" If you "look good" too often, your estimates will be distrusted. So, just play some videogames and look like you're a genius at estimating.
skeeter2020 2y ago
if you need to deal with this, you must present estimates as ranges or distributions. Management needs a value for both concrete, legit purposes like budgets and also for (still legitimate) psychological reasons like building comfort that they know what's going on and they are in control. As you mention, people will anchor on a number and that in a nutshell is how an estimate becomes a deadline. Planning and execution will refine the value right up to the point you ship with a very accurate estimate of "how long do you think this will take?".
ppeetteerr 2y ago
For starters, never commit to a timeline without doing your due diligence. We're not selling carpets. Anyone who gives a time estimate on the spot is setting themselves up for failure. Second, always pad your estimates. If you have been in the industry longer than 6 months, you'll already know how "off" your estimates can be. Take the actual delivery date, divide that by the estimated date, and that's your multiplier.

aoeusnth1 2y ago

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".
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.

bodge5000 2y ago

Always reminds me of this https://youtu.be/8xRqXYsksFg?si=qlG18BB2nNUmt3ub https://youtu.be/8xRqXYsksFg?si=qlG18BB2nNUmt3ub

citizenkeen 2y ago
Knew what this was without clicking on it.

bigiain 2y ago

> I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. I worked at a place where this management insanity was endemic, which lead to everyone padding all estimates with enough contingency to account for that. Which lad to the design team, and the front-end team, and the backend team, and the QA team, all padding out their estimates by 150 or 200% - to avoid the blame storms they'd seen for missing "deadlines". Then the Project managers added those all ups and added 150 - 200%. Then the account managers and sales teams added 150 - 200% to the estimated costs before adding margins and setting prices. Which ended up in literally around 1 million dollars a month to maintain a website which could _easily_ have been handled by a full time team of 8 or 10 decent web and full stack devs. Hell, apart from the 24x7 support requirement, I reckon I know a few great Rails or Django devs who could have done all the work on their own, perhaps with a part time of contracted graphic designer. That all lasted a handful of years, until the client worked out what was going on, and my company management flew the whole thing into the mountain, with ~100 people losing their jobs and their owed entitlements (I was out about $26K that day.)

ethbr1 2y ago
This is literally the endgame. And the only cure is instead building a company that's tolerant of mistakes while still aspiring to excellence. The one I've worked at which got the closest had a corporate culture that failures were atrributable to processes, while successes were atrributable to individuals/teams. Of course that had its own negative side effects, but on the whole it made the company a lot more honest with itself. And consequently got better work out of everyone.
- likium 2y ago
  Just curious if the processes got tuned/adjusted as a result? And what were the negative side effects?
  - ethbr1 2y ago
    Absolutely! That was one of the common productive outcomes: this policy / approach is screwed up, and we could do it better. Negative side effects were about what you'd imagine. Some low performers unjustly shielded themselves. Safeguards were overbuilt as proof "something" was changed to prevent a failure repeat. Executive promotion criteria could get squirrelly. Etc. But on the whole, I think the individual/team productivity boost and agility created by honesty was a huge net win.

mock-possum 2y ago

Some of the best career advice I got was very early on at my first gig - I had a designer tell me, over a cup of sake, that I should just inflate all my estimates by 60%. 30% to cover the stuff I hadn’t thought of, 30% to cover what they hadn’t thought of. That sounded insane to me… nearly two decades later, with plenty of remote freelance and full time onsite team experience under my belt… and I fully agree. It’s always going to take significantly longer, and if you pretend it’s not, it’s going to come down on your head, like it or not. Always better to underpromise and overdeliver than the other way around.

Etheryte 2y ago

The hallmark of a bad manager who doesn't know they're a bad manager: "Why can't you just give me a number?" Inexperienced managers or people backfilling for someone else I can completely understand, they're not comfortable with the uncertainty they're dealing with. However in any other circumstance I think it's inexcusable.

jimmydddd 2y ago
But you have to remember that the manager is going to be asked for an estimate by his boss. He can't just say some time between "1 day and 10 years." In the real world, you have to be able to give some sort of estimate and help the poor guy do his job.
- xedrac 2y ago
  And thus we get to the root of the problem. As as business executive, why not simply track how long your big projects tend to take, rather than try and dictate how long they should take?
  - mewpmewp2 2y ago
    How can you tell what is worth doing if you don't know how long it might take?
    - zelphirkalt 2y ago
      You make projections instead of estimates. You split the work that needs to be done into many tasks and project from past experiences. You cannot rely 100% on any estimates either, and all you are doing by demanding estimates is creating stress and making people less productive. The meta work imposed by that in itself will make a project take more time, as everyone will be padding their estimates.
      - mewpmewp2 2y ago
        What is the difference between a projection and an estimate?

andai 2y ago

Reminds me of Hofstadter's Law: It always takes longer than you think, even when you take into account Hofstadter's Law. We could say, always say it will take longer than you think? Though by this principle, it seems that "overestimates" are likely to be actually accurate? Joel Spolsky wrote about his time estimation software which recorded the actual time required for completion, and then calculated for each person a factor by which their estimates were off, and this factor was consistent enough that it could be reliably used as a multiplier to improve estimation accuracy. > Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected, because the estimate didn’t account for bug fixing, committee meetings, coffee breaks, and that crazy boss who interrupts all the time. This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6} https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

ethbr1 2y ago
Doesn't the article say that for experienced developers, the scaling factor tended to be converge on an average for each individual, even if variable for any particular task? And Joel sidesteps the unknown-unknowns problem in that piece, by discussing boiling down tasks to <1 day chunks. But what if you need to build a prototype before you sufficiently understand the project and options to decide on an approach? Where does that time get estimated? The more projects I work on, the bigger of a fan of spiral development [0] I become. Because, at root, there are 2 independent variables that drive project scheduling -- remaining work and remaining risk. This estimation problem would drastically simplify if it allowed for "high confidence, 30 days" and "low confidence, 5 days" estimates. And critically, that could drive different development behavior! E.g. prototype out that unknown feature where most of the remaining technical risk is. Trying to instead boil that down to an un-risk-quantified number produces all the weird behaviors we see discussed elsewhere in the comments. [0] https://en.m.wikipedia.org/wiki/Spiral_model https://en.m.wikipedia.org/wiki/Spiral_model
conception 2y ago
I’m more of a Parkinson’s Law person: "Work expands so as to fill the time available for its completion.” Things take longer but if you over-estimate the project won’t come in significantly any earlier.

genghisjahn 2y ago

What helped me was to track Sprint Volatility in addition to Sprint Velocity. We had our over all capacity, let's say 40 points and that would go up or down some based on people leaving the team, joining the team, etc. It's just an average of how much a team can get done in a given sprint. Velocity was gauged as points per person per day. Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points. I would snapshot the sprint each day, so each day I could see how many tickets got removed/added. The end result being I could show my manager, look, when volatility is low, we almost always finish the sprint. When the volatility is high, we don't, it doesn't matter if we are over/under velocity because we don't have the time to properly plan and get clarity on asks. Have our product team think more than two weeks out and we'll deliver. That worked to a degree.

nunez 2y ago
Jitter in agile; I love it.
Izkata 2y ago
> Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points. Isn't the entire point of a sprint that, once planning at the start of the sprint is over, you can't change what's in it by reprioritizing? All of product's reprioritizing should be in the backlog, not the sprint, and only affect what the next sprint is going to be, not the current one.
- wolpoli 2y ago
  In official scrum, the development team could choose to accept substitution. It looks like the GP's case, they are obligated to accept substitution.
  - genghisjahn 2y ago

intelVISA 2y ago

Problem is anything non-trivial can't be estimated: deadlines are useful to timebox the process and keep it accountable with a follow-up to see if it's worth continuing. Otherwise it becomes "just trust me bro" which is equally unfair in the opposite direction.

veunes 2y ago
"Just trust me" approaches can be just as damaging as rigid demands for precise estimates

deleted 2y ago

[deleted]

groby_b 2y ago

One way to get the point across is by stopping to pretend estimates are precise. Instead of giving a single fixed estimate, give one with error bars. "3 months, plus minus 4 weeks". Most engineers know their estimates have error bars, but have somehow been bludgeoned into forgetting to mention them. It's also helpful from the management side - the size of the error bars makes it immediately clear how confident folks are in the estimate. It allows reasoning about risk. It allows things like "OK, currently we have 30% error bars either way - what are the biggest contributors to that? Can we knock one or two of those out when we spend a few days investigating?" It's beyond me why we, as a supposed engineering profession, are unable to talk about risk, probabilities, and confidence intervals. And that isn't just on managers.

smegger001 2y ago
>It's beyond me why we, as a supposed engineering profession, are unable to talk about risk, probabilities, and confidence intervals. And that isn't just on managers. Because management quits listening after hearing "3 months," and bad management heard "3 months minus three weeks" and goes "okay 2 months it is".
- groby_b 2y ago
  Outside of cartoons and a couple of rather bad environments, that's just plain made up nonsense. Management in most places is rather interested in getting planning right, not making up numbers and then failing at achieving them. They often lack the training to get it right (both because we have non-engineers as managers, and because we give shit management training to the engineers that become managers), but "management quits listening" is just an excuse. I'm in this thing for ~4 decades now, at a good number of companies of all sizes (3-200,000) and I've seen the "not listening and insisting on made up numbers" exactly once. I see however a lot of engineers refuse to even attempt to make reasonable estimates.

veunes 2y ago

I think "good managers" create environments where estimates are treated as collaborative tools rather than promises etched in stone

InsideOutSanta 2y ago

"then you get it done "ahead of time" and look good" If you "look good" too often, your estimates will be distrusted. So, just play some videogames and look like you're a genius at estimating.

skeeter2020 2y ago

if you need to deal with this, you must present estimates as ranges or distributions. Management needs a value for both concrete, legit purposes like budgets and also for (still legitimate) psychological reasons like building comfort that they know what's going on and they are in control. As you mention, people will anchor on a number and that in a nutshell is how an estimate becomes a deadline. Planning and execution will refine the value right up to the point you ship with a very accurate estimate of "how long do you think this will take?".

ppeetteerr 2y ago

For starters, never commit to a timeline without doing your due diligence. We're not selling carpets. Anyone who gives a time estimate on the spot is setting themselves up for failure. Second, always pad your estimates. If you have been in the industry longer than 6 months, you'll already know how "off" your estimates can be. Take the actual delivery date, divide that by the estimated date, and that's your multiplier.