9 ms·

Estimates are difficult for developers and product owners

• th0ma5 11mo ago
  It's a shame that developers read these articles and not project managers.
• based2 11mo ago
  https://en.wikipedia.org/wiki/Delphi_method https://en.wikipedia.org/wiki/Delphi_method > https://news.ycombinator.com/item?id=26368011 https://news.ycombinator.com/item?id=26368011 https://blog.pragmaticengineer.com/yes-you-should-estimate/ https://blog.pragmaticengineer.com/yes-you-should-estimate/ > https://news.ycombinator.com/item?id=27006853 https://news.ycombinator.com/item?id=27006853 https://josephmate.github.io/PowersOf2/ https://josephmate.github.io/PowersOf2/ Complexity Estimator https://earthly.dev/blog/thought-leaders/ https://earthly.dev/blog/thought-leaders/ > https://news.ycombinator.com/item?id=27467999 https://news.ycombinator.com/item?id=27467999 https://jacobian.org/2021/may/20/estimation/ https://jacobian.org/2021/may/20/estimation/ > https://news.ycombinator.com/item?id=27687265 https://news.ycombinator.com/item?id=27687265 https://tomrussell.co.uk/writing/2021/07/19/estimating-large-scale-software-projects.html https://tomrussell.co.uk/writing/2021/07/19/estimating-large... > https://news.ycombinator.com/item?id=27906886 https://news.ycombinator.com/item?id=27906886 https://www.scalablepath.com/blog/software-project-estimation/ https://www.scalablepath.com/blog/software-project-estimatio... https://estinator.dk/ https://estinator.dk/ > https://news.ycombinator.com/item?id=28104934 https://news.ycombinator.com/item?id=28104934 https://news.ycombinator.com/item?id=28662856 https://news.ycombinator.com/item?id=28662856 How do you do estimates in 2021? https://web.archive.org/web/20170603123809/http://www.tuicool.com:80/articles/7niyym https://web.archive.org/web/20170603123809/http://www.tuicoo... Always Multiply Your Estimates by π > https://news.ycombinator.com/item?id=28667174 https://news.ycombinator.com/item?id=28667174 https://lucasfcosta.com/2021/09/20/monte-carlo-forecasts.html https://lucasfcosta.com/2021/09/20/monte-carlo-forecasts.htm... > https://news.ycombinator.com/item?id=28769331 https://news.ycombinator.com/item?id=28769331 https://tinkeredthinking.com/index.php?id=833 https://tinkeredthinking.com/index.php?id=833 > https://news.ycombinator.com/item?id=28955154 https://news.ycombinator.com/item?id=28955154 https://blog.abhi.se/on-impact-effort-prioritization https://blog.abhi.se/on-impact-effort-prioritization > https://news.ycombinator.com/item?id=28979210 https://news.ycombinator.com/item?id=28979210 https://www.shubhro.com/2022/01/30/hacks-engineering-estimates/ https://www.shubhro.com/2022/01/30/hacks-engineering-estimat... https://www.paepper.com/blog/posts/monte-carlo-for-better-time-estimates-of-your-work/ https://www.paepper.com/blog/posts/monte-carlo-for-better-ti... https://drmaciver.substack.com/p/task-estimation-101 https://drmaciver.substack.com/p/task-estimation-101 > https://news.ycombinator.com/item?id=32177425 https://news.ycombinator.com/item?id=32177425 https://morris.github.io/e7/#?t= https://morris.github.io/e7/#?t= https://stevemcconnell.com/17-theses-software-estimation-expanded/ https://stevemcconnell.com/17-theses-software-estimation-exp... https://www.doomcheck.com/ https://www.doomcheck.com/ > https://news.ycombinator.com/item?id=34440872 https://news.ycombinator.com/item?id=34440872 https://github.com/kimmobrunfeldt/git-hours https://github.com/kimmobrunfeldt/git-hours https://pm.stackexchange.com/questions/34768/why-are-developers-expected-to-estimate-tasks-at-all https://pm.stackexchange.com/questions/34768/why-are-develop... > https://news.ycombinator.com/item?id=35316808 https://news.ycombinator.com/item?id=35316808 https://erikbern.com/2019/04/15/why-software-projects-take-longer-than-you-think-a-statistical-model.html https://erikbern.com/2019/04/15/why-software-projects-take-l... > https://news.ycombinator.com/item?id=36720573 https://news.ycombinator.com/item?id=36720573 https://news.ycombinator.com/item?id=42173575 https://news.ycombinator.com/item?id=42173575 https://www.thecaringtechie.com/p/8-guaranteed-ways-to-annoy-your-senior https://www.thecaringtechie.com/p/8-guaranteed-ways-to-annoy... > https://news.ycombinator.com/item?id=43146871 https://news.ycombinator.com/item?id=43146871 https://news.ycombinator.com/item?id=43873604 https://news.ycombinator.com/item?id=43873604
  • teddyh 11mo ago
    <https://www.joelonsoftware.com/2000/03/29/painless-software-schedules/ https://www.joelonsoftware.com/2000/03/29/painless-software-...>
    • truelson 11mo ago
      I preffered: https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/ https://www.joelonsoftware.com/2007/10/26/evidence-based-sch... 20-25 years later, this is still where we are at :)
      • truelson 11mo ago
        "Evidence-based" stats tracking is the only somewhat scientific method i know of that can give you a good range of estimates. But it takes effort. Thus why many don't do it. But accurate estimate ranges are a super-power for businesses if they can trust them. Never understood why that's not demanded more... oh yeah, it's work :p
• vb-8448 11mo ago
  In my experience, most of the time estimates are difficult because prerequisites and constraints are not clear or not fully known. But, if you are enough experienced, with some fermi-style math, you will do good enough estimates most of the time.
  • skydhash 11mo ago
    Giving an estimate is not hard and shouldn't be a pain if if was truly an "estimate" PMs were asking for. But after a while you learn that when they say "What's the estimate for feature F?", they're in fact saying "What deadline you wish to impose on yourself for feature F?". Then the next interaction is most likely to be "Are you done yet?" and not "Is the estimate holding up?".
• csours 11mo ago
  I largely agree. Another way to say this is that an estimate becomes a commitment to not learn. Re-planning is seen as failure by [management]. Re-planning is what happens when you learn that a previous assumption was not correct. You should be encouraging learning, as this is THE cornerstone of software development.
  • ravenstine 11mo ago
    Re-planning in isolation is not a failure. I think re-planning is a failure when nothing is learned from previous assumptions not being correct, which usually leads to serial re-planning. I've seen this pattern form at practically every company I've worked for, in particular whenever there's a merger or a private equity buy-out. More often than not, this is ironically caused by leadership failing to learn from previous assumptions because they're too busy chasing the shiny new bobble of the week, but the blame still gets diffused across the organization.
    • csours 11mo ago
      > I think re-planning is a failure when nothing is learned from previous assumptions not being correct This is the exact problem, and why it is so extremely difficult to communicate about the subject. Another way to say "learn from previous [failures]" is "bureaucracy". We did something wrong last time, so we need a rule about that failure. It SHOULD NOT be seen as failure, we SHOULD NOT add bureaucracy, simple rules CAN NOT fix the issue. What should happen: Line managers and developers should be able to communicate about what they are learning as they do the work of software engineering. Developers should be able to re-plan their approach to problem solutions. This simply will not work if there is not strong trust between upper management/[the money] and the engineering/execution side of the organization. ---- The meta-problem is that you have to see things go wrong many times in many ways before you really understand what is going on, and by that point ... well everything gets very tiresome.
  • Bjartr 11mo ago
    When you make a plan, you have the least information you will ever have about the goal/problem.
• deleted 11mo ago
  [deleted]
• js8 11mo ago
  What the article suggests is basically Kanban. It's the most effective SW development method, and similar scheduling system (dispatch queue) is used by operating systems in computers. However, management doesn't want Kanban, because they want to promise things to customers. You can make good estimates, but it takes extra time researching and planning. So you will spend cycles estimating instead of maximizing throughput, and to reduce risk, plan is usually padded up so you lose extra time there according to the Parkinson's law. IME a (big) SW company prefers to spend all these cycles, even though technically it is irrational (that's why we don't do it in the operating systems).
  • namdnay 11mo ago
    > technically it is irrational Only if your company operates in a vacuum, without investors or customers
    • poguemahoney 11mo ago
      As an investor, I don't like a investment that throws away 10-30% of its resources, perpetually lowers morale except among the least creative and misses opportunities because their competition is faster.
    • js8 11mo ago
      Investing or buying into something new and unknown is by itself not a rational act (to the extent the thing is novel). IMHO rationality (optimization) only makes sense relative to a well-defined goal.
  • greenchair 11mo ago
    Another reason kanban doesn't work for large projects is because you have to coordinate your cycles with multiple dependencies teams roadmaps and releases.
    • js8 11mo ago
      I don't think so, only if they need to have a schedule as well. Most OSS projects operate as Kanban and it's just fine. Waiting on a dependency is kinda like waiting on a lock held by another process in the operating system. It has little bearing on whether dispatch queue is effective or not; in fact, it shows the solution: Do something else instead of waiting. (This is why the OS analogy is so useful for project management, if only PM's would listen!) It's again, if you need to plan things ahead (for some reason) when the dependencies become a problem. But maybe I misunderstand what you mean, if you still disagree provide a more specific example.
• codingdave 11mo ago
  This is why I push for Kanban whenever I am a PO. If we can ballpark an estimate, I can prioritize it. If we cannot ballpark an estimate, I can prioritize the research to clear out some of the unknowns. But most importantly, we set an expectation of rolling feature rollouts, not inflexible release dates. We communicate both internally and externally the next few things we are working on, but no hard dates. The article correctly identifies that hard release dates communicated to customers are the root cause of problems, so I simply don't give such things out.
  • awesome_dude 11mo ago
    Sorry, but how does Kanban come into this? From your description, SCRUM, could work just as equally. Don't get me wrong, I'm a fan of Kanban, it's awesome for visually presenting where bottlenecks are for tasks, but estimations aren't a feature of that. But SCRUM maybe, where people are having a sprint planning meeting maybe more what you're thinking?
    • deleted 11mo ago
      [deleted]
    • TheOccasionalWr 11mo ago
      Kanban in IT world in my experience implies approach where you focus on the work and tasks as they come based on priority. It doesn't imply what is on the board is finished strictly by some date, as the whole premise is that you can't really know. SCRUM implies sprints where you agree in advance what will be actually pulled into sprints and delivered by the team so spillovers are not really expected / wanted.
      • awesome_dude 11mo ago
        I think that we are agreeing that Kanban and estimates aren't really analogous
    • ecaradec 11mo ago
      When working with kanban I maintained a average number of card done per days. if someone asked when some card woud be done, I just multiplied the number of card ahead of that one by average and get an estimate. You can estimate the cards but usually it doesnt really improve accuracy as tasks are on average the same size.
• zkmon 11mo ago
  A couple of decades back PMs used to look at historical data to guide the estimates for a new project. If a similar coding work took 2 weeks on average in the past, that gives some basis. So, I think the issue is about whether it is a routine workflow work which has well-tested historical timelines or not. Nevertheless, estimates are needed at some granularity level. When you order something on Amazon, would like an estimate on when the item would be delivered to you? Even if coding work can't be estimated, the overall project requires estimation. Someone need to commit to timelines and come under pressure. Distribution of that pressure is only fair.
  • louthy 11mo ago
    > A couple of decades back PMs used to look at historical data to guide the estimates for a new project. If a similar coding work took 2 weeks on average in the past, that gives some basis. Even that doesn’t work because the time taken isn’t just about similarity to other work, it’s about how your new feature interacts with the current state of the codebase which is not the same as when the similar feature was implemented before. Ultimately, it’s a complexity problem that’s borderline impossible for our feeble human brains to properly understand. And we consistently misunderstand the nature of that complexity
    • zkmon 11mo ago
      An aircraft engine could be highly complex, but the flight times can be estimated. Complexity is not issue. Reproducibility, and similarity is missing. Every coding work became an adventure into unknown landscape, with no trekking map.
      • louthy 11mo ago
        And that cavalier attitude to complexity is literally the cause of so many issues with software engineering. An aircraft engine is almost simple compared to a multimillion line codebase.
        • zkmon 11mo ago
• jph 11mo ago
  When teams don't need strong estimates, then Kanban works well. When teams do need strong estimates, then the best way I know is doing a project management ROPE estimate, which uses multiple perspectives to improve the planning. https://github.com/SixArm/project-management-rope-estimate https://github.com/SixArm/project-management-rope-estimate R = Realistic estimate. This is based on work being typical, reasonable, plausible, and usual. O = Optimistic estimate. This is based on work turning out to be notably easy, or fast, or lucky. P = Pessimistic estimate. This is based on work turning out to be notably hard, or slow, or unlucky. E = Equilibristic estimate. This is based on success as 50% likely such as for critical chains and simulations.
  • swatcoder 11mo ago
    Three-point or PERT estimates are in the same vein, but are just an old and established business process concept and not a trademarked "project" from a (defunct?) consultancy. https://en.wikipedia.org/wiki/Three-point_estimation https://en.wikipedia.org/wiki/Three-point_estimation https://projectmanagementacademy.net/resources/blog/a-three-point-estimating-technique-pert/ https://projectmanagementacademy.net/resources/blog/a-three-... And yeah, they can be useful when you can must put numbers to things and can decompose the work into familiar enough tasks that your estimation points are informed and plausible. Unfortunately, in a field often chasing originality/innovation, with tools that turn over far too often, that can be a near-impossible criteria to meet.
    • jph 11mo ago
      Yes you're correct. PERT 3-point was my starting point and I wanted to add a critical chain 50% estimate. BTW the SixArm name and ROPE is merely my personal work. Way back when, I had to put on the trademark because someone else said my work was theirs.
  • Marsymars 11mo ago
    > E = Equilibristic estimate. This is based on success as 50% likely such as for critical chains and simulations. I've found giving probabalistic estimates to be hopeless to effectively communicate, even if you assume the possible outcomes are normally distributed, which they aren't.
• yen223 11mo ago
  The unique thing about estimates in software engineering is that if you do it right, projects should be impossible to estimate! Tasks that are easiest to estimate are tasks that are predictable, and repetitive. If I ask you how long it'll take to add a new database field, and you've added a new database field 100s of times in the past and each time they take 1 day, your estimate for it is going to be very spot-on. But in the software world, predictable and repetitive tasks are also the kinds of tasks that are most easily automated, which means the time it takes to perform those tasks should asymptotically approach 0. But if the predictable tasks take 0 time, how long a project takes will be dominated by the novel, unpredictable parts. That's why software estimates are very hard to do.
  • seviu 11mo ago
    I am in a project where we have to give estimates in hours and days. Needless to say we always underestimate. Or overestimate. Best case we use the underestimated task as buffer for the more complex ones. And it has been years. Giving estimations based on complexity would at least give a clear picture. I honestly don’t know what the PO and TL gains with this absurd obscenity.
    • 121789 11mo ago
      Hours is insane. But ultimately time is money and opportunity cost. Software engineering can’t be the only engineering where you ask the engineers how much something will cost or how much time it will take and the answer is “it’s impossible to know”. Even very inaccurate estimates can be helpful for decision making if they are on the right order of magnitude
      • yetihehe 11mo ago
        I think software is one of those VERY rare things, where inaccurate estimates can actually be inaccurate by "orders of magnitude". After 20 years in the field, I still managed to use 2 months of time on a task that I estimated as 10 days.
        • 11mo ago
• epolanski 11mo ago
  One thing that changed my way of thinking about estimates is reading that 86% of engineering projects, regardless of what kind of engineering (chemical, infrastructure, industrial, etc) go over budget (in time or money). Missing estimates isn't unique to software, but it's common across all engineering fields.
  • SoftTalker 11mo ago
    Physical real-world projects include a buffer for this, called "contingencies" or "change orders" so that if a requirement changes or they discover something like previously unknown site geology that will require changes to the foundation they can absorb it. Based on a large history of similar projects their estimates are usually pretty good but occasionally they will run over.
    • tomnipotent 11mo ago
      > but occasionally they will run over 86% is more than "occasionally".
    • epolanski 11mo ago
      Even accounting for contingencies most of civil engineering projects go way over budget. Two elements (the first quite obvious, the second not really) seem to be particularly common in overruns: - the bigger the project the likelier the overrun. Small road projects tend to be over estimated, complex rail projects are virtually always way underestimated, mega projects are never close to the budget. - the lengthier the planning and pre-construction phase the likelier the overrun. This is particularly interesting because it's counter intuitive: you would expect that the more analysis is done, the more accurate the estimates, but experience tells us the truth is the very opposite.
  • phantasmish 11mo ago
    What's wild about software is we don't do 1/10th as much planning as "real" engineering projects do, and also find ways to create problems akin to the ones they run into from interfacing with an unpredictable real-world environment, by inventing ways for all our platforms and libraries and such to be insanely unstable. If you're not subject to the batshit insanity of the broader software market, and you crank the planning up a little closer to what "real" engineering does, software delivery gets extremely predictable. See: NASA's Space Shuttle software development processes. (There are actual, not self-inflicted, problems with software development that "real" engineering doesn't see, though—for one thing, you can't on a whim completely restructure a building that's already been built, and for another, you generally don't have to design real-world engineering projects to defend against the case of intentional sabotage by someone who's just e.g. using the bathroom—it may happen, but it's rare and short of wacky Mission Impossible type plans, busting a water pipe in the bathroom isn't going to get you access to super-secret documents or anything like that)
• Trasmatta 11mo ago
  The thing that sucks is that when I avoid giving estimates, I'm not trying to be difficult, I'm being honest about the unknowns of the project and the inherent uncertainties and messiness of software development. I'm helping protect myself and the rest of the team from making plans based off of bad estimates. But I get all this pushback when I do that, such that the path of least resistance is to give some bullshit estimate anyway. Or I get asked to make a "rough guesstimate", which inevitably turns itself into some sort of deadline anyway. Garbage in, garbage out. Inaccurate estimates, unreasonable timelines, stressed devs and upset PMs. I'm so over working on software teams.
  • patrickmay 11mo ago
    In those cases, you should be asked for estimates to eliminate the unknowns.
• chickensong 11mo ago
  It's also difficult for LLMs it seems. If I forget to add instructions to skip resource estimates, Claude will estimate a week or two, then bang it out in under an hour. For humans, 2x the original estimate.
• hennell 11mo ago
  As a largely solo dev I found I can't estimate well unless it's a common task, and it's easy to find tasks grow exponentially if it touches too many layers. Asking "how long do you want me to spend on this?" got better results, because I got more idea how important tasks were to the business and can usually tell if something is going to take longer than they want. (Or know when we need to discuss scoping it back, or just abandoning the feature)
  • awesome_dude 11mo ago
    I think that that's how you solve the estimate problem - by having an understanding of how many layers it's going to touch, and how big of a change it's going to be for each layer.
  • zipy124 11mo ago
    It also helps because software is one of the rare engineering fields where code is non-destrictive and can be changed after the fact. The carpenters trick of measure many times, cut once, can instead just be cut and re-size if wrong size, which can often be quicker. Asking how long they want me to spend on it also let's me know how solid it needs to be engineered. Is it something that needs doing right then first time, or do we just want something rough that we can refine later with feedback.
• arthurfirst 11mo ago
  30 years ago my boss at a large defense/aviation contractor told me estimating software projects was a very valuable skill, but all estimates were always wrong because they are simplifications and to keep that in mind -- his words. Mainly they are useful to build belief and keep a direction towards the goal. Models of any kind in whatever domain are necessarily always something less than reality. That is both their value and weakness. So estimates are models. Less than reality. Therefore we should not expect them to be useful beyond 'plans are useless, but planning is indispensable' -- I think thats' Eisenhower.
  • arthurfirst 11mo ago
    I literally filled out TPS reports every week at this place down to the hour, breaking down internal project billing and customer billing. In order get the charge codes from the PM, you need to give them estimates. That was the main driver for estimates - convince the non-coders.
• rendall 11mo ago
  There’s a well-established Agile technique that in my experience actually succeeds at producing usable estimates. The PM and team lead write a description of a task, and the whole team reads it together, thinks about it privately, and then votes on its complexity simultaneously using a unitless Fibonacci scale: 1,2,3,5,8,13,21... There's also a 0.5 used for the complexity of literally just fixing a typo. Because nobody reveals their number until everyone is ready, there's little anchoring, adjustment or conformity bias which are terribly detrimental to estimations. If the votes cluster tightly, the team settles on the convergent value. If there’s a large spread, the people at the extremes explain their thinking. That’s the real value of the exercise: the outliers surface hidden assumptions, unknowns, and risks. The junior dev might be seeing something the rest of the team missed. That's's great. The team revisits the task with that new information and votes again. The cycle repeats until there’s genuine agreement. This process works because it forces independent judgment, exposes the model-gap between team members, and prevents anchoring. It’s the only estimation approach I’ve seen that reliably produces numbers the team can stand behind. It's important that the scores be unitless estimates of complexity, not time. How complex is this task? not How long will this task take? One team had a rule that if a task had complexity 21, it should be broken down into smaller tasks. And that 8 meant roughly implementing a REST API endpoint of complexity. A PM can use these complexity estimations + historical team performance to estimate time. The team is happy because they are not responsible for the PM's bad time estimation, and the PM is happy because the numbers are more accurate. A clear description with background appears in Mike Cohn’s original writeup on Planning Poker: https://www.mountaingoatsoftware.com/agile/planning-poker https://www.mountaingoatsoftware.com/agile/planning-poker
  • twerka-stonk 11mo ago
    I do like the blind estimation aspect, but I don’t like: * the arbitrary usage of the Fibonnaci sequence * a non-clear conversion from complexity to time. Complexity and time aren’t always correlated. Some things can be easy but take a long time. Should that be a 1 or a 5? Let’s just cut the layer of terminology, in this difficult task, and estimate in units of time directly.
    • 11mo ago
• freehorse 11mo ago
  I have read about the rule of multiplying any time estimate by 1.57, but ime it should be multiplied by 7.85 rather.
• edoceo 11mo ago
  One thing frustrating for me is when folk leave $BigCo, with it's methods (ie: estimate time to complete, sprint planning) and try to apply those same methods at a very early company. Estimates don't work there at all - everything is new. So, flip it. Use known values to prioritize work. That is: client demand and (potential) revenue. Then allocate known time/budget to the necessary project, see how far you get, iterate. Team can move faster. Looks chaotic. At some (uncomfortable) point however, need to rotate into the "standard" process.
• sema4hacker 11mo ago
  In the 70's a Brazilian programmer told me his method was to make his best guess how long something would take, double it, then promise that amount plus-or-minus 50%.
  • patrickmay 11mo ago
    The one I heard was estimate, double it, and move to the next higher unit. 2 days? Nope, that's 4 weeks.
• hi_hi 11mo ago
  I wonder how different the perception of these projects being late or (massively) over budget would be if we used different words. Bear with me here... Words mean things. Estimate carries a certain weight. It's almost scientific sounding. Instead, we should use the word "guess". It's exactly equivalent, but imagine the outcome if everyone in the chain, from the very serious people involved in thinking up the project, to funding the project, to prioritising and then delivering the project, all used the word "guess" Now, when the project is millions of dollars over budget and many months/years late, no one is under any pretence that it was going to be anything else. I tried this once. It turns out serious people don't like the idea of spending millions of dollars based on "guessing", or even letting developers "play" in order to better understand the guesses they are forced to make, even when it turns un-educated guesses into educated guesses. Of course, none of this would improve the outcome, but at least it sets expectations appropriately.
• mono442 11mo ago
  My experience is that I have to basically always overestimate if I can get away with it because otherwise if something goes wrong, I will pushed to do free overtime to complete all the work assigned in a given sprint.
• zkmon 11mo ago
  Maybe software industry should learn from other industries where people don't see estimates as something unthinkable?
• ricksunny 11mo ago
  I think that executives requiring estimates of time from product owners (PMs, Engineering Managers) is an instrument for putting them into de-facto 'debt' servitude, and provides a constant stream of justification for dismissal with cause. As others have commented, if the ability to time perfectly was there, it would no longer have been an innovative product. Same with requiring sales forecasts from salespeople. There's no way for the salesperson to know, so they are constantly on the chopping block for falling short of forecasts they are forced to generate. I imagine above is more or less tacitly acknowledged in tip-sharing conversations between & among execs & their investors.
• barfoure 11mo ago
  Companies that need estimates have an Estimations department. These are usually companies that are led by and perform engineering work. Software developers aren’t engineers. Project managers have no authoritative training, certification or skills to manage software development projects.
• DanHulton 11mo ago
  From both the developer and manager side of things, I've found that the most important attribute of estimates is frequently the least paid attention to: that they be kept up to date. When you discover more work hidden under that "simple" pile of code, you absolutely HAVE to update your estimate. Add more points, add more tickets, whatever. But then your various managers have the ammunition to decide what to do next - allocate more resources to the project, descope the project, push back the release date, etc. Far too frequently, the estimate is set in stone at the start of the project and used as a deadline that is blown past, with everyone going into crisis mode at that point. The earlier the estimate is updated, the calmer and more comprehensive action everyone responsible can take.
  • dawnerd 11mo ago
    Exactly. And I’ve found this is incredibly hard to get people to do, developers especially. No one wants to say a task is going over / taking longer than expected but will gladly run over. It’s hard for pms to resource if estimates are not updated as scope and complexity changes. Also doesn’t help when estimates become due dates.
  • alanfranz 11mo ago
    I have noticed the same for a lot of long-running software projects. The estimate is created at the start an never revised. Projects can and will fail or run late; but heck; a 6-months projects cannot found late after 5 months and 29 days; things must be discovered early, so that the most important issues can be addressed.
  • trueno 11mo ago
    This is why stuff like Jira is so polarizing for many developers. It is an additional translation tax on me, the developer, to have to go constantly keep this tracking tool thing up to date so that the product owners/managers stay off my nuts. The burden of effort is placed on me to make their tool functional that they can have what they need to provide roll up status. This tool virtually never benefits me, it's always a time consuming sidequest that breaks focus and scatters important information all over a kanban board where tickets disappear and makes it really hard to cohesively work as a unit to get anything done. Like many orgs we've had PM's and stuff try to mandate expectations on when those updates should be provided, somehow completely oblivious to the human nature of development: you should never expect that a developer can simply hop in and out of moments of deep focus and suddenly provide a bunch of updates regularly when it's convenient for you, as if that has zero impact on their work. It takes a toll, full stop. I won't say no to it, but I do expect PM's to know that style of PM'ing is effectively asking me to make your job easier by populating your tool with updates that are useful to you and not me because I'm well aware you aren't involved enough to assess where things are yourself. We've gone through so many cycles of how to use Jira well at my org where these frustrations are shared and we try a different approach, and we're finally starting to converge on the idea that this has historically been a little too lopsided requiring too much tax on the developer doing the actual work. We agreed on a new approach that has actually been pretty awesome: the product owners or managers that are trying to direct a body of work must be a little more in the trenches with us to have an overall understanding of where the different pieces are in a moving body of work. We don't expect them to understand the nitty gritty work in the trenches, but at the same time no more 30,000 foot view product managers who just ask for status updates at EOD. _Everyone_, developers included, is responsible for keeping documentation up to date as we go. So we have central working-bodies of information to find details without having to cruise thru 100+ jira tickets to find details we're looking for. The expectation is that they're engaged enough with development whether in chat or on meetings that if they were blindsided by an executive asking for an update, they could speak to it with some authority over at the water cooler without having to go check Jira. This has really helped weed out the lazy product owners/managers, has forced them to thoughtfully consider their meeting schedules, and has placed the exceptional ones in the pod of work being done and really added a lot of velocity and together-ness about the things we're pushing along. This approach we're using now was born out of some hurt feelings from projects that didn't go so well & we had to have some real restrospective convos where everyone aired out their beef. Those are good convos to have, I think a lot of teams would find that people aren't deceptively trying to screw you over. Being encouraged to level set human-to-human genuinely is one of the greatest parts of working where I work. Always walk away from those types of chats learning valuable things: for the most part our product owners really do care. Not just about their career aspirations but also about _us_ nerdy and sometimes socially maladjusted developers. They look forward to working with us, and they want to make this as easy as possible for themselves but also for the developers. In the past they spent a lot of time in planning phases trying to scaffold out a project in Jira and attaching timelines to it so that their needs are met to provide predictable timelines to their bosses... but also with the hope that by plainly outlining work it sort of 2 in 1 satisfies our needs and will make development timelines a breeze. We've had to ask them to cede rigidity on that latter part because even the software architects admit the work being done is often a moving target. And when that target moves, maybe you realized you need to add a pivotal software solution to the stack, you can sometimes throw like 45 planned tickets into the dumpster. New ship dates need to be assessed. This was our reality check that we were all collectively shit at adapting to the dynamic nature of any given project. Now, our product owners decided that the expectation they have of their own role is that they understand this dynamic and are prepared and willing to make the case about why the shipping timeline must change. So there's actually a pain point solved here: don't break your back doing so much up front work to try and guess/capture what the body of work might look like only for it all to possibly get thrown away, involve architecture a bit more in the planning phases, but most importantly let's engage throughout the project and we'll try our best to have shared ownership/interest in making sure where we are in the project is broadly understood by everyone involved. We're currently in phases of implementing a major platform right now and it's just night and day better and dare I say fun. We're still keeping Jira up to date, but the product owners and PMs are more or less managing this as it is a tool they find useful. Removing the "can you update this ticket please" 24/7 has forced them to be a little more involved and have the right chats, but also makes us developers happier to jump in and get it updated on our own volition because we also want to help them have an easier time. If my PM pings me and says "hey I'm looking at this ticket that's stuck in blocked, I just wanted to make sure we got an update from so-and-so about provisioning this credential so I can follow up if needed" I will likely automagically jump in and be like "still stuck, but let me update that ticket for you there's a couple key details I want to make sure our there for you before you reach out". There's an inherent "we're both interested in seeing this ticket through" here that doesn't strike a nerve with either party. Pretty much everyone involved both developers & non developers has a really solid read on where anything's at and we're all just talking a lot more. And for developers I find that it's really good, even if you've got them committed in one narrow body of work, to understand the larger pieces in motion. When they're in tune with the broader orchestration of a projects timeline, they tend to weigh in during unsuspecting moments that might tie seemingly unrelated pieces together. They might be assigned to work on x, but in a group chat about y they notice y has a dependency on x and they'll speak up and call out the need to test that they both work together. We've had a lot of great callouts materialize like this, and on a human-psyche level I think it snowballs & avalanches encouraging developer participation in a way that is really meaningful for PMs. It's interesting that Jira & the expectation that predicting development time in an arena of uncertainty was previously in the way of forming the group dynamics we have now. Jira, despite just being a tool, can really amplify a lot of bad outcomes when it's used by those who aren't fit to be near development, it sort of devolves into a two dimensional behind-schedule tracker that detrimentally impacts how team members on the ground communicate with each other. And since we're talking a lot more there's just like... way more memes. And memes are important in any development timeline. We prioritize laughing through the pain together.
• bdangubic 11mo ago
  estimates are only difficult cause entire industry has convinced everyone that we do something special which we have no idea how long it will take to do :)
• horizion2025 11mo ago
  It is often not just about the difficulty of estimation the time for specific tasks but also what the assumptions put in were. Sometimes these assumptions werent written out explicitly or other times they were (deliberately?) removed. Just one example of a broken example: a project can be run in many ways. You can have an estimate done based on A-team resources and high priority but the moment the contract or whatever is done, it is decided to outside the whole work to a new team who never worked on the code before and sit thousands of miles away. To compensate 2-3x as many people are assigned. Add in a non technical project manager and scrum master and all kinds of resources that were never envisaged but who will report time in on the project etc. You get the idea. And this was just done type of assumption that could broken!
• JackSlateur 11mo ago
  I'll give you random estimate and start working The more I work, the more the estimate can be refined By the time my work is done, that estimate will be perfect Wait Perhaps my true job is to create perfect estimate ? Is coding only a side-effect ?
• jackfranklyn 11mo ago
  [flagged]
• twerka-stonk 11mo ago
  I will often estimate 3x as a rule of thumb. Estimating is indeed difficult especially when dealing with unforeseen task switching. I was surprised to not see “story points” mentioned in the context of scrum. This is an estimation concept I have found baffling because it is a measure of “complexity”, not time, yet is used directly to estimate how much can be done. At least this is how it is done at my work. Scrum lingo is silly.
  • bdangubic 11mo ago
    scrum lingo is silly because scrum itself is stupidity squared and hence the lingo also cannot be anything but that
• CrzyLngPwd 11mo ago
  Estimates are difficult, but if you monitor your estimate vs actual, and then adjust your next estimate accordingly, then it becomes easier to have decent estimates. There is also the adage that if you are late, then 100% of the time the customer will be unhappy, but if you are early, then 100% of the time the customer will be pleased. So make people more pleased :-) So always over estimate a bit (25%)
  • dboreham 11mo ago
    This only works when the next thing is reasonably similar to the last thing. In my 40 years doing this it's happened exactly once.
• pyrolistical 11mo ago
  My success rate went way up by only making 4 estimates. 1 day 1 week 1 month 1 year This communicates the level of uncertainty/complexity. 5 days is way too precise. But saying 1 week is more understandable if it becomes 2 weeks. I don’t estimate in hours or use any number other than 1
  • bdangubic 11mo ago
    But saying 1 week is more understandable if it becomes 2 weeks. Amazing to read this… everything wrong with our industry summed up neatly in one sentence :)
    • pyrolistical 11mo ago
      Why is that a problem? It is an estimate. Not a hard commitment. By definition estimate can be wrong
      • deely3 11mo ago
        How often you spend a week doing 2-day job?
        • bdangubic 11mo ago
          I’d be fired if that happened without a reasonable explanation why I was so terrible at the task I took on and let my team down by taking that long
      • bdangubic 11mo ago
        thats fantastic as long as you are not the one paying for it
        • Capricorn2481 11mo ago
          I know it's easy internet points to say we should have accurate estimates, but that's not an actionable comment. That's like saying "cars should be safer" and expecting applause. Most clients would rather you just give an estimate with 15 minutes of eyeballing it and hold you to that. That's not realistic, and it's not on developers.
• Animats 11mo ago
  The trouble with estimation is that few places record the estimates and the actuals for future reference. As I've pointed out before, the business of film completion bonds has this worked out. For about 3% to 5% of the cost of making a movie, you can buy an insurance policy that guarantees to the investors that they get a movie out or their money back. What makes this work is that completion bond companies have the data to do good estimations. They have detailed spending data from previous movie productions. So they look at a script, see "car chase in city, 2 minutes screen time", and go to their database for the last thousand car chase scenes and the bell curve of how much they cost. Their estimates are imperfect, but their error is centered around zero. So completion bond companies make money on average. The software industry buries their actual costs. That's why estimation doesn't work.
  • dboreham 11mo ago
    Movie people are doing essentially the same thing over and over for 100 years. Everyone in the industry does things the same way. Their projects last only 1-2 years and are totally done once "in the can". In my experience this is almost never the case with technology based projects.
  • jpfromlondon 11mo ago
    My employer does, but only analyses the overage, so when a project comes in under estimate they think it's because it went smoothly, the reality is actually that estimates only ever tell you how good you are at estimating.
  • kragen 11mo ago
    If your database of software projects has a thousand web browsers in it, you have to ask why all those programmers couldn't work together and write just ten or fifteen web browsers; maybe they're hobbyists who are reinventing the wheel for fun? If so, is that a good basis for estimating a new web browser? The first time I worked on a database-backed web site, my team had written their own ORM, and while I was there we put together a thing so we could use the same view on more than one web page. The second time, we used web.py and no ORM. The third time, we used Ruby on Rails, which solved most of the problems we had on the first project I mentioned out of the box. Most recently, I used Django, which is roughly as convenient as Rails but easier to debug. I haven't tried it, but I'm guessing Claude Code could probably put together a usable Django site in a few minutes. So achieving equivalent results requires very different activities over time, because each time someone does it, we accumulate not just knowledge but code that makes it easier the next time—thousands of times easier, if the novelty is small enough. This impedes estimation. Often, too, the things we're trying to estimate are things like "add automatic Dart dependency support to Blaze". The time-consuming part of this is not breaking the rest of Blaze in the process. What reference class do we use for estimating adding new languages to Blaze without breaking it? Is Dart more like C++ or more like Go? These are questions for lawyers, not actuaries. Maybe the videogames industry is different because they don't share code and don't maintain it? But it seems like an awful lot of games these days are getting written in Godot and Unity where 15 years ago people would have written their own engines... and problems that were major technical challenges for Quake are trivial now. If someone wants ragdolls in their game, they can just license your code, right? They don't have to write it themselves. A dataset of how long it took people to implement ragdolls from scratch wouldn't provide any insight into how long it should take to integrate your ragdoll library.
• osigurdson 11mo ago
  I've always found this sound, rational ROI driven approach to product management a little off the mark. Software isn't like real estate or investing in TBills - you don't invest $X in development and get a nice 10% annualized return on investment over the next 10 years or something like that despite how seductive such thinking can be. It is largely a "hits" business where 1% of the activities that you do result in 99% of the revenues. The returns are non-linear so there should be almost no focus on the input estimation. If your feature only makes sense if it can be done in 3 months but doesn't make economic sense if it takes > 6 months - delete feature.
• amelius 11mo ago
  An LLM's guess is as good as anyone's.
• hal-eisen 11mo ago
  https://youtu.be/QVBlnCTu9Ms?si=k_UolNc2o6UFGS9f https://youtu.be/QVBlnCTu9Ms?si=k_UolNc2o6UFGS9f #NoEstimates Yes, be agile. Yes, measure all the things. But estimation sets everyone up for disappointment.
• alphazard 11mo ago
  The best hack for improving estimation is first never giving a single number. Anyone asking for a single number, without context, doesn't know what they are doing; it's unlikely that their planning process is going to add any value. I think they call this being "not even wrong". Instead you should be thinking in probability distributions. When someone asks for your P90 or P50 of project completion, you know they are a serious estimator, worth your time to give a good thoughtful answer. What is the date at which you would bet 90:10 that the project is finished? What about 99:1? And 1:99? Just that frameshift alone solves a lot of problems. The numbers actually have agreed-upon meaning, there is a straightforward way to see how bad an estimate really was, etc. At the start of a project have people give estimates for a few different percentiles, and record them. I usually do it in bits, since there is some research that humans can't handle more than about 3 bits +/- for probabilistic reasoning. That would be 1:1, 2:1, 4:1, 8:1, and their reciprocals. Revisit the recorded estimates during the project retrospective. You can make this as much of a game as you want. If you have play-money at your company or discretionary bonuses, it can turn into a market. But most of the benefit comes from playing against yourself, and getting out of the cognitive trap imposed by single number/date estimates.
  • charlie-83 11mo ago
    This is what I do but I don't try to make it complicated with too many numbers. "2 weeks but there's a 10% chance something bad happens and it takes longer". I have no problem if they just hear the "2 weeks" part. If they come complaining in 3 weeks I just say "we hit that 10%". The other important thing is to update estimates. Update people as soon as you realise you hit the 10%. Or in a better case, in a week I might be able to say it's now "1% chance of taking more than a week".
  • xyzzy123 11mo ago
    One interesting angle for me is that I am seldom given complete specs or requirements when asked for an estimate. Of course you ask questions to try to determine key information that has not been specified but often the answers are not available or fully reliable. So any estimate has to include uncertainty about _the scope of the work itself_ as well as the uncertainties involved in delivering the work. The natural follow on question when you present a range as the answer to an estimate is: what would help you narrow this range? Sometimes it is "find out this thing about the state of the world" (how long will external team take to do their bit) but sometimes it is "provide better specs".
• pizzafeelsright 11mo ago
  I've found the best estimates are not estimates but non negotiable deadlines with fixed outcome. "You have six weeks to do X for $$$" or "I'll get it done in six weeks or you don't pay" Where i work there is no penalty for being late or not hitting a deadline. Life goes on and work continues. I have seen when there are specific dates and metrics and suddenly people work in focused effort and sometimes work weekends or celebrate with finishing early.
• pmg101 11mo ago
  I always say, "it's a prediction, not a promise."
• spjt 11mo ago
  I've always seen estimates as trying to guess the highest number the PO will accept, the time or effort involved in actually completing the task is irrelevant. I have never had a PO or anyone else complain that a task was completed more quickly than expected. However I do have to be careful to not tell them it is complete too early, lest they start expecting shorter cycles. At least in my company we've stopped calling them "estimates". They are deadlines, which everyone has always treated "estimates" as anyway. Unfortunately in the real world deadlines are necessary. The customer is not just mad that they didn't get the shiny new thing, especially in the case of B2B stuff, the customer is implementing plans and projects based on the availability of X feature on Y date. Back to the initial point, these deadlines often come down to how quickly the customer is going to be able to implement their end of the solution, if they aren't going to be ready to use the feature for six months there's no reason for us to bust our asses trying to get it out in a week.
  • throwawaysleep 11mo ago
    I can't say I know many engineers who object outright to deadlines. They just get frustrated when an estimate turns into a deadline as those are different questions. The far more common pattern is being asked to provide such an estimate off hand and those are all about what you mentioned, giving the PM whatever number you think they will accept.
• arach 11mo ago
  this feels like language from another era
  • cpach 11mo ago
    I’m afraid I don’t follow. Would you mind to elaborate a bit?
• general1465 11mo ago
  Estimates are like traveling from point A to point B in completely unpredictable terrain. Sometimes you can just go straight and beat the estimate easy. Sometimes you will find massive valley and you need to build a bridge to continue while your PM is furiously yelling in the radio that estimated deadline was a week ago.
• nobodyandproud 11mo ago
  Prototyping goes a long way in helping come up with estimates.
• Aeolun 11mo ago
  I don’t think I dislike being forced to estimate. I dislike being asked to estimate by the same people that consistently make those estimates worthless by introducing changes at literally every point in the process.
  • greenchair 11mo ago
    That cuts both ways though. You may hand out an estimate and then once you get into the research/POC weeds need to revise that estimate.
• AceyMan 11mo ago
  "Predictions are hard; especially about the future." –Yogi Berra, MLB HoF catcher & manager
• proc0 11mo ago
  I have a solution but I don't think companies care about this level of meta-analysis on how people work together. They think they do but in reality they just care about optics, and the status quo culture has a huge weight on continuing in the same direction, largely dictated by industry "standards". In essence, estimates are useless. There should only be deadlines and the confidence of engineers of achieving the deadline. To the extent there are estimates, it should be an external observation on the part of PMs and POs based not only on the past but also on knowledge of how each team member performs. This of course only works if engineers are ONLY focusing on technical tasks, not creating tickets or doing planning. The main point of failure in an abstract sense is making people estimate or analyze their own work, which comes with a bias. This bias needs to be eliminated and at the same time you give engineers the opportunity to optimize their workflows and maximize their output. TLDR, engineers should only focus on strictly technical because it allows to optimize within the domain, meanwhile other roles (whoever PM, PO or other) should be creating tasks, and estimating. Of course this doesn't work because there are hard biases in the industry they are hard to break.
• marcus_holmes 11mo ago
  Businesses have many aspects of their operation that are unpredictable: ask the legal team exactly what the result of a legal action will be, and when it will be completed by, and you'll get a fuzzy answer. Ask the marketing team exactly how many new signups will result from this new ad campaign and you'll get a fuzzy answer. Businesses can easily cope with unpredictability, this is not a problem. The problem is that software development has not been treated as one of these unpredictable operations. It absolutely is unpredictable, we know this from decades of experience and all the academic research on the subject. But, probably because of history, politics and power imbalances, software dev teams have very rarely managed to convince executive teams that software development must be treated as unpredictable. As a result, software dev as a profession has a bad reputation for not delivering on their promises. When we do manage to convince executive teams that software development is unpredictable, good things happen. The author's point that "tax software must be released at tax time" still happens, but the planning around the specific feature set takes into account that if the release date is fixed then the feature set in the release will not be. Again, it's not a problem to deal with the unpredictability, as long as everyone accepts that it is unpredictable.
• fs_software 11mo ago
  If you know your team's velocity, this methodology has worked well for me in the past: - ask enough questions about the scope of work to do a prototype - build a prototype to identify constraints / complexity - ask followup questions - break the body of work down into a list of tickets (spike/discovery tickets included) - use the PERT formula to estimate the total number of story points for the body of work - take the total estimated points and divide by your team velocity for a duration of time (e.g. 100 total points / 40 points per 2 weeks = 2.5 weeks)
• bytefish 11mo ago
  I have never been in a project, where estimates were spot-on, and I do this for 15 years now. By now hundreds of features have floated by the river and hundreds of meetings have been held. Estimations are often complicated, because there are way too many variables involved to give accurate estimates. Politics within companies, restructuring of teams. The customer changes their mind, the reality you've expected is slightly different, your architecture has shortcomings you find out late in a project, the teams your work depends on disband, … and a million other things. Theoretically you could update your estimates in a SCRUM meeting, sure, but to be honest, this has always been nothing but a fantasy. We rarely do work in a void. Our features have been communicated higher up and have already been pitched to customers. In a fully transparent and open organization you might update your estimates, and try to explain this to your customers. In reality though? I have never seen this. While this sounds very negative, my take on it is not to waste too much time on estimates. Give a range of time you expect your features to fall into, and go on with getting your work done.
• black_13 11mo ago
  [dead]
• sandeepkd 11mo ago
  I tried to search for the CMMI keyword in the whole discussion to find something relatable. Guess like everything else people happen to loose memory over a cycle and discover it again as if thats something new. Another thing I realize from this is that I am probably getting older.
• xGLaDER 11mo ago
  [Author here] A friend told me my post was gaining some momentum on HN and I've read through the comments and found a bunch of good insights. I especially liked the one from @arach: "this feels like language from another era", which I hope means it's evident my post was written by someone who loves the craft and refrain from prompting an LLM for "a blog post on topic X". I also try to decide whether I side with the numerous people who want to sort development task into either trivial or novel. Someone wrote that if we break each issue down to its components, the above holds, but idk whether the developers who does not want to estimate are keen on doing such a rigorous breakdown of each feature. Regardless, super fun to read all the comments. You have already found my blog and feel free to connect in any way as you see fit (or not at all).
• fittingopposite 11mo ago
  I think the main issue with time estimates is that they don't follow a normal distribution (like many things we are taught in school) but log-normal distribution, which is very skewed and has a big right tail. This misconception is the reason people fail to understand why time estimates are inherently hard.
• phyzix5761 11mo ago
  I've tried running teams with and without estimates and I've noticed that when work isn't estimated it tends to drag on forever. But when you put a number on it, even if it's a rough or inaccurate guess, it gets done much faster.
• commandlinefan 11mo ago
  > Why does the backlog need to be prioritised? We know _why_ you want to know how long everything will take. It seems to escape these guy's attention that if software development was as predictable as they seem to insist it must be, they could be replaced with a spreadsheet.
• coreload 11mo ago
  All estimates should be accompanied by a "cone of uncertainty". Teams should evolve their ability to describe a cone of uncertainty as well as their ability to estimate. Estimating "accurately" is only possible when understanding the accuracy is elevated to the same importance as the estimate itself. https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_what_it_does https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha... https://hubbardresearch.com/product-category/publications/how-to-measure-anything/ https://hubbardresearch.com/product-category/publications/ho...
• tinodb 11mo ago
  I don’t agree with the given answer to “Why the PO wants you to estimate”. The author cites external reasons (made commitments etc) that shouldn’t have been there in the first place. Sure, in some lines of software development you really have a “deadline”, if you are working towards some event or launch date. But most of the time estimates are needed to determine *if it is worth it*. Can it be built in 2 weeks, let’s go. Is it gonna cost 2 months, then let’s prioritise something else. That isn’t to say you always have to go with the shortest te build features (you can apply "CD3" – Cost of Delay Divided by Duration), but you need it to compare alternatives.