19 ms·

"No, it's less effort than that"

• deleted 3y ago
  [deleted]
• scotty79 3y ago
  Pushing estimates is silly. If you have another estimate than your developer you have every right to have it and make decisions based on it. But the reality of how much it will actually take is the future. It is unknown and will probably worse than both your estimate and the one of your developer you don't agree with.
• avereveard 3y ago
  Pushing estimated is wrong but solutions exists in a spread of quality, completeness and efficiency, you can definitely find a balance where the time to release is shorter, if you are prepared to give up something else Often the issue is that programmer are unaware of the exact quality and sophistication expectations and estimate the perfect solution with the most efficient algorithmic complexity whether it makes sense or not for the business scale and the other constraints at hand. Then management ask shorter deadlines, programmers find different solutions that may or may not be appropriate, and it gives the illusory appearance that managing is working, while the underneath visibility/communication issue remains unaddressed while creating potential technical debt.
• zeroCalories 3y ago
  Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.
  • phanimahesh 3y ago
    Also any estimate providedwill be pushed downwards, not to mention unforeseen curveballs, so there is an incentive to estimate higher to preserve your own sanity. Some don't learn to estimate higher until they get burnt. Another common pitfall is to estimate each task in isolation, and the people receiving the estimates considering them timelines. Effort estimates and delivery timelines are wildly different beasts and great care has to be taken to avoid miscommunications.
  • ejb999 3y ago
    >>Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. Bingo, having just left a mega-corp this is the status-quo of a lot of projects I had visibility into - take a trivial task, estimate it at 8-13 story points (i.e. the whole 2 week sprint), have nobody question the estimates, complete the story in 1-2 days and then chill for the other 8-9 days left in the sprint. It was pretty much an open secret. ...and nobody gets faulted by management, because they completed the story in the time they committed to. On the other hand, if you had estimated the task at 3 days, and it ends up taking 5, you would get dinged for it. Estimate the same task at 13 story points, even if it was really only a 3, you were rewarded for meeting estimates - its a very perverse incentive structure.
    • deleted 3y ago
      [deleted]
    • rightbyte 3y ago
      Ye. If the estimates are accurate they will be overrun about 50% of the time. Punishing "late" tickets is what leads to the outcome of having to pad the estimates as much as possible.
    • DiskoHexyl 3y ago
      Predictability is arguably more important than speed, especially when you have a lot of moving parts. When you have a developer that is slow, but constantly delivers on his estimates, you have a reliable IC that you can count on not failing to develop an API for some other team to integrate with. Fast and ambitious guys, who frequently fall behind their own estimates, are a pain in the ass to manage in large teams/companies. Sure, with startups on the bleeding edge and with RnD it's different, but most of devs aren't doing that
      • orwin 3y ago
        Fast and ambitious guys, who frequently fall behind their own estimates I wasn't particularly fast, but I was this guy for a year. You're exactly right.
    • 3y ago
  • Buttons840 3y ago
    > Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. Developers have to push for higher estimates because management has an incentive to underestimate to make life easier. See what I did there? There's a fallacy in both statements: one side's actions are portrayed as greedy pursuit of "incentives" while the other side's actions are portrayed as a natural and logical counter to those incentives.
    • zeroCalories 3y ago
      You're reading too much into the morallity. Furthermore how is it a fallacy?
      • em-bee 3y ago
        it's a fallacy in that it implies that one side is right and the other is wrong. (or one side is fair and the other is greedy)
        • zeroCalories 3y ago
          My argument is not assigning blame, but explaining why the article will not convince many managers. It works assuming either side can be greedy or fair.
          • em-bee 3y ago
            many projects everywere are failing their estimates. so the idea that developers overestimate the time it takes to complete a project is not supported by statistics. Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. this statement as written clearly supports management and puts blame on developers. if that wasn't your intention then it could be expressed more neutrally: management pushes for lower estimates, because they believe that developers intentionally overestimate, therefore this article will not convince them my response to that would still be the same though. statistics don't support that developers overestimate. on the contrary, one might even be motivated to claim that projects failing their estimates is caused by these managers.
  • throwawaysleep 3y ago
    You punish us for being ambitious and failing and give us nothing for being ambitious and succeeding. As a developer, I endorse doing as little as possible as a result.
    • zeroCalories 3y ago
      This is a very childish way of viewing the situation. Of cousd you should look out for yourself, but your reward is not fixed, so you should not look to minimize your work at all costs
      • throwawaysleep 3y ago
        My reward is fixed as my salary is fixed.
        • zeroCalories 3y ago
          For most people it isn't. Most jobs offer raises, promotion, and bonuses for high performers. Low performers get PIP, salary adjustments, and layoffs. If you work at a competitive place like Amazon or Microsoft, there isn't even a floor for performance because you'll be stack ranked. But hey maybe you work some of the few high pay / low effort jobs where it's impossible to get fired.
  • deleted 3y ago
    [deleted]
  • nonameiguess 3y ago
    Estimate high is the mathematically most valid thing to do in the face of uncertainty. This is more or less the fundamental theorem of finance. Expected rate of return increases with risk as compensation for the risk. Project planning should be following the same principle. If you're uncertain of traffic conditions, you leave earlier to be safe. If you're uncertain of future work unknowns, you estimate longer completion time to be safe. If management is pushing for lower estimates, it's typically going some reason along the lines of: - Someone higher up gave them a fixed budget or a fixed deadline and they can't exceed that. - They're expecting market conditions to reward earlier delivery more than higher quality. - They don't understand the problem domain. - They do understand the problem domain but don't understand limiting factors like tech debt or organizational process hurdles the developers face that preven them from hitting timelines they would hit under ideal conditions. If it's one of the latter two, they need to have a come to Jesus moment with themselves because you can't run a team if you don't understand what they do, how they do it, and what obstacles they face. If it's one of the former two, great, communicate that, but then whoever is ultimately accepting or using your product needs to understand the basic release models that you can either get a complete set of well-defined features or you can get a specific release date but you can't get both, except by luck. And you need to have an organizational culture that isn't going to punish developers if they don't get lucky and meet only one of those goals. Companies purchasing labor output don't get to violate the basic constraints of being a consumer. If you've got a fixed budget, fine, but you get what you pay for.
  • marcosdumay 3y ago
    > developers have an incentive to overestimate to make life easier Have you ever seen developers overestimate their tasks? On what kind of alternative dimension this happens? Developers are always deluded optimists that can't get realistic estimates no matter how much they inflate it.
• Scarblac 3y ago
  It's not quite true. Many features can be in a very bare bones way or in a fully gold plated way, and several shades in between. Sometimes I see colleague developers estimate two weeks for a feature I consider one day at most, because they assume lots of extra functionality that wasn't actually asked for, or that I didn't realize would be necessary. If you are asked to change your estimate, see it as an invitation to discuss the requirements and proposed implementation a bit more. Maybe something much simpler that brings you 90% of the way there is both possible and a acceptable. Meteorologists don't have that option.
  • anonzzzies 3y ago
    Often clients don't understand what they want; like you say, the difference between met plonking in a basic combobox/select vs some much nicer, and much more fitting the case, custom ui element doesn't really translate to anything many people outside IT understand. To explain this difference it can be drawn, but stakeholders still don't understand what's going on as they don't see & feel it, so you have to make it work mostly. I have clients asking 'just do the simplest thing you can do'; we present prototyped gui's then after approval fully designed guis and after that a prototype. They approve the first 2 immediately as they can't even be bothered looking at them; some, when pressed, will try the prototype and often still say 'yes great, let's go'. And then when it works and they can try it on the test server, they say 'no this is really not what we meant'. I have had this with 2 person mom and pop stores (long ago; I don't do those anymore luckily) to fortune 500 companies with the regional directors and global cto present to give their opinion. And this is frontend ... Backend, devops is another thing entirely, but there, is also a large difference between bare bones or gold plated. I know the game by now, so these days we make a lot of money from this broken process.
    • Scarblac 3y ago
      The other extreme is that management was talking about new functionality and we kept seeing it as just another small feature in our existing product, and kept giving them estimates of a few weeks. Until they ended up setting up a whole new team for it because what they had in mind was a completely new product fully focused on that functionality. It's all communication, programmers and stakeholders live in different worlds.
• IanCal 3y ago
  A valuable discussion to have is about how to change the scope so that the cost/return tradeoff is right for your stakeholders. I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day. > There is back-and-forth as the estimates are questioned for being too high, almost never for being too low. I'm sure people will have flashbacks when I say this so sorry to those, but this is the issue addressed with planning poker. The idea being that you all say how hard the task is, without being affected by each other, and discuss when expectations aren't aligned. Someone is probably missing something. I might think something is simple because I've not realised a complex part of the problem, or because I can see a nicer neater solution.
  • atoav 3y ago
    I get that. But as a tech guy I sometimes get itchy when the actual reality of things is ignored. A good example would be when a customer demands something that is mathematically or physically not possible. With wishes like these you could the do the planning poker all day and maybe land at a compromise that is still not possible. As a former freelancer I am a big fan of just getting a thorough explaination of the problem, maybe with me looking over the shoulder of someone who has to solve it currently. And then I vanish in a hole for a few days and return with the design proposal I think would most elegantly, reliably etc solve the problem. Unless we are speaking about people who have good experience with complex problems, most people are okay at describing their problems, but suck at proposing solutions (they are always modelled after the limited things they know).
    • IanCal 3y ago
      Always a good time to rewatch the expert: https://youtu.be/BKorP55Aqvg?si=eqw2-mWA1T3FDUtl https://youtu.be/BKorP55Aqvg?si=eqw2-mWA1T3FDUtl > most people are okay at describing their problems, but suck at proposing solutions Yes, it's best to focus on their problems and the consequences of proposed solutions. They shouldn't care about your caching strategy internals but they do care about whether stale info impacts their users or what scale it's reasonable to hit, or how much extra it'll cost to implement.
• code_biologist 3y ago
  I'm glad the article gets to talking and haggling with stakeholders. Trying to estimate with different understandings of where complexity lies between stakeholders, product managers, and devs is the biggest source of frustration in my experience. Lol, long ago I was working with a junior PM who heard what was difficult and what was easy from devs and started to design features around that intuition to make work faster. Too smart for his own good though. Often the proposed features would be more complicated in trying to be easy. Much to his chagrin, our ticket estimation sessions often turned to "wait, what are we trying to do here again?" But often, one week of work turned into a day or two. The world is complicated and I think a sizable minority of workplaces defy stereotypes. One hard driving "VP of Operations" type I worked with would push for aggressive estimates, but alongside that suggested every corner that could be cut without hampering the business. In a bizarre way, he was far more agile/MVP/product-validation focused than almost all of the technical staff. I've seen fast but sloppy developers drive stakeholders crazy. One situation I was in, we needed to culturally back off from way over-spec'ed tickets. The engineers had been focused on closing tickets and "shipping" as fast as possible. If a detail wasn't in the ticket, it wasn't happening, so tickets got bloated and rigid. The rest of the business was ok with slowing down if it meant reliable features, the engineering leadership was the most hesitant.
• m0llusk 3y ago
  This is a bad metaphor. You can't make the sun come out faster by dropping features.
  • albert_e 3y ago
    yeah i cannot use this analogy to tell my client to backoff. they will say: if you guys are only watching the weather and telling me whether it will rain or not -- I dont need you guys then. I will hire someone else - who will build me a working umbrella within my budget before it starts to rain. or some other imperfect analogy that we cannot question having done the same thing ourselves first
  • wojciii 3y ago
    What you can do is release a product faster with less features and continue working on adding the missing features after the initial release. This happens all the time in embedded systems which can be updated by the customer.
• pydry 3y ago
  If you're asking for estimates from devs at all you're probably pushing waterfall on them. If you want to be waterfall, that's fine. If you're forced into doing it by your business context, that's also fine. But, you shouldn't be under any illusions about what you're doing. It's a waterfall behavior that will drive waterfall effects.
  • maccard 3y ago
    That's just not true. It _can_ be waterfall, but story points are everywhere in agile development.
    • pydry 3y ago
      Story points are for relative sizing are not estimates. That's why you use story points and not hours or days. They're for re-arranging the priority of stories and deciding which ones to do or not.
      • maccard 3y ago
        > relative sizing are not estimates. Relative sizing is still an estimate. > They're for re-arranging the priority of stories and deciding which ones to do or not. Hard disagree - that's what priority is for. Story points are an _estimate_ for how much we can do in a period.
        • pydry 3y ago
          >Relative sizing is still an estimate. Not one which would attract any pressure.
          • regularfry 3y ago
            If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint. If you don't think toxic managers and scrum masters are going to use that "commitment" to death-march the team if it looks like the sprint goal is going to be missed then you have a far more optimistic view of humanity than I do.
• nabla9 3y ago
  My estimate math: R = t × [1.1^ln(n+p) + 1.3^X] R - time it really takes. t - shortest possible time it would take without need to communicate. n - number of people working and involved during the process, both customers and developing organization. p - longest communication distance network involved in the project (typically from the lowest level developer to the end user) X - number of new tools, libraries, techniques, used in the process. Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4. 2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.
  • luibelgo 3y ago
    Out of curiosity, how did you came out with this formula? What’s the math behind it?
    • dsomers 3y ago
      It’s from his butt. Which makes it just as valid as how everyone else does estimates.
    • nabla9 3y ago
      Crude estimate based on some self evident truths: Logarithms for number of people and communication chain come from network theory because network size and network distances slow down information flow. New technologies bring in unexpected delays and problems that rapidly accumulate in nonlinear ways. If bring in 20 people to work with new programming language, new library stack, etc. everything slows down to crawl.
      • 8organicbits 3y ago
        From the other angle, you can see how velocity is impacted by using "boring tech", keeping teams small (two pizza team), clearly identifying stakeholder roles, creating efficient communication channels. It's a pretty useful model.
    • crispyambulance 3y ago
• gherkinnn 3y ago
  The following point has stuck with me for half a year now. > What they actually want is "the earliest date you cannot currently prove to be infeasible" https://news.ycombinator.com/item?id=35318124 https://news.ycombinator.com/item?id=35318124
  • regularfry 3y ago
    That echoes the book Waltzing With Bears, if I'm remembering it right.
• fasteo 3y ago
  1975: Fred Brook's wrote[1]: “The bearing of a child takes nine months, no matter how many women are assigned.” Can't get better than this [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month https://en.wikipedia.org/wiki/The_Mythical_Man-Month
  • stavros 3y ago
    I don't know, I've seen some 10x women do it in seven months, though the deliverable did suffer.
  • weinzierl 3y ago
    But more and more women are working faster. Later preterm rates are on the rise for quite some time. "The late preterm singleton rate rose at an average annual rate of 2% each year from 2014 to 2019 (from 5.67% to 6.32%). The decline in the late preterm rate between 2019 and 2020 (6.32% to 6.30%) was not significant." https://www.cdc.gov/nchs/data/databriefs/db430.pdf https://www.cdc.gov/nchs/data/databriefs/db430.pdf
  • bgribble 3y ago
    I have even smart managers look me in the eye and say things like "can we parallelize parts of this? let's map out the dependencies." EVERY EXTRA PERSON YOU ADD MAKES IT TAKE LONGER. The fastest delivery is a solo developer that you get out of their f**ing way and let them work.
    • deleted 3y ago
      [deleted]
    • datadrivenangel 3y ago
      If you want to go fast, go alone. If you want to go far, go with people.
• paulsutter 3y ago
  The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule
  • bsenftner 3y ago
    This is why Professional Communications is so critical for software developers, and exactly why your manager absolutely does not want you to have such skills: you'll be able to explain why their requests are manipulative, unrealistic, and frankly pointy haired wishful nonsense.
    • geraldwhen 3y ago
      Your workplace may be toxic. My manager celebrates simplification and cost reduction when it solves business problems.
      • bsenftner 3y ago
        Completely different topic. I'm not even referencing "my workplace", I'm talking our entire industry.
        • _a_a_a_ 3y ago
          Please don't generalise or you wipe out the occasional good that does exist.
          • bsenftner 3y ago
            Now seriously, my comment is a call for people to acquire professional communication skills, because they are extremely useful when negotiating work in far too many areas to count. Such advice getting down voted indicates how little value quality communications has within the software developer community - to the industry's demise. Communications are everything, and if you don't have good communication skills you get overlooked, abused, and misunderstood... leading to career frustration, stagnation, and burnout.
• jongjong 3y ago
  Unlike the meteorologist, the developer has the ability to bend reality a bit when it comes to estimates, but they can never bend reality in a way which makes it worthwhile. Cutting corners is almost always a mistake. It's a very short term move which may only make sense if the business is collapsing and looking for a quick exit.
  • smolder 3y ago
    You could spend 15 years cutting every corner imaginable as a self-professed genius 1-man engineering team until everything becomes unsustainable, feature work is impossible due to frequent fires, the business is faltering, and you can't even understand your own code any longer. Then, quit as soon as a new hire comes in so you can't be held accountable for your quagmire by other engineers. I don't really understand why someone would do this, but I recently got to see it first hand. ;)
    • jongjong 3y ago
      Damn 15 years is a long time. I think the oldest ball of unmaintainable spaghetti code I saw was 3 years old and it was almost impossible to add or change anything. None of the developers who worked on it and had the most knowledge of it could explain how it worked, not even at a high level. Like they barely understood it better than non-tech end users.
• jdlyga 3y ago
  At least you get to estimate.
  • mattchamb 3y ago
    We have a deadline and estimates, now all we need are the requirements...
• zubairq 3y ago
  I love these types of posts. Most of my career as a developer felt like being in a bazaar, where the buyer (manager) would constantly be trying to get the price of a carpet down (my work) without ever knowing exactly what type of carpet they wanted, but having a vague idea of a "quality" carpet in their head.
• beardyw 3y ago
  Never reduced an estimate (without change of scope) in my whole career. Didn't do me any harm.
  • praptak 3y ago
    TBH missing estimates also didn't do me any harm. That's why I'm always tempted to agree... and then ignore all pressure to deliver. "Your estimate, your problem"
• ThinkBeat 3y ago
  If developers did not approach projects with the goal of adding acronyms to their resumes and infuse every project with the latest cargo cult du jour it would improve the ability to predict timelines. Pick boring technology, that the team is already comfortable with, when possible. Keep the teams as similar as possible, Keep running projects the same way, when possible I am not saying it will get things perfect, but it will be an improvement.
  • GoToRO 3y ago
    Developers do not choose the tools. Not in agile/scrum companies. Heck, they are not even allowed to choose the variable names by themselves.
    • kaashif 3y ago
      What? That seems like it would vary from company to company. My company does scrum and developers choose which technologies to use, which seems like it's probably common...
  • cityofdelusion 3y ago
    The problem is that developers have a very strong incentive to add new technology to their resume, as their job is not guaranteed. I think most junior devs have seen some old hat at their first real job who codes in one, ancient tech stack; someone that they perceive as un-hirable if the economy takes a turn. We all see the job listings out there and the tech they desire. It is self-preservation, and it is in direct conflict with what is best for the company itself. To use myself as an example: I have zero regrets with pushing for JavaScript over VBScript many years back, for moving from Microsoft HTA to React, or for moving from Yahoo's YUI to jQuery. Being infused with old tech can very severely limit your ability to survive. Most of my interviews after my first job were simply explaining/defending the ancient tech I had specialized in. It is all risk, no reward at the employee level.
• Havoc 3y ago
  Except the meteorologist has no inherent incentive to predict a specific outcome. A dev who will need to deliver against the resulting target deadline has a powerful incentive to overstate. Even more so if they think they’ll subsequently be pushed to revise downwards Rubbish metaphor
• throwaway091ba 3y ago
  Whenever this estimation question comes up, developers rarely put themselves in the shoes of the business side, and try to understand why there needs to be an estimate, and why shorter is always better than longer. What they do instead, is try to protect their holy land of software development, and exacerbate the differences between engineers and "the others" - sarcasm and cynisism usually shine through at this time, and that's how you end up with unrealistic estimations. I've been a developer, PO, manager, director, CTO, the whole thing. I'm still shocked by how most (not all, but most) developers are simply too disconnected from the reality that, yes, they do need to provide value, and yes, that value does have a time factor. Lucky are we as developers, that people actually ASK us how long it will take, and give us the opportunity to explain it, push back, and actually defend your estimates. The sad reality (at least from 90% of my career), is that developers are rarely able to actually engage in business-level conversations, and actually express their thoughts/ideas/concerns/proposals, in a way that it drives the conversation forward. In a way that helps PMs and managers actually see the complexities of the work, and engage in healthy cost/benefit discussions.
  • verve_rat 3y ago
    I agree with all the points you've made, but I would add that the PMs and managers and directors and whatnot are never that keen to help engineers out on this front. It is a rare person indeed that can do software development and think (and talk) in business terms. As a dev, being able to talk in business terms about the problems you face in creating software is really, really handy. But I can count on one hand the number of POs, directors, managers that want to engage in that conversation with developers. Most of the time a solution is thrown over the wall and developers are told to build a thing. An actual conversation about a business problem between the people that actually have the problem and the people that will build the software that (hopefully) solves it happens way, way less often than it should.
    • WJW 3y ago
      In addition, any actual conversation wouldn't just require devs that can talk in business terms but also business people that can talk in development terms. Otherwise the only territory that can be usefully covered by both parties are the business requirements and the outcome will almost always be biased towards that.
• GoToRO 3y ago
  If you ask for a lower estimate it means that you are providing an estimate. Why people that are not qualified to estimate, scum masters, team leads, product owners, provide estimates? The whole management structure is upside-down and then we wonder why software is crap and people quit.
• tyingq 3y ago
  Dev teams have choices though. They can choose to use existing 3rd party code, services, etc, to accelerate development or not. They can choose some amount of non-functional requirements. They can choose the amount of "future proofing", abstraction, etc. And on and on...many choices that would drive timelines, trade speed for quality, longevity, maintainability, or cost, and so on.
  • danaris 3y ago
    But unless that 3rd party code, and those services, have already been discovered, evaluated, and learned by that particular dev team, integrating them might take more time than building something from scratch that meets the specific requirements at hand. And if it's built in-house, that means that in addition to being much more tailored to the organization's needs, it can be much more easily changed as those needs evolve. This doesn't mean that I think it's always better to roll your own, of course; there are lots of instances where that counts as "reinventing the wheel." But it's absolutely not as simple as "just use something that's already out there and it will be faster and work just as well."
    • tyingq 3y ago
      I wasn't suggesting that example was a magic bullet. Just that it is one of many choices that drive an estimate...down OR up. I agree there are cases where 3rd party software doesn't help. I think it would be pretty rare for a team to have zero choices in their control that would change an estimate.
    • jeltz 3y ago
      Quite often using third party tools take longer time but still are worth it in the long term due yo lower maintaisnce and generally simpler tech stack.
• nmstoker 3y ago
  I get the point, and with irresponsible parties (as is fairly widespread in most companies) there's a real risk here. However the analogy of a meteorologist seems poor as that job is focused on predicting the weather - the typical dev is focused on operating in that weather and comparatively inexperienced in predicting with great accuracy. What's frustrating as a stakeholder is ludicrous estimates, which don't even start with the work time, let alone end up with a realistic duration. This is particularly true (and frustrating) at the micro task level, an area I'm often requiring items that take at most 30 minute to complete and are usually things I could do in less time if only I had access... You get a weeks long estimate back, even when it's incurring a serious cost in production and falls in the drop everything category (which obviously one wants to avoid but does come up). I get that none of those 30 minute tasks will take 30 minute alone as there's testing and documentation to add but the more bs level the estimate, the more it damages the trust relationship.
  • Aeolun 3y ago
    To some extend, but there’s tasks that I could do in 30m in a company with 15 employees that I have still not accomplished after 2 months in our 15k employee enterprise.
    • wkat4242 3y ago
      This so so much. Some tasks take me 10 minutes but it takes me half a day to jump through all the hoops that our colleagues have thrown up. Excel approval sheets, annoying proxies with SSL inspection (try configuring all that in multiple docker containers), having no access to actually configure what I need to do so I constantly have to put in tickets to other teams.. The worst thing is when they then outsource the work and ask us why they can do it so much faster.... :X
    • briHass 3y ago
      Large orgs almost become like a bloated government in that way: groups start to construct little fiefdoms with rules and policies that are ostensibly constructed to improve quality. However, those rules end up becoming bludgeoning tools used by nefarious actors in those groups. The real problem is that nobody ever steps back and asks: are all these rules actually helping to improve quality of the software. Is the cost of the reduced velocity and overhead actually worth it in the end. Then, the org does layoffs and all that policy is still in place without the necessary people to supported the bloated workflow.
• Sprinterra 3y ago
  [dead]
• smcleod 3y ago
  Estimates are just that - estimates. More importantly they’re estimates of effort - not of time. If you estimate in time you’re tracking time over time and as such not your ability to estimate time. Estimating within the team should be for the team, not for the business (directly).
• dbalatero 3y ago
  I think the biggest challenge I have is that people will immediately ask for estimates when the project is barely a paragraph description. On top of that, my feeling is always "it depends on how much tech debt is in the code after I look in there." The only reasonable response I've had is "I need 1-2 days to both push you on solidifying these requirements, and stop & audit the codebase to look for any risks before starting". Is there anything I could be doing better here?
  • coldtea 3y ago
    >Is there anything I could be doing better here? Yes. Not give a fuck about the code debt and quality, and just rush out something that barely works. That will keep them satisfied.
    • paulryanrogers 3y ago
      Having built a few of these and inherited a few, please don't. They become brittle and future changes become increasingly difficult, until velocity grinds to a halt. Then you're just firefighting constantly. My guess is there is a happy medium between never changing and staying on the cutting edge. A place where you can ride the current of tech, FOSS, dev communities and talent pools. If course what this looks like day to day and in pointing poker will vary. Ideally there is a seasoned architect on every team who can steer the biggest decisions away from the hazards.
      • kayodelycaon 3y ago
        The goal is to leave the company before this becomes your problem. ;) I say this as the person who gets hired to fix things after they left.
  • gemstones 3y ago
    I have found success with having a session with the PM where the goal is not to have complete, perfect cards, but at least one ticket for every thing you can think you will need to do on the project. So you’ll have a bunch of one liner cards, but at smaller fidelity, like - Make a bulk create API endpoint - Migrate data from old to new table Then, if there are 5 or more cards there, make your estimate ((number_of_cards / number_of_devs) * est_business_days_per_card) + est_pto_days It will not be accurate - but it will leave the PM and their boss feeling like the estimate was thought out and reasonable at the time, and any necessary delays will go over easier (“we estimated assuming every card was about the same number of days, but these two cards were large outliers that took longer than expected.”) Much like the normal sprint process, but without the need to keep a track of sprint velocity beyond a gut feel.
• gregoriol 3y ago
  This metaphor is wrong: meteorologists don't have any impact on the sunshine, whereas devs have direct impact on estimates. In both cases, wrong estimates will generate problems for the stakeholders, but devs can make choices during the implementation that will influence the outcome and may in some ways mitigate the lower estimates, but meteorologists won't ever have any influence on the weather.
• chiefalchemist 3y ago
  I wish we could somehow get away from estimates where the expectation is precision and instead talk about a spectrum of possibilities (i.e., best case, worst case, and points in between). As the journey to the destination gets longer and more complex the range of possibilities increases. Why do we continue to pretend otherwise? That aside, more accurate running scoring (if you will) would also help. Engineering is asked for an estimate but engineering knows that they don't have absolute complete control end to end of everything. Someone else somewhere along the line is going to cause delays, but the estimate stays fixed and engineering remains accountable. That's not helpful in the short term or long.
• hoosieree 3y ago
  Typical action movie hacking scene: Leader: How long until you can hack the mainframe? Techie: The other hacker is really good; at least 2 hours. Leader: You have 1. Get it done! [commence flying around the 3d filesystem] Whenever I watch a scene like this, I mentally add a voiceover for the techie: [Techie thinks]: My actual estimate was 20 minutes. I can probably get it done in about 50, then I need to fly in the 3d filesystem for 10 more minutes looking busy so Leader doesn't get any big ideas.
  • zargon 3y ago
    https://wiki.c2.com/?ScottyFactor https://wiki.c2.com/?ScottyFactor
    • hoosieree 3y ago
      C2 has an article for everything!
• BurningFrog 3y ago
  So happy to work without estimates for decades. We just work on our tasks until they're done.
• ResearchCode 3y ago
  Why are you pushing software engineers for "estimates"? You don't ask mathematicians how long that conjecture will take to prove. It's done when it's done.
  • andyjohnson0 3y ago
    Because developing software is almost always an economic activity, and proving maths conjectures almost always isn't.
    • ResearchCode 3y ago
      There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying.
      • andyjohnson0 3y ago
        > There is no evidence that you get better economic outcomes from micromanaging software engineers, and not for the lack of trying. Thats not really the point that my reply was addressing. Software production almost always takes place within a wider context of economic activity: product launch activities need to be scheduled, server capacity needs to be provisioned, hardware needs to be produced and assembled, people need to be paid out of budgets, etc. I'm a dev and I hate being micromanaged, but usually people really do need to know when the code will be done. Not so much for mathematicians proving conjectures. Which is nice for them. I guess.
        • ResearchCode 3y ago
          That's yearly planning. If estimation means giving your best effort to complete a project over the next year then that's not a problem. When you start micromanaging on a biweekly basis with daily status updates then it becomes a real problem.
          • NegativeK 3y ago
• dtgriscom 3y ago
  My manager once gave me a succinct method for accurately estimating project times: 1. List all the necessary tasks 2. Estimate the time for each task 3. Add up all the times 4. Multiply by π If using unknown technology, that last step should be "multiple by π^2".
• steveBK123 3y ago
  The correct conversation is "what can we remove / what can I do / what can we re-prioritized / what else is in the way" to get some version of this ask earlier. Simply bullying for a lower estimate, which is what I see 90% of the time is idiotic. Basically demanding to be negatively surprised later when the estimate slips rather than positive surprised when the dev is able to beat their initial estimate. The first conversation requires empathy while the second conversation is a pure power flex. So it is unsurprising which we get more of.
• zoomablemind 3y ago
  Pushing for lower estimates is generally a sign of dysfunctional project manager. This is when the PM does not have practical knowledge of existing obstacles to the project flow or the implications of external dependencies (intra team included). This is a set up for throwing the team under the bus in case the schedule derails. PM is supposed to harmonize the objectives and abilities, not manufacture the curves.
• jalapenos 3y ago
  It's more Machiavellian than that. What the middleman wants is a heads I win, tails you lose deal. He wants to present a low number, to encourage whoever he's dealing with on his end to do what he wants, gaining the benefit from that. So he'll use every technique under the sun to encourage devs to give him a number he likes more, while never making it look like an order or coercion (which would make it his number - spoiling the whole play). But when it inevitably takes much longer, he can point at the numbers the devs provided and say he was just communicating what they told him, so he's not responsible. The only language these types understand is for requests for estimates to be "reviewed" to result in them always going up, to send a message.
  • black_13 3y ago
    [dead]
  • epolanski 3y ago
    I swear I hate this estimates thing so hard. For many reasons: 1) Estimations should be useful so business can adapt. In reality there's no adaptation of any sort, your PM will get the stick from its own boss that stuff needs to be ready by this or that more-or-less vague deadline. Thus, what am I estimating for if you don't care about my estimation anyway? 2) There are no incentives for teams ultimately to estimate anything realistically. What do you get for being accurate? A medal? In fact, all incentives go towards inflating the amount of work through estimates. 3) Ultimately all this dancing of estimates and rituals is nothing else but stuff that management embraces to appear more effectful and impactful than it really is.
    • jalapenos 3y ago
      Most impressive statement I ever heard said in a meeting between management and engineers about a project's progress was a long-tenured dev saying "it'll be done when it's done", followed by silence, and then they let it be. To this day I still don't know how this event came to pass.
    • replyifuagree 3y ago
      Yeah if you estimate realistically many companies have a culture that will punish you for not being a team player.
• jvans 3y ago
  The problem is not with estimates themselves, but on giving point estimates. A better way of saying something will take 2 weeks, is that there's a 80% chance this takes less than weeks, 15% chance it takes 2-4 weeks and 5% chance 4+. But people have a hard time wrestling with uncertainty so they'd rather a point estimate that's wrong but makes them feel like they understand the situation
• fuzzfactor 3y ago
  More like a clueless "leader" demanding an earlier sunrise. If he's going to want an earlier sunrise, he's going to need to shave off a good portion of the still-dark Earth that's standing in the way and he's going to need to get it done before dawn. The team can do their part after that.
• corry 3y ago
  “Pushing sales people to increase their amount of sales/quota is like asking meteorologists for sunshine”. Hmmm it doesn’t seem unreasonable in that context? You’re really asking people to work more effectively, to accomplish the same amount of work more quickly. It’s like asking sales people what their quota should be. They pick a number that is no-brainer hittable, because there is a lot of complexity and many unknown variables in getting deals signed, so to prevent looking bad they’ll pad their number. But their no-brainer number is below what the business needs. So you tell them their quota is going to be a bit higher. They’ll have to stretch to hit it. And it’s even MORE important since their comp is DIRECTLY tied to hitting that number. And yet sales people aren’t writing article after article about how self-set quotas are sacrosanct, should only settable by sales people themselves, and how clueless management is to try to get more performance above the no-brainer target.
  • lukevp 3y ago
    Isn’t sales a numbers game for the most part? Like you can convert 10% of leads, so if I need 5 conversions instead of 4, I need to call ~10 more people? A better comparison to software I think would be construction of a novel building. Try constructing a geodesic dome house with no experience, and little knowledge of the issues you might run into, but then you’re asked for accurate estimates and then pressured to shorten them.
    • paulddraper 3y ago
      > I need to call ~10 more people? I need to write 10 more lines, code for 10 for minutes, etc.
      • replyifuagree 3y ago
        Maybe bonus developers on lines of code written? Or my personal favorite, bugs fixed! https://devhumor.com/media/dilbert-s-team-writes-a-minivan https://devhumor.com/media/dilbert-s-team-writes-a-minivan
      • lelandbatey 3y ago
• Spooky23 3y ago
  This isn’t going to be a popular take, but this is just wrong. Developers will often plan out a cathedral when what’s needed is a garage. Usually this is due to a misunderstanding of the requirements, or an inability of the requestor to formulate or express them. Also, developers are notoriously bad at forecasting work product and the numbers they deliver usually have a tenuous link to reality. The conversation that starts with “We don’t have 6 months, how do we deliver this by 12/31?” is ultimately a hashing out of what the requirements are. When it’s a cool tech driven story, we call it “an MVP”. When it’s driven by the business, the author considers it yelling at the weatherman.
• deleted 3y ago
  [deleted]
• charles_f 3y ago
  Sorry to be a stickler but this is a heavy editorialization of the title. The original title is "Someone saying 'No, it's less effort than that!'?". The current HN title isn't even a proper quote of the article, the quote is > Pushing for a lower estimate is like negotiating better weather with the meteorologist!
• riazrizvi 3y ago
  Sometimes. Or the estimator is fixated on an extent of scope/depth that is not intended by the stakeholders at the initial stage. Or sometimes the estimator is baking in extra time that will get filled whether or not it’s necessary.
• 23B1 3y ago
  My favorite bit of this argument is the presumption of honesty, accuracy, or transparency on the part of developers. Someone in the estimation process is always protecting themselves, packing on a little margin, or fudging the numbers. It's nothing to get upset about, it's just normal human behavior, happens in all industries. For this reason alone, I always kick estimates back down and amazingly they almost always come back better-optimized – usually because some trusted graybeard engineer, who has been on both 'sides' of the business, steps in and cleans it up based on his experience.
• justin_oaks 3y ago
  Estimates aren't deadlines. If we're talking estimates then we should also talk about accuracy and precision. I can give a low estimate if you're ok understanding that it's not a deadline and that is has astonishing low accuracy. Estimates indicate that there's a probability that the time required could be more OR less. Choosing the deadline to be exactly the same as the estimate is ignoring the probability that the the task will take longer.
• camhart 3y ago
  I disagree. Engineers have a habit of over engineering. Businesses have a habit of introducing too much process, too many meetings, too many layers between the end user and the engineer building. A lot can be done most of the time to help devs optimize to deliver quickly. However, most businesses get stuck in their ways, struggle to give sufficient autonomy, and... sometimes get burned by giving too much to a dev when they aren't yet ready for it. In short, getting efficiency "right" is a balancing act, and each "story" could be unique which makes it difficult to balance well consistently. In my experience, don't get too caught up with estimates. Devs do need goals (even artificial ones) to help focus effort and prevent too much "bad" distraction (sometimes distraction is exactly what they need though--stepping away from the problem for some amount of time can help them look at it differently). Give estimates. Motivate with goals. Build a real team environment where delivering is contagious. Its actually much harder to do than say, and I'd guess many devs have never experienced this before.
  • charles_f 3y ago
    > Engineers have a habit of over engineering Developers have one. It's in most academic definition of engineering that the job is to produce the cheapest design that will do the job safely. Devs also have a habit of underestimating, which puts them under pressure once the date has came and gone.
• charles_f 3y ago
  I link with the article, I usually call predictions a forecast, and not estimates, because you don't get angry at a meteorologist. I have produced estimates for almost 20y now, and boy do I hate that. There's multiple layers to it. This post touches the nefarious one. Sometimes yes, someone wishes something would come sooner and will shake the tree to see what happens. Sometimes there's actually a reason for it - be it budget, customer related, event related, etc. Sometimes someone knows better, because the feature or project is similar to another that was shorter. When someone discusses estimates with an underlying motive other than their experience and surprise at the cost, I usually enter a discussion where I produce the evidence for our numbers and justify what we are telling. It highly depends on why we produce estimates in the first place. If it's for budget or planning, I couldn't care less to reduce estimate, since these exercises are pointless in nature in my experience (the budget or planning is usually rendered moot within weeks of being approved). If its to predict delivery dates, I'm usually very conservative, note that I am not in the art of divination, and that reducing estimates is a risk in itself if anything bad happens. When people are acting on bad faith, documenting stuff usually tames things a little. Unless things are very simple and predictable, I also usually provide several dates with confidence indices. This is a framework that's much harder to negotiate, and give some information to whomever "needs" those dates. It helps reducing the pressure a bit while being non committal and leaving room for error (and I never give a 100% confidence). TBH, I don't think I've ever been in trouble for "being late", especially because I have always been able to explain that we weren't late, we just gave an incorrect date in the first place.
• piinbinary 3y ago
  I agree: https://jeremymikkola.com/posts/2021_10_11_weather_and_estimates.html https://jeremymikkola.com/posts/2021_10_11_weather_and_estim...
• dasil003 3y ago
  This article is extremely weak, pandering to engineers beset by clueless pointy-hair antics, without acknowledging that engineers can suffer from their own blind spots, regardless of whether stakeholders have the technical background to understand it or not. The elephant in the room is this: a team can not produce good work without both competence and trust in equal measure. An immature engineer may assume a business stakeholder is dumb because they don't understand or engage on technical details, an immature business stakeholder may assume that pressure and threats can yield quality work. In both cases, the immature individuals are putting their energy into counter-productive hand-wringing. But now here's where it gets hard: trust can't be blind and incompetence exists. The straw man analogy that content of estimates are somehow immutable and unavoidable facts like the weather demonstrates an incredible lack of agency and resourcefulness. We are talking about humans working together to solve problems and build things, we have incredible latitude on how we want to approach things. This viewpoint reeks of learned helplessness. Look at the proposed solutions: > In these cases, discuss with your stakeholders: why the estimated effort is this much? what part of the story takes the most time? where are the biggest unknowns? In addition, discuss ways to: slice up the story and deliver it in multiple parts, validate each part early, preferably using prototypes Do you see the assumed constraint? There is no discussion of the problem to be solved or job to be done. Often in these cases you have a non-technical person prescribing a solution that doesn't make sense. If that's the case, it can only be solved by an engineer who has communication skills and credibility to discuss a better approach to the problem. Assuming that a user story passed down to the team is somehow sacrosanct is the type of process-oriented dysfunction that tanks morale and leads to impotent teams.
  • mardifoufs 3y ago
    Oh my god thank you. Software engineering seems to be the only field where it seems like these types of super weird arguments about being too special or unique to follow or apply any business process are common, coupled with a vibe of "we are way smarter than everyone else". Why are these people surprised that other stakeholders won't just accept a "trust me bro, it's ready when it's ready you just have to go with it" when nothing else works like that in the business world.
• smokel 3y ago
  I'm sometimes a bit ashamed of the IT sector as a whole. I have been programming professionally for more than 20 years, but I have not seen much improvement in time to delivery. For each step forward, we seem to be taking two steps back. I can't blame the developers, but I wonder who to blame instead. The first suspect is: the internet. It may seem like a great invention, but having machines connected at all times, without formal restrictions, results in terrible security problems. Which have to be fixed. Which takes enormous amounts of time. The second one is related to that, and that is the idea that we have to continuously upgrade everything to the latest fad. As one consequence, we are somehow stuck with a weird common ground for user interfaces defined by web browsers, which leads to overly complex software. What most people often want is just a push button to send a message to some other system. Both companies and governments alike seem to be paying billions of dollars for that. Because it is all so extremely complex, and people are somehow buying that. My understanding is that the industry is happy making a lot of money, so there could be limited incentive to change things for the better. However, for some other odd reason, most ordinary people try to avoid technology like the plague, and pride themselves in not understanding how computers work, yet unknowingly spend a big percentage of their tax money on exactly that lack of understanding. I am still extremely thankful for the likes of Richard Stallman for starting the free software movement. Unfortunately, delivering software is only one (small) part of the problem. Embedding computers in human processes is a whole different ballgame. Can we perhaps have some kind of "free management foundation" as well? I actually reread the above rant, and I fear for the downvotes, but perhaps someone understands what I am on about and has a good tip to ease my mind.
  • alanfranz 3y ago
    > but I have not seen much improvement in time to delivery. Is this true, by the way, or it’s just our hedonistic treadmill? Nowadays it’s extra fast to deliver and serve a lot of functionalities worldwide. Thing that would require a dev team are handled by a free saas out of the box. But our implied non-functional requirements have grown exponentially. Twenty years ago, if a business critical software was offline for one day a month, it wasn’t a big issue. Today, if Facebook is offline for an hour it’ll make headlines on major newspapers. Expectations just evolved. And writing working software over multiple layers of mess is as difficult as ever. “Precise estimation” is just a misnomer.
• mumblemumble 3y ago
  I think that it might even be worse than asking a meteorologist for sunshine. Because asking a meteorologist for sunshine has no conceivable influence on the weather, but putting a thumb on the estimation process can absolutely alter the design of the system. And that, in turn, can alter the overall effort and delivery date. Whether the influence is positive or negative seems to depend a lot on the details of how you do it. I think, though, that the Extreme Programming community was on to something when they suggested that demanding more meticulous up-front technical design invites overengineering and ultimately makes things take longer. Unfortunately, that's often what happens when managers directly push back on estimates. I would advocate for something more like a feedback cycle: at the end of every milestone or iteration, the team should compare how long work actually took to their estimates, and discuss the factors that may (or may not!) have contributed to any severe under- or overestimate. That process should improve the quality of estimates over time, and help the team to get better at focusing on the important factors in producing a quality estimate. And it will improve trust, too - I've noticed that it's common for teams that don't do something like this to bicker over estimates rather than collaborating on them. And then, with all that established, it finally becomes possible for the team to reliably focus attention on the only way to actually reduce development costs without cutting corners: scope management and negotiation.
• theptip 3y ago
  I dislike the framing here, it disempowers the team and sets up a hostile lens towards stakeholders. As the product team, you are in general optimizing between quality, scope, and timeline. Pick values for two, the other one will be determined. So if a stakeholder communicates a timeline constraint, you can work with them to achieve it by cutting quality or scope. For example if the urgency is that they need to give a customer demo, maybe a moving skeleton prototype, or at least delivering an iteration without all the integration tests would be appropriate (quality). Or maybe you can chop the deliverable into two milestones and ship the features they urgently need sooner (scope). I acknowledge that in some cases there is just an asshole who doesn’t know what they are talking about, trying to inject urgency. But in many cases, if you actually empathize with the stakeholder and try to figure out what they are really communicating, you can find the underlying issue and modify your deliverables accordingly. This is what it looks like to be a high-performing team. The idea that the timeline is out of your control is asinine, and will make stakeholders distrustful, since the idea is obviously nonsense (or if it’s true, the team is adrift). I strongly advise you to never use this language or philosophy in your stakeholder interactions.
  • pfsalter 3y ago
    Completely agree, the article reads more like someone who thinks they are doing research rather than development. There's no esoteric perfect form for software that needs to be discovered, there's a set of patterns and structures that can be learned before the project starts. Analogies are often unhelpful because people argue about the analogies instead of the actual problem at hand. If you can't communicate why these things are hard, and why 'do it faster' won't always get results, you need to get better at dev management.
• Too 3y ago
  Did anyone ever get asked to simply make the estimate lower? Without any other context? That never happened to me, it sounds extremely immature. Feedback that you don’t agree with the estimate on the other hand, happens all the time. This is a completely different thing than a hollow request for “lower plx”. Good stakeholders often do have a good idea of how long time things take. Maybe they worked as dev before, or with other clients. Leaving the estimation exclusively for the well oiled hero-team with perfectly calibrated velocity and ponies coming out of their retrospectives, as the article portrays it, isn’t always ideal either. Some tasks are new and unknown to them too, and honestly not all teams are that perfect. There needs to be a two-way dialogue about scope contra timing.
  • pc86 3y ago
    TLDR - Yes, but from a crazy person. Yes, in the most toxic place I ever worked. Gee, those are probably related, huh? The owner of the company was crazy. Not in a hyperbolic "oh yeah she's nuts" way but in a "she's either taken too much medication or not enough because she's unstable." Some of my favorite anecdotes, starting with one relevant to your comment: 1. After I provided an estimate of N weeks for a project, her response was "no it needs to be done faster than that." Okay, what features do you want to remove? What can be added after launch? "Everything is critically important and has to be available at launch, I thought it would take a day or two not weeks!" Finally she just wrote something about 80% of my original estimate and moved on. It took a week or two longer than I had originally estimated and it was fine. 2. Insisted on charging $10 instead of $9.99 because "the taxes get too complicated." Turns out rather than just using billing software like any sane person ca. 2010, she was using a calculator on her desk to figure out what clients owed and just typing that into an invoice and sending it. I bet 90% of our clients either overpaid or underpaid basically every bill by 1 cent due to her rounding in her head. 3. My favorite one ever was she was out on vacation one week, and while she was out we had some production issue over the course of a day and a half or so that was eventually resolved but she was cc'd on everything as she insisted. She pops into my office her first day back at like 8AM and says "I saw $THING wasn't working last week, everything's good now?" Yup. "Okay thanks!" and left. Comes in a few more times asking about $THING over the next hour, kind of weird but not unusual. Runs into my office frantic right before lunch "John Doe just emailed me, $THING is down!" Turns out she was just reading her Outlook top to bottom, so was gradually reading earlier and earlier emails. So in her mind $THING was totally fine and gradually slid into chaos as she read older and older emails. That was an exciting few years, I have to say.
• ghusto 3y ago
  > Next time, when someone starts a conversation about your team's estimate, pushing for a lower estimate without any new insights that will lower the effort, ask them: do you ever tell the meteorologist it isn't going to be this bad weather tomorrow? I'm more direct. I ask them why. As in "why do you think it's less work / time / effort?". Every single time they've realised it's not less, they just _want_ it to be less.
• deleted 3y ago
  [deleted]
• tasuki 3y ago
  I don't get the meteorologist analogy: The meteorologist does not create the weather. The software development team does create the software. Also weather is (somewhat) possible to predict. In software, the unknown unknowns are a problem, so all estimates are basically bullshit.
• deanCommie 3y ago
  Engineers have been burnt by too many ex-engineer PM's who haven't coded in 20 years, but push back against estimates by claiming "I could've implemented this in Perl in 2 hours. How can it be 2 weeks!?!" So it depends on who's saying "no, it's less effort than that". Often I come to my engineers and say "No, it's less effort than that" because I know "You've never done this before, and you're buffering for the unknown. But actually one part of this can be reused from <module> and you can get this other part from <existing service>". I share the context, the engineers go "oh cool", and update the estimate. And just as often I come to my managers (people and product) and say the opposite - "No, it's more effort than that" because I know what other things the devs are working on that are not visible to the PMs, what scaling cliff they're stopping us from going over, or that the PM's t-shirt size is not including automation, testing, infrastructure, scaling, etc.