| ▲ | aoeusnth1 7 days 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. |
|
| ▲ | eminent101 6 days ago | parent | next [-] |
| 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. |
| |
| ▲ | koyote 6 days ago | parent | next [-] | | > 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 6 days ago | parent [-] | | > "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 6 days ago | parent [-] | | 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. |
|
| |
| ▲ | c0balt 6 days ago | parent | prev | next [-] | | 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 6 days ago | parent [-] | | 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". |
| |
| ▲ | gjvc 6 days ago | parent | prev | next [-] | | 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 6 days ago | parent | prev | next [-] | | 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. | |
| ▲ | bdangubic 6 days ago | parent | prev [-] | | 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 6 days ago | parent | next [-] | | 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 6 days ago | parent [-] | | In your 2nd example of a large corp I can see myself joining and not knowing anything about all these potential landmines etc… but if I was at that corp for say 2-3 years those would all be known things, no? And hence estimates can come with number of assumptions based on 6 other teams doing whatever it is that they need to do etc…? But I totally agree with your point and would not be disappointed if someone missed an estimate in that sort of chaos. My comment was not really geared towards chaotic organizations but general sense (especially in myriad threads on this forum) that SWEs think that somehow our profession is so “special” that we cannot possible know how long something will take. I simply do not accept that and personally believe that more likely vast majority of SWEs simply suck at their job. there are roughly 4.5 million of us, how many are really good at their jobs (big part of which is estimation)? probably like 0.4% :) | | |
| ▲ | WOTERMEON 6 days ago | parent [-] | | I agree with the general sentiment (estimation is part of the work, ppl are not good at estimates, ppl are not good at their job)
I also think that in high churn rate companies, or where team get created and disbanded every two quarters, it’s quite difficult to have a mental model on other teams ability to deliver a dependency for your team.
And this situation I find quite common tbh |
|
| |
| ▲ | redleggedfrog 6 days ago | parent | prev [-] | | You can't make accurate estimates that can be used for deadlines for non-trivial work. You can make educated guesses on how long specific things will take, and it might be a pretty good guess if you've been keeping metrics on your past work, including things like vacation days and other similar disruptions as well, and keeping a team together long enough to have solid institutional knowledge on your code-base. And you can respectfully lay these numbers out to a manager in the form of, "This will probably take 1 to 3 days," or for bigger stuff, "2 to 3 weeks", and so on. And the manager can take the sum of all this and say, "The soonest it can probably be done is 3 months, but most likely it'll be 4, with a small chance of a bit longer", or whatever, you get the idea. And then the mangers can set the deadline as they see fit. Now, for some reason, many managers just look at the first number and are done - that's the due date. And then after that they get deer in the headlights treatment, so the worst case becomes the best case. That's on them. If they don't understand that software estimation isn't an exact science they're in the wrong field. As for software development being special, I really hope that what I've described above is like other engineering disciplines, and we're not special. I don't want to be special, I want to be an engineer, like those who work with aircraft or bridges and what not. I feel like in those fields the concept of estimation is a little more respected. But I'm probably wrong. :^) I'll mention I've been a professional software developer since the early 90's, not that experience equals veracity. But I've had good success using the system above, and even though the bad managers to good managers was pretty even during that time, the company experienced outstanding success during my tenure (20 years!). In the end, bad managers never last. Good managers, who take reasonable estimates to their superiors, succeeded, where managers who brought "It'll be done July 1st" got doubted because their superiors know it really doesn't work that way. | | |
| ▲ | bdangubic 6 days ago | parent [-] | | your comment is exactly what I am talking about. you actually CAN make accurate estimates for non-trivial works. try to envision this - I hand you a non-trivial assignment to estimate with a condition that if you meet your estimate -/+ 5% you get 7-figure bonus. alternatively if you do not you get fired. after working 30 years in the biz you tell me which of the two is happening for you? I worked at two places that gave huge bonuses when deadlines were met (based on “estimates”) and wouldn’t you know it sh*t always got done on time and people got paid. | | |
| ▲ | leetcrew 6 days ago | parent | next [-] | | in the short term, people will work crazy hours to hit a date if it's the difference between a 7 figure bonus and getting fired. if the estimate is based on devs working reasonable hours, that's a lot of slack built in. I'm sure they hit the date more often than not in your scenario, provided they control most of the dependencies, but it's not a sustainable approach for delivering features. "provided they control most of the dependencies" is a pretty important caveat by the way. many times I've seen people get the rug pulled out from under them by partner teams at the last second. it doesn't matter how clever you are or how hard you work. if you depend on something owned by a team far away in the org chart, they can always blow up your project with little consequence. | | |
| ▲ | bdangubic 6 days ago | parent [-] | | I honestly do not think it is about working crazy hours. perhaps my example can be misunderstood in a sense that if you give someone 7-figure bonus they will inevitably work 20hrs/day if necessary to get there which of course would not mean that they estimated correctly but were off by 12hrs/day :) as things stand what is my incentive to provide an accurate estimate? if no one can question my estimate and hold me to it (well perhaps they can question it but we as industry have successfully been able to convince everyone that these are just estimates, nothing else...) what is my incentive to be accurate? If like one of the commenters above can say "it'll be 2 to 3 weeks" there is an INSANE difference between 2 and 3 weeks, 33% difference. it's like coming to buy a house and agent says "this house is $200k or $300k but you sign here on the bunch of dotted lines and we'll tell you all about it eventually before you have to cut a check." It is good to be in this industry (and especially if you WFH) - say 2 to 3 weeks, finish in 2 and get a week of working on your wellness (or another job :) ) | | |
| ▲ | yetihehe 6 days ago | parent | next [-] | | > it's like coming to buy a house and agent says "this house is $200k or $300k but you sign here on the bunch of dotted lines and we'll tell you all about it eventually before you have to cut a check. Not really with price, but when I've had my house built, the date was overshoot by about 30% too, because of various reasons, like having to stop for winter because some supplies were late by a week several times or my builders had to help teams at other places from time to time (because other teams were late too), not doing anything at my house sometimes for days. So even when building homes (something they do again and again) you can't really put exact estimates. | |
| ▲ | 6 days ago | parent | prev [-] | | [deleted] |
|
| |
| ▲ | redleggedfrog 6 days ago | parent | prev [-] | | That's an interesting scenario you're proposing. To answer it personally, which of the two, 7 figure bonus or being fired, it'd be I'd quit. If someone is structuring the development of software based on this premise, then they are going to need a different kind of person than me. But I admit I'm probably an outlier here. I don't really work for the money, and my salary is enough, and I don't like undo pressure. For arguments sake let's say the 7 figures is $1,000,000. To offer that kind of bonus the project is likely going to be a larger one. And I'm assuming my estimate is determining the deadline, so of course I'm making sure it's something I think I can achieve. But then there are other significant problems with this structure and the likelihood of meeting the deadline, and, more importantly, generating good code and user experience. - +5% (in ignoring the -5% as no one cares if you're early unless it creates some sort of QA burden) implies a narrow window. On a 6 month project that is ~6 days. Enough that personnel changes or other uncontrollable factors could lead to a missed deadline. One person getting fed up and leaving would be a huge problem. - The specification would have to be really clear and agreed upon, since there is much at stake. - Any changes, scope creep, customer requests, could change the development time, and you'd have to have some sort negotiating buffer built in since there is now so much at stake. Otherwise you're going to get literally everything rejected by the developer as they drive towards the deadline (maybe that's what you want, though). - Is the result worth having? A focus on a deadline, in my experience, tends to shortchange quality. But maybe the deadline is more important than quality. - And lastly, if that deadline is missed, or worse, something changes the scope of the project and the bonus is not awarded because that led to the deadline being missed, you're going to have some super pissed developers that will not trust such an arrangement in the future. I suspect you're talking about situations beyond my pay-grade. I've been a meat and potatoes programmer working in e-commerce and integrations mostly, and we don't see 7 figure bonuses. We certainly have had can't miss deadlines that we mostly didn't miss, but mostly those deadlines were due to external factors (API deprecation mostly), or financial considerations, or lastly, arbitrary deadlines set by management. On the latter, those mostly got missed. But that was to be expected as they were not tied to reality. And I'd second leetcrews comment below of, "...but it's not a sustainable approach for delivering features". Maybe this scenario works once or twice, but it seems like a terrible way to develop software. But still, an interesting thought experiment. |
|
|
|
|
|
| ▲ | tivert 6 days ago | parent | prev | next [-] |
| > 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. |
| |
| ▲ | jjk166 6 days ago | parent | next [-] | | 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. | |
| ▲ | tonyedgecombe 6 days ago | parent | prev [-] | | I think a lot of them know the difference, they just don't care. The estimate is a tool to beat you with. |
|
|
| ▲ | mewpmewp2 6 days ago | parent | prev | next [-] |
| 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 6 days ago | parent [-] | | 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 6 days ago | parent [-] | | 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 6 days ago | parent [-] | | 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. | | |
| ▲ | mewpmewp2 6 days ago | parent [-] | | I have thought about how it would be fun to have something where people will either openly or blindly estimate and bid. In practice I might be concerned about few things like introducing too much of a competitive culture within the team. Or it could lead to a place where people get too specialized and knowledge doesn't spread around, since everyone will bid on things they have experience with, and so they will be the only one with that experience, which might hurt in the long run. I couldn't actually imagine doing it in my current team. I think people are diligent anyway, and already work more hours than usually would be required.
I find it better to just try to protect each other within the team, to drive everyone making higher estimates. Also doing bidding for those estimates in addition could mean that there might be strong incentives for a lot of corner cutting for certain tasks, etc. People will value short term gains over long term gains when there's such pressure. | | |
| ▲ | rightbyte 6 days ago | parent [-] | | I think any process step that resembles a game might be problematic. And a major problem with group estimates is that given how much knowledge a person has about the code, the effective time will vary so much. So dunno. I have no experiance as a team lead or manager. I would probably not track task time at all as a manager. It would give the illusion of insight. Rather some loose percent worked by project per programmer. |
|
|
|
|
|
|
| ▲ | Moru 6 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | ebiester 6 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | switchbak 6 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | DennisP 6 days ago | parent | prev | next [-] |
| 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 6 days ago | parent [-] | | 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 6 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | watwut 6 days ago | parent | prev | next [-] |
| > 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. |
|
| ▲ | qaq 6 days ago | parent | prev | next [-] |
| 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. |
|
| ▲ | Aeolun 6 days ago | parent | prev | next [-] |
| > 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. |
|
| ▲ | disambiguation 6 days ago | parent | prev [-] |
| Yeah but missing estimates makes you look super duper incompetent by comparison. |
