14 ms·

How I estimate work

• jll29 8mo ago
  My empirical findings (30 year time frame, dozens of projects, a few larger, some small many small-to-medium, median perhaps 18 calendar months with around four people on the core team): 1. Good estimates are possible. - use intervals, not single numbers; intevals are asymmetric (worst case is far out compared to best and expected cases); - calculate using PERT estimates; - estimate by combining top-down and bottom-up estimates; when both agree, trust the estimate; otherwise, refine/revise the plan; - let the assignee estimate their own work, but the manager correct it (because of (2)); 2. Better engineers tend to underestimate their own time more than average performers. If management tells you how long you got, look surprised and ask them how they can know that; then tell them you will now working on calculating how long it will really take. If their "gut instinct" and your professional estimate diverge, show them your plan, talk them through it, and ask them which part you should leave out (if you keep the time fixed, perhaps you can shrink the scope).
• jmpeax 8mo ago
  "If you refuse to estimate, you’re forcing someone less technical to estimate for you." This is the perfect approach, given that estimates are top down and work to fill the estimate is bottom up. "When I estimate, I extract the range my manager is looking for, and only then do I go through the code and figure out what can be done in that time."
  • inadequatespace 8mo ago
    Except managers also have expectations of what can be done
• shoknawe 8mo ago
  The old guys in the 80's and 90's would say kiddingly multiply your original estimate time pi (3.14).
  • heikkilevanto 8mo ago
    Several times, to be sure
• wbkang 8mo ago
  This resonated with me a lot, thank you. It more or less matches what I have experienced, and it’s good to see someone write this down in a fairly balanced point of view. My favourite parts: > My job is to figure out the set of software approaches that match that estimate. […] > Many engineers find this approach distasteful. […] > If you refuse to estimate, you’re forcing someone less technical to estimate for you. Even after many years, I still find it distasteful sometimes but I have to remind myself what everyone gets paid for at the end of the day.
• RickJWagner 8mo ago
  When I started in the early 90s, a wise old programmer gave me two pieces of advice about estimation. 1. When you consider planning, testing, documentation, etc. it takes 4 hours to change a single line of code. 2. To make good estimates, study the problem carefully, allow for every possibility, and make the estimate in great detail. Then take that number and multiply by 2. Then double that number.
  • dcminter 8mo ago
    I used to (half) jokingly tell people to go to the next human unit. A few days? At least a week. A week? A month. A month? A year. A year? Uh... decade or never... It's wildly pessimistic but not as inaccurate as I'd like.
  • zabzonk 8mo ago
    10 lines of working and tested code per day has always been considered the realistic maximum, in my experience. Anything else is pure optimism - which might of course work for the project in the short term.
• ericyd 8mo ago
  The more I work in engineering, the more I agree with pieces like this which suggest that a large part of the job is managing politics in your workspace.
• publicdebates 8mo ago
  > I ask myself "which approaches could be done in one week?". This is exactly how all good art is done. There's an old French saying, une toile exige un mur.
  • dxdm 8mo ago
    > No results found for "une toile exige un mur". In case anyone else is wondering: The French phrase can be translated literally as "a canvas requires a wall", or less closely, "its boundaries are important for every picture". (I am not a native French speaker and just piecing this together with a dictionary.)
    • wiether 8mo ago
      French guy here: never heard of "une toile exige un mur". Not a single result in French also. I know there's a (more popular?) saying that is very similar but can't remember it atm.
      • publicdebates 8mo ago
        Are you sure? I thought it was Renoir or Batut, or Bresson, or perhaps Watteau, who, when asked for his most useful advice to a new artist, famously uttered this short and mysterious phrase. Could have sworn LaBeouf quoted it in an interview after he collaborated with artist Cantor on their magnum opus.
        • wiether 8mo ago
          It could be a niche quote in an art history book, but it could hardly be qualified as a saying. I asked around since my first comment and not a single person knew about it.
          • publicdebates 8mo ago
            It's so memorable, probably why it stick in my memory: how can you have a canvas without a wall? The wall is the canvas. Yet the wall simultaneously constrains the canvas, thus allowing it to become the canvas, to become worthy of a canvas. This French idiom says so much without saying practically anything.
• mattacular 8mo ago
  Estimation is an art, not a science. It's always going to be a judgement call by the engineers tasked with giving them to management. Taking all of the factors from this article and beyond can and should go into making that judgement call. I always tell my teams just skip the middlemen and think of estimates as time from the jump. It's just easier that way. As soon as an estimate leaves an engineer's mouth, it is eagerly translated into time by everyone else at the business. That is all anyone else cares about. Better said - that is all anyone else can understand. We humans all have a shared and unambiguous frame of reference for what 1 hour is, or what 1 day is. That isn't true of any other unit of software estimation. It doesn't matter that what one engineer can accomplish in 1 hour or 1 day is different from the next. The same is true no matter what you're measuring in. You can still use buffers with time. If you insist on not thinking of your labor in terms of hours spent, you can map time ranges to eg. points along the Fibonacci sequence. That is still a useful way to estimate because it is certainly true as software complexity goes up, the time spent on it will be growing non-linearly.
  • tuna74 8mo ago
    You can improve if you follow up the estimates. My team had several months when we were within +- 10% in the aggregate.
    • AnimalMuppet 8mo ago
      I second this. If you don't close the loop, if you don't keep track of what you estimated and how long it took, how are your estimates going to get better? They aren't. Is that a problem? Well, how good are they now?
• cube2222 8mo ago
  I think the main problem in estimating projects is unknown unknowns. I find that the best approach to solving that is taking a “tracer-bullet” approach. You make an initial end-to-end PoC that explores all the tricky bits of your project. Making estimates then becomes quite a bit more tractable (though still has its limits and uncertainty, of course). Conversations about where to cut scope will also be easier.
  • mariusor 8mo ago
    But how long it'll take you to make that PoC? Any idea? :P
• danjl 8mo ago
  Bravo! Not a single mention of LLMs changing the calculus.
  • badgersnake 8mo ago
    In some situations it may be politically useful to pretend that an LLM makes things faster because that is what your boss wants to hear though.
• bgribble 8mo ago
  One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well. They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engineering team for not delivering to their estimate.
  • genghisjahn 8mo ago
    Anyone from a sales roll care to speak to this?
    • carefulfungi 8mo ago
      Sales gets fired (or not paid) for missing their estimates (quotas, forecasts) and often have little empathy for engineering being unable to estimate accurately.
      • genghisjahn 8mo ago
        Are you in sales or have you ever worked in sales?
        • carefulfungi 8mo ago
          I've been a CTO (with a lot of pre-sales engineering responsibilities) and a VPE responsible for engineering - sales relationships; I've participated in hundreds of prospecting and customer calls and many years of sales planning/strategy/deal review meetings. I can tell you from first hand experience that sales (and marketing, to a large extent) are both strictly measured and held accountable to forecasts. Forecasting a buyer's behavior, or a lead gen pipeline, or deal timing is not easier than forecasting the construction of a new feature.
    • mcfly_c-137 8mo ago
      Really interesting topic. (I’m actually somewhere in between sales and dev - doing Req. Engineering, Concepts and planning). Personally I consider it more important to constantly narrow down any uncertainties over time, than having an initial estimate that holds. The closer it gets to any deadline, the less uncertainty I want (need) to have because the less options remain to react to changes. And frankly, this usually not only applies to estimates but also to things that these estimates rely upon. The longer the timeline, the more room for circumstances and requirements to change.
• maximgeorge 8mo ago
  [dead]
• ripped_britches 8mo ago
  I don’t do a ton of estimation but an interesting new thing is asking a cli agent to estimate for you. First impressions with this is they give really long estimates. Also, due to coding agents, you can have them completely implement several different approaches and find a lot of unknown unknowns up front. I was building a mobile app and couldn’t figure out whether I wanted to do two native apps or one RN/Expo app. I had two different agents do each one fully vibe coded and then tell me all the issues they hit (specific to my app, not general differences). Helped a ton.
  • cvwright 8mo ago
    I think Claude’s estimates are biased towards huge enterprise projects. I asked it to estimate a timeline for a feature in my hobby project and it confidently replied, “4.5 weeks to code completion”. Less than 4 hours later, the feature was done. I asked it to compare this against its initial estimate and it replied, “Right on schedule!” I have completely given up on using it to estimate anything that actually matters.
    • danparsonson 8mo ago
      It's a next-word-prediction-machine, not a calculator. It's not aware of the passage of time, or how long things take, and doesn't reason about anything. It's just very good at putting words together in combinations that look like answers to your inputs. That's really useful for some tasks, like regurgitating code to perform a specific function, but it's basically useless for jobs like estimating schedules.
      • the_arun 8mo ago
        I don’t disagree. But have you tried estimation using Claude or Cursor? If not, give it a try.
• jawns 8mo ago
  Here's my (somewhat tongue-in-cheek) rubric: - If it's an internal project (like migrating from one vendor to another, with no user impact) then it takes as long as I can convince my boss it is reasonable to take. - If it's a project with user impact (like adding a new feature) then it takes as long as the estimated ROI remains positive. - If it's a project that requires coordination with external parties (like a client or a partner), then the sales team gets to pick the delivery date, and the engineering team gets to lie about what constitutes an MVP to fit that date.
  • deleted 8mo ago
    [deleted]
  • tfrancisl 8mo ago
    My issue with the second one is that, as an engineer, I am almost never the one trusted with managing ROI. In r&d this just means your product people expect delivery earlier and earlier, and will accept lower and lower quality if they think it has some return for the product.
    • cryptonector 8mo ago
      Exactly. For many software projects ROI is just not measurable the way it is for more pedestrian products. Sometimes you can estimate the cost of replacing one product with another, and then you can estimate the "value" of enhancements to the current product that keep you from having to spend the cost of replacing it. Other times you can measure happiness of your product's users but not the ROI strictly defined. Other times you can say "this project enabled _that_ project, and that project has a measurable ROI, therefore so does _this_ project". You just can't count on always having a measurable ROI. So far the only metric I've seen that works is KTLO fraction, where lower is better, because that means with the rest of the time you can be adding value, and that value is socially determinable by asking your peers and users. KTLO fraction can't be gamed because your peer managers will call you out on it if you try to cook it. To drive KTLO fraction down you also have to address tech debt that cause high KTLO fractions, and addressing that tech debt enables value-add because between spending less time on KTLO and having a cleaner architecture/design you enable the addition of valuable features.
• tuna74 8mo ago
  Slightly OT, but anyway. The only reasonable way to estimate something is in work hours. Everything else is severely misguided. Also, if you don't follow up any estimate is meaningless.
  • Falimonda 8mo ago
    Work hours is the only way I've learned to think about it productively. It's also important to gather consensus among the team and understand if/why work hour estimates differ between individuals on the same body of work or tasks. I'd go so far as to say that a majority of project planning, scoping, and derisking can be figured out during an honest discussion about work hour estimates. Story points are too open to interpretation and have no meaningful grounding besides the latent work hours that need to go into them.
    • tuna74 8mo ago
      If you have complex tasks and you have more than one person put in time to do a proper estimate, yes, you should sync up and see if you have different opinions or unclear issues.
• Glyptodon 8mo ago
  I agree with most of things on this article with and additional caveat: estimates are also a function of who is going to do the work. If I have a team of 5 offshore devs who need hand holding, 2 seniors who are very skilled, and two mid level or juniors, how long something will take, what directions will be given, and even the best approach to choose can vary wildly depending on which subset of the team is going to be working on it. On top of all the other problems with estimates. This variance has degrees, but particularly when there are high-skilled on shore engineers and low skilled offshore ones, it leads to problems, and companies will begin to make it worse as they get more cost sensitive without understanding that the different groups of engineers aren't perfectly fungible.
  • coffeebeqn 8mo ago
    And how many other parallel work streams are going. So many times I’ve estimated something to be “5” and it’s gone into my queue. Then people are wondering why it’s not done after “5” estimation units have passed and I’ve got “10” points worth of more high priority tasks and fires at every moment of my career
    • tuna74 8mo ago
      Excellent example why anything else than work hours is pointless to estimate in.
• dasil003 8mo ago
  This is a great insight and something every engineer should reflect on in the context of their own orgs: > estimates are not by or for engineering teams. It's surprising the nuance and variety of how management decisions are made in different orgs, a lot depends on personalities, power dynamics and business conditions that the average engineer has almost no exposure to. When you're asked for an estimate, you've got to understand who's asking and why. It got to the point in an org I worked for once that the VP had to explicitly put a moratorium on engineers giving estimates because those estimates were being taken by non-technical stakeholders of various stripes and put into decks where they were remixed and rehashed and used as fodder for resourcing tradeoff discussions at the VP and executive level in such a way as to be completely nonsensical and useless. Of course these tradeoff discussions were important, but the way to have them was not to go to some hapless engineer, pull an overly precise estimate based on a bunch of tacit assumptions that would never bear out in reality, and then hoist that information up 4 levels of management to be shown to leadership with a completely different set of assumptions and context. Garbage in, garbage out. These days I think of engineering level of effort as something that is encapsulated as primarily an internal discussion for engineering. Outwardly the discussion should primarily be about scope and deadlines. Of course deadlines have their own pitfalls and nuance, but there is no better reality check for every stakeholder—a deadline is an unambiguous constraint that is hard to misinterpret. Sometimes engineers complain about arbitrary deadlines, and there are legitimate complaints if they are passed down without any due diligence or at least a credible gut check from competent folks, but on balance I think a deadline helps engineering more than it hurts as it allows us to demand product decisions, designs, and other dependencies land in a timely fashion. It also prevents over-engineering and second system syndrome, which is just as dangerous a form of scope creep as anything product managers cook up when the time horizon is long and there is no sense of urgency to ship.
  • mmis1000 8mo ago
    > When you're asked for an estimate, you've got to understand who's asking and why. This is so real. Sometimes when you get a unreasonably big feature request. It always turns to be somebody don't know how to express their request correctly. And the management overexerted it.
• fallinditch 8mo ago
  I find that ballpark estimates are often more accurate than estimates based on work breakdowns ... and this concurs with OP's observation that estimates tend to miss due to the unknowns.
• notjustanymike 8mo ago
  After owning a product, I've developed a lot of sympathy for the people outside of engineering who have to put up with us. Engineers love to push back on estimates, believing that "when it's done" is somehow acceptable for the rest of the business to function. In a functioning org, there are lot of professionals depending on correct estimation to do their job. For us, an accurate delivery date on a 6 month project was mandatory. CX needed it so they could start onboarding high priority customers. Marketing needed it so they could plan advertising collateral and make promises at conventions. Product needed it to understand what the Q3 roadmap should contain. Sales needed it to close deals. I was fortunate to work in a business where I respected the heads of these departments, which believe it or not, should be the norm. The challenge wasn't estimation - it's quite doable to break a large project down into a series of sprints (basically a sprint / waterfall hybrid). Delays usually came from unexpected sources, like reacting to a must have interruption or critical bugs. Those you cannot estimate for, but you can collaborate on a solution. Trim features, push date, bring in extra help, or crunch. Whatever the decision, making sure to work with the other departments as colaborators was always beneficial.
  • kubb 8mo ago
    You're saying it would be convenient for you to know the future. It would also be convenient for me. That said, if you haven't done very similar work in the past, it's very unlikely you'll know exactly how much time it will take. In practice developers have to "handle" the people requesting hard deadlines. Introduce padding into the estimate to account for the unexpected. Be very specific about milestones to avoid expectation of the impossible. Communicate missed milestones proactively, and there will be missed milestones. You're given a date to feel safe. And sometimes you'll cause unnecessary crunch in order for a deadline you fought for to be met. Other times, you'll need to negotiate what to drop. But an accurate breakdown of a project amounts to executing that project. Everything else is approximation and prone to error.
  • doix 8mo ago
    I used to work in the semiconductor industry writing internal tools for the company. Hardware very rarely missed a deadline and software was run the same way. Things rarely went to plan, but as soon as any blip occured, there'd be plans to trim scope, crunch more, or push the date with many months of notice. Then I joined my first web SaaS startup and I think we didn't hit a single deadline in the entire time I worked there. Everyone thought that was fine and normal. Interestingly enough, I'm not convinced that's why we failed, but it was a huge culture shock.
• rawgabbit 8mo ago
  The most important part of the article is ”I gather as much political context as possible before I even look at the code.”
  • dfunckt 8mo ago
    Exactly. The principle to go by for estimates is finding a balance between time/scope/cost, and figuring out which aspects of the context affect which dimension is the first step.
• deleted 8mo ago
  [deleted]
• paulddraper 8mo ago
  You wouldn’t put up with this drama from any other professional, I don’t know why I’d take it from a SWE. Timelines can be estimated approximately. I’ve never had a construction project finish exactly on time, but that doesn’t mean estimates are unwise.
  • xelah 7mo ago
    I think we should not compare apples to oranges here. A construction project is not an IT project. In a construction project, many things can be easily estimated. I know how much concrete, steel, and other materials I need. I can estimate how long it will take to get them delivered. I can estimate how long it will take to build this one specific part. Sure, there are unknowns, but they are usually (not always) due to human error, price changes, unreliable partners, or weather conditions. That's nothing you can predict upfront (maybe except weather, to a degree), but those factors usually blow up construction projects. Not the fact that it suddenly took you three times as long to build this wall because you had to do it completely differently than before, and couldn't have known that. An IT project is totally different. As the article states (and I agree), most of the work happens in terra incognito. I cannot reliably estimate what I don't know. Sure, there are situations where I can reliably estimate my work, but more often than not, I can't. Especially when the estimates go into weeks or months. There is no way to predict anything reliably for such a period of time, IMO.
• tossandthrow 8mo ago
  IMHO time estimation for software development is a legacy way of thinking. A result of industrial processes. At my team we think in terms of deliverables and commitments: "I can commit til deliver this by that date under these circumstances". This mitigated the diverse nature Og thinking.
• somewhereoutth 8mo ago
  Features : Quality : Timeline Choose 2. For example a large feature set can be made quickly, but it will be of poor quality. Note that cost is somewhat orthogonal, throwing money at a problem does not necessarily improve the tradeoff, indeed sometimes it can make things worse.
  • jayanmn 8mo ago
    Agree. I feel people with less clarity about priorities of features waste too much time by asking accurate estimates
• amelius 8mo ago
  Software time estimations are always going to be bad, you might as well ask an LLM.
• the_arun 8mo ago
  Article resonates with me. This time around, we asked cursor to estimate giving PRD & codebase. It gave very detailed estimate. Currently in the process of getting it down to what leadership wants (as in the article). AI estimates much better & faster than us. We are bringing it down much faster than AI. Sometimes changing the PRD or prioritizing the flows & cutting down scope of MVP. Honestly AI is a great tool for estimation.
• theptip 8mo ago
  > This is, of course, false. As every experienced software engineer knows, it is not possible to accurately estimate software projects. This is a cop-out. Just because you can’t do it, doesn’t mean it’s impossible :) There are many types of research and prototyping project that are not strongly estimable, even just to p50. But plenty can be estimated more accurately. If you are building a feature that’s similar to something you built before, then it’s very possible to give accurate estimates to, say, p80 or p90 granularity. You just need to recognize that there is always some possibility of uncovering a bug or dependency issue or infra problem that delays you, and this uncertainty compounds over longer time horizon. The author even gestures in this direction: > sometimes you can accurately estimate software work, when that work is very well-understood and very small in scope. For instance, if I know it takes half an hour to deploy a service So really what we should take from this is that the author is capable of estimating hours-long tasks reliably. theptip reports being able to reliably estimate weeks-long tasks. And theptip has worked with rare engineers who can somehow, magically, deliver an Eng-year of effort across multiple team members within 10% of budget. So rather than claim it’s impossible, perhaps a better claim is that it’s a very hard skill, and pretty rare? (IMO also it requires quite a lot of time investment, and that’s not always valuable, eg startups usually aren’t willing to implement the heavyweight process/rituals required to be accurate.)
  • funrep 8mo ago
    Did you read the article? They go on explain how you actually do it, in a very reasonable way.
    • theptip 8mo ago
      Hi! “Did you read the article” is generally not in compliance with the HN community guidelines. Please don’t do this.
      • cryptonector 8mo ago
        Pedantic commentary isn't terribly useful either.
  • 8mo ago
• heyitsdaad 8mo ago
  Compare this with how customer requests end up in products in startups: Step 1: Customer <-> Sales/Product (i.e., CEO). Step 2: Product <-> Direct to Engineering (i.e., CTO) The latency between Step1 and Step2 is 10 minutes. CEO leaves the meeting takes a piss and calls the CTO. - Simple features take a day: CTO to actual implementation latency depends on how hands on the CTO is. In good startups CTO is the coder. Most features will make its way into the product in days. - Complex Features take a few days: This is a tug of war between CTO - CEO and indirectly the customer. CTO will push back and try to hit a balance with CEO while the CEO works with the customer to find out what is acceptable. Again latency is measured by days. Big companies cannot do this and will stifle your growth as an engineer. Get out there and challenge yourselves.
• xn 8mo ago
  Is it going to take more than two hours? Is it going to take more than two days? Is it going to take more than two weeks? Is it going to take more than two months? Is it going to take more than two years? If you can answer these questions, you can estimate using a confidence interval. If the estimate is too wide, break it down into smaller chunks, and re-estimate. If you can't break it down further, decide whether it's worth spending time to gather information needed to narrow the estimate or break it down. If not, scrap the project.
  • swat535 8mo ago
    I like this approach, it's more accurate than T-shirt sizing.
  • dchuk 8mo ago
    I prefer 1 hour/1 day/etc but yes, this is the only method that I’ve found to work. Be very clear what result you’re trying to produce, spec out the idea in detail, break down the spec into logical steps, use orders of magnitude to break down each step. There’s your estimate. If you can’t break it down enough to get into the 1 day/1 week range per step, you don’t actually have a plan and can’t produce a realistic estimate
  • scott_w 8mo ago
    There’s also something more concrete about asking “Can you get it done by end of tomorrow? What does that require?” I prefer it over estimating which feels more like asking the length of a piece of string.
    • alfiedotwtf 8mo ago
      The problem I have is, conceptually a task always looks easy, but then as your coding, you hit several problems that are not simple to overcome - in fact, lot of times these issues turn into almost insolvable problems that blow out any time estimates ;(
      • napaparts 8mo ago
• oakashes 8mo ago
  This is all helpful but I felt like it skipped past a critical part - how do you "extract the range my manager is looking for"? Presumably your manager has to stick to the polite fiction that estimates are a bottoms-up process, so what questions do you find helpful to get a sense of the number your manager/leadership team had in mind?
• saghm 8mo ago
  > For instance, many engineering teams estimate work in t-shirt sizes instead of time, because it just feels too obviously silly to the engineers in question to give direct time estimates. Naturally, these t-shirt sizes are immediately translated into hours and days when the estimates make their way up the management chain. I've worked on multiple teams at completely different companies years apart that had the same weird rules around "story points" for JIRA: Fibbonacci numbers only, but also anything higher than 5 needs to be broken into subtasks. In practice, this just means, 1-5, except not 4. I have never been able to figure out why anyone thought this actually made any practical sense, or whether this apparently is either common enough to have been picked up by both teams or if I managed to somehow encounter two parallel instances of these rules developing organically.
  • avandekleut 8mo ago
    Are you me? We do the same thing, and they also translate it into hours by averaging across the whole team's velocity.
• wellpast 8mo ago
  This is one of those discourses that disappoints me about our industry. Estimation can be done. It's a skillset issue. Yet the broad consensus seems to be that it can't be done, that it's somehow inherently impossible. Here are the fallacies I think underwrite this consensus: 1. "Software projects spend most of their time grappling with unknown problems." False. The majority of industry projects—and the time spent on them—are not novel for developers with significant experience. Whether it's building a low-latency transactional system, a frontend/UX, or a data processing platform, there is extensive precedent. The subsystems that deliver business value are well understood, and experienced devs have built versions of them before. For example, if you're an experienced frontend dev who's worked in React and earlier MVC frameworks, moving to Svelte is not an "unknown problem." Building a user flow in Svelte should take roughly the same time as building it in React. Experience transfers. 2. "You can't estimate tasks until you know the specifics involved." Also false. Even tasks like "learn Svelte" or "design an Apache Beam job" (which may include learning Beam) are estimable based on history. The time it took you to learn one framework is almost always an upper bound for learning another similar one. In practice, I've had repeatable success estimating properly scoped sub-deliverables as three basic items: (1) design, (2) implement, (3) test. 3. Estimation is divorced from execution. When people talk about estimation, there's almost always an implicit model: (1) estimate the work, (2) "wait" for execution, (3) miss the estimate, and (4) conclude that estimation doesn't work. Of course this fails. Estimates must be married to execution beat by beat. You should know after the first day whether you've missed your first target and by how much—and adjust immediately. Some argue this is what padding is for (say, 20%). Well-meaning, but that's still a "wait and hope" mindset. Padding time doesn't work. Padding scope does. Scope padding gives you real execution-time choices to actively manage delivery day by day. At execution time, you have levers: unblock velocity, bring in temporary help, or remove scope. The key is that you're actively aiming at the delivery date. You will never hit estimates if you're not actively invested in hitting them, and you'll never improve at estimating if you don't operate this way. Which brings me to: 4. "Estimation is not a skillset." This fallacy is woven into much of the discourse. Estimation is often treated as a naïve exercise—list tasks, guess durations, watch it fail. But estimation is a practicable skill that improves with repetition. It's hard to practice in teams because everyone has to believe estimation can work, and often most of the room doesn't. That makes alignment difficult, and early failures get interpreted as proof of impossibility rather than part of skill development. Any skill fails the first N times. Unfortunately, stakeholders are rarely tolerant of failure, even though failure is necessary for improvement. I was lucky early in my career to be on a team that repeatedly practiced active estimation and execution, and we got meaningfully better at it over time.
• etamponi 8mo ago
  I think this post unveils a great truth that I never grasped: estimates are a political tool to decide what gets done and what doesn't get done. Thanks for putting it so nicely! One thing that I'd like to understand then is _why_... Why doesn't management use a more direct way of saying it? Instead of asking for estimates, why don't they say: we have until date X, what can we do? Is it just some American way of being polite? I am sincerely curious :)
  • fogzen 8mo ago
    I think because capitalist employment is inherently adversarial. If employers (and managers) reveal the time budget, employees may take advantage and reduce output to expand to fill the deadline. Tight schedules squeeze employees, so hiding the real time constraint allows management to exert pressure by adjusting the deadline. Employees that realize the bluff and ignore fake schedule pressure can be identified, marginalized, and eliminated. Avoiding this degrading game is half the reason I preferred contracting.
  • wiether 8mo ago
    Because manager have budgets that are translated in human hours/days of work. So they need to know the cost of each feature to decide which they're going to pick with their budget and deadlines. Think of managers as kids in a toy/candy shop with a $X bill in hand. If items don't have price, how are they suppose to choose? They want everything, but they are limited by their budget.
• fogzen 8mo ago
  The thing that I got wrong about estimates was thinking it was about estimating. Actually, someone already has a time constraint. There’s already a deadline. Always. Your manager, VP, customer, whoever already has a time budget. Find out what it is and work backwards. When someone comes at you for an estimate, you need to be asking for the time budget or expected schedule — not estimating. I failed to understand this for most of my career. Someone would ask me for an estimate, and I would provide one. But without knowing the expected schedule, the estimate is always either too high or too low. Scope is always flexible. The feature or commitment is just a name and a date in people’s heads. Nobody but engineers actually care about requirements. Adjust scope to fit the date, everyone is happy. Adjust the date to fit the scope and people will think you’re either late or fooling them.
• skeptrune 8mo ago
  I think Sean often overplays politics. The most important thing in any project is whether or not it achieves the goal that the overall business has for it. And your job is always to increase the probability of that happening as much as possible. Sometimes it requires politics and sometimes it just requires getting to the task at hand.
  • HEmanZ 8mo ago
    Every engineer thinks politics don’t matter until they end up at a company/org where politics are all that matters…
    • skeptrune 8mo ago
      Politics definitely matter. I just think Sean makes a bigger deal out of it than necessary.
• lifetimerubyist 8mo ago
  > For instance, many engineering teams estimate work in t-shirt sizes instead of time, because it just feels too obviously silly to the engineers in question to give direct time estimates. Naturally, these t-shirt sizes are immediately translated into hours and days when the estimates make their way up the management chain. This is mostly fine when it’s the tooling that does the translating based on rolling historical averages - and not engineers or managers pulling numbers out of their rear.
• j45 8mo ago
  Surprised multiplying by Pi hasn't made it here. Multiply your estimate by 3.14159 until you find the actuals and your more accurate estimating coefficient. https://news.ycombinator.com/item?id=28667174 https://news.ycombinator.com/item?id=28667174 (2013) original: https://web.archive.org/web/20170603123809/http://www.tuicool.com:80/articles/7niyym https://web.archive.org/web/20170603123809/http://www.tuicoo...
• aloukissas 8mo ago
  I love this - it's very similar to what the book Shape Up (https://basecamp.com/shapeup https://basecamp.com/shapeup) calls "appetite". I've been using this method even before I came to read this book for years, it works great! Estimates otoh, really don't.
• telliott1984 8mo ago
  A lot of this felt very familiar. Having multiple plans does seem like a good way to hedge against the unknown, but I can also see that you'd end up with the "secret 5th" plan when all of those unknowns eventually stack up. Planning is inaccurate, frustrating, and sadly necessary.
  • lucketone 8mo ago
    > Planning is inaccurate, frustrating, and sadly necessary. Right.
• o92992930999599 8mo ago
  U5jjtkfjjxhdu88939994999992889398 929 88889993uej72737377787383883998
  • publicdebates 8mo ago
    > U5jjtkfjjxhdu88939994999992889398 929 88889993uej72737377787383883998 Now of course, my dear Watson, you should first suspect this to be a pattern, three groups in fact, separated by the two spaces, with the middle being a three digit number, perhaps an area code. > U5jjtkfjjxhdu88939994999992889398 > 929 > 88889993uej72737377787383883998 But naturally, you would believe (and correctly so) this to be too obvious a clue, suitable only for the mind of a small child, not to mention the fact that these groups still produce nothing coherent. You would then take note of the admixture of letters and digits, thus considering these boundaries to also be that of the grouping mechanism, not having yet forsook the spaces as delimiters. > U5jjtkfjjxhdu > 88939994999992889398 > 929 > 88889993 > uej > 72737377787383883998 Yet this too, I'm afraid, would be merely a red herring, intended to placate the most simple minded of detectives, who, thus having congratulated themselves on such a brilliant deduction, fail to find anything more of meaning within this mangled mesh of evolved squiggles, yet nevertheless refuse to backtrack and admit their logical defeat, preferring rather to indefinitely postpone such investigations as "inconclusive" and requiring more evidence, so as to maintain their disguise as a competent student of human reasoning. But you, oh no, you will not give up so easily, dear Watson, for you have seen practically miraculous epiphanies emerge at precisely the most unexpected of times, yes indeed, and you have thus all the reason in the world to march on just a meter more in this logical game of cat and mouse. And thus you notice next the repeats of digits and groups thereof. > U5jjtkf > jjxhdu > 88939994 > 99999288 > 9398 929 > 88889993 > uej72737 > 37778738 > 3883998 Indeed, Watson, there are quite a few patterns within this group, and you endeavor to piece them all together, one by one, stitching them into a cohesive plop of meaning. You quantify them, count them, group them by every possible demarcator. But you still find youself baffled. And why, my dear Watson? Why, it's elementary, good sir, quite elementary indeed: you failed to take into account the username and date of origin: o92992930999599, created 5 hours ago, with only two comments, this and another: "U878574890309987t366989283i487". You see, my dear friend, there are only three explanations to this baffling mystery. First, and least likely: this is the most advanced crypt I have ever laid eyes on. Preposterous! Bonkers! Absolutely mad! Simply look at the placement. It's a public web forum. There is no need for secrecy, nor for such a secretive communique. Second, this account is merely a computer script, being tested for its verility upon the public forums of the net, to ensure it is functioning properly and soundly. Quite so, but no, these patterns were not computer generated. Indeed not, for the patterns betray a certain command of the physical keybaord. Notice the repition of characters near one another yet not quite symmetric. It's as if the fingers danced across the keyboard, sometime here, sometime there, yet never in one spot for too long, now hopping from the left finger to a new key, now staying a while between two new keys, now hopping from the right to a new key, all the while intending to appear absolutely random, and failing absolutely, I migh add. And this, my dearest Watson, has solved the great mystery for us! The clues have all added up to this one, great, pure moment of clarity: Some kid's js high af n thought itd be funny to type random keys.
• tiberriver256 8mo ago
  How do people get to "staff" without reading industry core reading? Software Estimation: Demystifying the black art by Steve McConnell should be 1st year reading in any software development major in college... We've largely "solved" this problem in the industry we just have a problem of getting people to read and read the right things
  • tree888 8mo ago
    What do you mean “how”? Levels aren’t like building a bridge, it’s just arbitrary stuff. Even money is arbitrary, we’ve got Bitcoin billionaires after all. As for reading… https://thecodelesscode.com/case/215?topic=documentation https://thecodelesscode.com/case/215?topic=documentation
• nickevante 8mo ago
  This discussion on software estimation brings up an interaction I had with an engineer who optimized Black & Decker assembly lines in 1981 using an Apple II. They didn't estimate in 'Story Points'. They used atomic physical constraints. He described it like this: There was a standardized metric for all manual operations like "reach, one hand, 18-24 inches" or "pick item 10-100g." Each step had a time in decimal seconds... The objective was to minimize the greatest difference in station time so that no line worker is waiting. The most interesting part was his conclusion on the result: Modern supply management is a miracle, but manual labor today is much harsher... The goal back then was flow; the goal now is 100% utilization. It feels like in software, we are moving toward that "100% utilization" model (ticket after ticket) and losing the slack that made the line work.
• andychiare 8mo ago
  > It is not possible to accurately estimate software work. An "accurate estimation" is an oxymoron. By definition, an estimate is imprecise. It only serves to provide an idea of the order of magnitude of something: will this work take hours? days? weeks? months? You can't be more accurate. And this does not apply only to software development.
• combatentropy 8mo ago
  This is clever advice, to first find out what estimate is tolerable to management and then adapt your design to fit. It's sort of like what the makers of Basecamp, in their book Getting Real, say in chapter 7, "Fix Time and Budget, Flex Scope"<https://basecamp.com/gettingreal/02.4-fix-time-and-budget-flex-scope https://basecamp.com/gettingreal/02.4-fix-time-and-budget-fl...>. I wonder if it was a mistake to ever call it "engineering", because that leads people to think that software engineering is akin to mechanical or civil engineering, where you hire one expensive architect to do the design, and then hand off the grunt work to lower-paid programmers to bang out the code in a repetitive and predictable timeline with no more hard thinking needed. I think that Jack Reeves was right when he said, in 1992, that every line of code is architecture. The grunt work of building it afterward is the job of the compiler and linker. Therefore every time you write code, you are still working on the blueprint. "What is Software Design?"<https://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm https://www.bleading-edge.com/Publications/C++Journal/Cpjour...> Martin Fowler cites this in his 2005 essay about agile programming, "The New Methodology"<https://www.martinfowler.com/articles/newMethodology.html https://www.martinfowler.com/articles/newMethodology.html>. Jeff Atwood, also in 2005, explains why software is so different from engineering physical objects, because the laws of physics constrain houses and bridges and aircraft. "Bridges, Software Engineering, and God"<https://blog.codinghorror.com/bridges-software-engineering-and-god/ https://blog.codinghorror.com/bridges-software-engineering-a...>. All this explains not only why estimates are so hard but also why two programs can do the same thing but one is a thousand lines of code and one is a million. I came into programming from a liberal arts background, specifically writing, not science or math. I see a lot of similarities between programming and writing. Both let you say the same thing an infinite number of ways. I think I benefitted more from Strunk and White's advice to "omit needless words" than I might have from a course in how to build city hall.
  • cpeterso 8mo ago
    I like Basecamp’s framing of software development time as management’s “appetite” for a new feature, how much time they are willing to spend on a project, as opposed to an estimate. This helps time box development and control project scope. https://basecamp.com/shapeup/4.5-appendix-06 https://basecamp.com/shapeup/4.5-appendix-06
• hosainnet 8mo ago
  The most memorable estimation technique I came across when I started out as a software engineer was "two days or less?". Our team would simply gather around, go through the tasks that were agreed with the business and on count of three, each of us simply raise a thumbs up if we thought we could ship it within two days - otherwise thumbs down. It generally implied we collectively thought a task would take more than two days to ship, it may require breaking down, otherwise it’s good to go.
• danabrams 8mo ago
  I read what the author is saying as “time is fixed, so I adjust the scope.” The problem is when product or management is demanding both fixed time and fixed scope. “Here’s a list of requirements (which are under defined and we will change without giving you a chance to estimate) and a set of figmas you must implement for those requirements (and also we will look at the finish product and decide not to give you any extra time to make changes we want or build a breakpoint not defined by the Figma that we demand), no how much time with this I’ll-defined, fixed-scope take?” Fixed time and fixed scope is essentially impossible, except in trivial cases. What I read the author saying is that he chooses to make it fixed time and has flexibility around scope in his work, because the requirements are more like loose descriptions than a description of exactly what a product should do, while ignoring edge-cases. That sounds like a nice situation. And a perfectly fine way to manage an engineering team. But it also sounds a bit to me like an abdication of responsibility to the engineering team by product, to allow the engineering team to decide what exactly the scope is. Again, that’s a perfectly good way to do it, but it means that product can’t come back and say “that’s not what I was expecting, you didn’t do it.” I don’t think the author really tackles estimation here, nor the reasons why estimation is a hard and controversial issue, nor what junior engineers are looking for when googling “how do I estimate?” The real reason it’s hard in this industry is that in general, product controls both scope and time, which are the two major dials by which delivery is managed, but abdicate responsibility for them by going an ill-defined but nonetheless more fixed (and unyielding) scope than described in this article, then demanding engineers give them specific date estimates to which they’ll commit, and work free overtime if they turn out to be wrong. The author correctly defines a way to resolve this conflict: give engineering more say over scope—but fails to recognize that the root cause is not poor estimation, but rather that product or management denies engineering much say over scope past the initial estimation, and then demands they set fixed dates they commit to before enough is known. Death march projects, in my experience, are generally a failure of product, not engineering.
• HEmanZ 8mo ago
  Whenever this comes up I feel like I work on completely different kinds of software than most people here. (Giant, backend, distributed systems projects at FAANG) I’ve never worked on anything large in software where the time it will take can be reasonably deduced at the accuracy some people here seem to assume possible. The amount of unknown-unknowns is always way way too large and the process of discovery itself extremely time consuming. Usually it requires multiple rounds of prototypes, where prototypes usually require a massive amount of data transferred to adequately mine for work discovery. The best you can do is set reasonable expectations with stakeholders around: - what level of confidence you have in estimates at any point in time - what work could uncover and reduce uncertainty (prototypes, experiments, hacks, hiring the right consultant, etc) and whether it is resourced - what the contingency plans are if new work is discovered (reducing specific scope, moving more people (who are hopefully somewhat ramped up), moving out timelines)
  • jkubicek 8mo ago
    > what the contingency plans are if new work is discovered (reducing specific scope, moving more people (who are hopefully somewhat ramped up), moving out timelines) I think this is the most important. You can't just HAVE contingency plans, but you need to be clear in who you need to get approval / sign-off on those contingency plans and who you need to notify. As a developer, knowing that you're going to need to drop Feature B to hit your deadline, but being unable to get the right people to approve dropping Feature B is endlessly frustrating and a massive waste of time on any project.
    • HEmanZ 8mo ago
      Yup, the whole chain of command needs to be bought in. All of this is not “in my head” but “well established with m1, m2, pm” In my experience this is a really hard conversation and you have to build a lot of relationship/trust (aka politics) within the company to be direct about it. But it saves you and your team from burnout, because it eliminates the expectation of “if you fall behind you’ll work 80hrs/wk until the timeline is caught up” which is what I’ve seen happen too many times.
  • 8mo ago
• khendron 8mo ago
  When I was in grad school my faculty advisor joked to me that to accurately estimate any medium to large software project, take your best estimate and multiply it by 3. If hardware is involved, multiply by 8. Yes, he was telling me this tongue in cheek, but in my actual experience this has been eerily accurate.
• wreath 8mo ago
  What often baffles me with engineers and especially engineering managers is that they don't derive the estimates from metrics of prior projects, especially for long running teams (as opposed to project teams). You don't need to estimate down to the minute, but you already know how many tickets/work items the completes at a given time interval with how many people in the team etc. This should give a rough estimate of how long a project might take, and you can confidence intervals like 90% confidence we finish this in 3 months, 70% confidence we finish it in 10 weeks, 50% confidence in 6 weeks and 10% confidence we finish it in 2 weeks. IMO this is also a better way to communicate with stakeholders outside the team instead of committing to a specific date. It gives more context and clearly communicates that this is a probability game after all since there are quite few moving variables.
  • flyingcircus3 8mo ago
    I think it comes down to the difference between predictions and prescriptions. When a person is predicting how long someone else's work will take, the revelation of their error causes them to change their subsequent predictions to be more accurate. When a person is prescribing how long someone else's work will take, the revelation of their error causes them to demand productivity increases.
  • pan69 8mo ago
    How long does it take to do a crossword puzzle or play a game of chess?
    • mlok 8mo ago
      Usually less than 2 days, with a 90% confidence.
    • tuna74 8mo ago
      Chess games usually have time limits, so pretty easy. Cross words depend on the size and difficulty.
    • impute 8mo ago
      You record the amount of time it takes people to do a crossword puzzle or play a game of chess. After a while you'll be able to make a distribution graph of how long it takes. Then you can give an accurate estimate along with a probability.
• croisillon 8mo ago
  blog title police, always present https://news.ycombinator.com/item?id=46256631 https://news.ycombinator.com/item?id=46256631
• rajman187 8mo ago
  i think it's worth revisiting this in a short while because, by and large, how the engineering craft has been for the last 40+ years is no longer the correct paradigm. it takes Claude Code a few moments to put together an entire proof of concept. engineers, especially experienced ones, will be less likely to produce (and hence be performance-calibrated on) code as output but rather orchestration and productionization of [a fleet of] agents. how do you guide an llm to produce exactly what is needed, based on your understanding of constraints, available libraries, various systems and APIs, etc. to accomplish some business or research goal? in that sense, estimation should theoretically become a more reasonable endeavor. or maybe not, we just end up back where we are because the llm has produced unusable code or an impossible-to-find bug which delays shipment etc.
• firefoxd 8mo ago
  We estimated a single sprint to move from our plain text passwords. Easy! Add a new field in the db for secure pass, and one to force password update. Update the api to take the new fields into account... It took 6 months. Why? Well it was a legacy app, and we learned that passwords were case insensitive because the customer sent a video of him entering his password that failed. On the video, we could see a sticky note on his monitor with the password written on it. When we made all the necessary changes, the docker file failed to build. SRE accidentally deleted the deprecated image with PHP that had reached EOL. Estimating is always fun.
  • shoo 8mo ago
    Your story reminded me of Bent Flyvbjerg and Dan Gardner's book "How Big Things Get Done". It's a pop science book communicating the research of Flyvbjerg & collaborators who collected data of actual schedule & budget outcomes for many large projects, along with recording the estimated schedule and budgets from the time the go/nogo decision was made to invest in the projects. For accurate schedule and budget estimates, Flyvbjerg strongly recommends figuring out which broader class of projects your project belongs to, then going and looking at accurate historical data with actual schedule and budget outcomes for projects in that class, and using historical averages as your estimates. There's a great table in an appendix at the back of the book, offering statistics for each category of project, ranking them by mean cost overrun. The absolute worst category of project, for mean cost overruns, is nuclear storage, with a mean cost overrun of 238%. IT projects are the 5th worst category of project, with a mean cost overrun of 73%, behind nuclear storage, olympic games, nuclear power and hydroelectric dams. The table also has statistics on "what percentage of projects has a cost overrun of 50% or greater" and "of those projects with a cost overrun of 50% or greater, what is their mean cost overrun". For nuclear storage projects, 48% of them have a cost overrun of 50% or greater, and of those, the mean cost overrun is 427% (!). For IT projects, 18% of them have a cost overrun of 50% or greater, and of those, the mean cost overrun is 447% (!!). Some of the chapters in the book discuss some of the structural or political pressures that set projects up to fail --- e.g. in some fields its an open secret that estimates are always wildly optimistic, as if the estimates were actually realistic, no one would ever agree to fund a project.
  • 8mo ago
• Jegber 8mo ago
  At my job we do all of our work estimations through a prediction market. Accurate predictions give real money payouts. Works great!
  • makeset 8mo ago
    I am sure you make this work on good faith at a small size, but how is it doable at large without insider trading, manipulation, and perverse incentives? People doing the work will be more informed and in a position to affect the outcome.
• crazygringo 8mo ago
  Not a single mention of planning poker and story points? They're not perfect (nothing is), but they're actually pretty good. Every task has to be completable within a sprint. If it's not, you break it down until you have a part that you expect is. Everyone has to unanimously agree on how many points a particular story (task) is worth. The process of coming to unanimous agreement is the difficult part, and where the real value lies. Someone says "3 points", and someone points out they haven't thought about how it will require X, Y, and Z. Someone else says "40 points" and they're asked to explain and it turns out they misunderstood the feature entirely. After somewhere from 2 to 20 minutes, everyone has tried to think about all the gotchas and all the ways it might be done more easily, and you come up with an estimate. History tells you how many points you usually deliver per sprint, and after a few months the team usually gets pretty accurate to within +/- 10% or so, since underestimation on one story gets balanced by overestimation on another. It's not magic. It prevents you from estimating things longer than a sprint, because it assumes that's impossible. But it does ensure that you're constantly delivering value at a steady pace, and that you revisit the cost/benefit tradeoff of each new piece of work at every sprint, so you're not blindsided by everything being 10x or 20x slower than expected after 3 or 6 months.
  • samastur 8mo ago
    I used to work for a company where we spent a day every 2 weeks doing this. And I had a headache at the end of the day every two weeks. Great that it works for you.
    • crazygringo 8mo ago
      A day is crazy. In my experience, retrospective takes about 30-60 minutes, and estimation is usually 1.5-2 hours. Does it take time? Sure. But what's the alternative? Not doing it is even worse, because you wind up with these endless never-finished "features" that turn out to be 20x harder than anyone thought, that engineers have sunk months and months and months into...
    • turdprincess 8mo ago
      Same - my new team doesn’t do any scrum or story points and it’s an amazing breath of fresh air - don’t miss those days just yelling random numbers at the zoom call for hours. The truth is on most teams one or two people who are closest to the task have enough context to estimate, and probably only after they spent some time starting or prototyping the task. Those people can give a reasonable estimate, in time not some strange point system. Sometimes the estimate is wrong and that’s ok. It’s fine to have a meeting catching everyone else up on the context but those pther people still likely don’t have enough to give an accurate estimate and shouldn’t be involved in estimation
• mmcnl 8mo ago
  I don't get the fight against estimates. An estimate is an estimate. An estimate can be wrong. It likely is wrong, that's fine, it doesn't have to be perfect. There is a confidence interval. You can communicate that. Very often something like "6-12 months" is a good enough estimate. I've worked in software a long time and I really don't get why many people think it's impossible to give such an estimate. Most of us are developing glorified CRUD apps, it's not rocket science. And even rocket science can be estimated to a usable degree. Really you have no idea if feature X is going to take 1 day or 1 year?
  • hahn-kev 8mo ago
    For me the worst part is that I (and they) don't fully know what the person asking me from the estimate wants me to build, and usually the fastest way is to just build the thing.
  • lucketone 8mo ago
    I think there are range of situations causing anti-estimate sentiment, each team is different, each tram has different levels or combination of these: - manager’s refusal to acknowledge any uncertainty - unclear requirements/expectations/system under change - changing requirements - negative consequence (“penalties”) for inaccurate estimate I’m now also in the environment where I give ranges, but not everybody is.
  • marcosdumay 8mo ago
    > It likely is wrong, that's fine It's almost never fine, though. When it's fine, people aren't pressured into giving estimates. > It likely is wrong, that's fine The most you can do is say it. Communication demands effort from all involved parties, and way too many people in a position to demand estimates just refuse to put any effort into it.
  • ptmcc 8mo ago
    You've never had a manager or product person take estimates, even clearly communicated as low confidence or rife with unknowns, as gospel truth? Lucky you.
• cfhz 8mo ago
  Extremely relatable. We seem to have a similar problem in product design.
• moribvndvs 8mo ago
  I’ve long felt estimations are a negotiation. It’s not as much about how long it will take or how much it will cost, but what do you really need and what can you afford. Kinda like I’m helping someone buy a car based on their needs and budget, I’ll put together 3 “trim line” options: 1. Economy (bare functionality, prefer low cost and fast delivery over reliability and longevity) 2. Mid tier (good enough quality and reliable but no frills) 3. Luxury (all the bells and whistles) The business will want all the bells and whistles of 3 but also the pragmatism of 2 but the budget and timeline of 1. So, they don’t actually pick themselves, I choose for them based on the circumstances and we negotiate the finer points. Devs can gold plate the shit out of any project, but having a plan for #1 is helpful when shit hits the fan and the business needs you to pivot. More than that, it’s useful during the negotiation to illustrate the ramifications of shortcuts. It’s helped me more than a few times to avoid some really stupid decisions from panicking PMs and execs.
• cauch 8mo ago
  I always have a lot of questions when I see this kind of articles, and I don't think any articles properly answer it. 1. What is different in software engineering with respect to any other work that require exploration? The author mentions "it requires research, it's why it's impossible". But plenty of work requires research and people doing it are also asked to provide an estimate: writing a book, managing a complicated construction project, doing scientific research, ... In all of this, it is also well known that time estimation is tricky and there are plenty of examples of deadline not met. Yet, it looks like that these people understand 1) that their estimations are guesses, 2) that still giving an estimation is useful for their collaborators. I've worked in academic research, and famously, you sometimes need to write a document for a grant detailing the timeline of your project for the next two years. We all knew what it was (an estimation that will deviate from reality), but we understood why it was needed and how to do it. I now work as researcher in the private sector, sometimes very closely with the software developers, sometimes doing the same work as them, so I have a strong experience of what it is asked. And I'm often surprised how often software developers are thinking that they are "special" when they have to deal with something that a lot of other persons have to deal with too, and how often they are all lost by this situation while other persons manage to go around it pragmatically. 2. Why is so many of these articles not reflecting in a balanced way on why people asked time estimates? When the article comes to explain why developers are asked for estimate, the main reason seems to be "because non developers are idiots, or because of the checking box system, or because of the big bad managers who want to justify their role, or because it is the metric to judge the quality of the work". But at the same time, if they need something, the same developers asks for time estimate all the time. This is just something needed to organize yourself. If you know that the builders will work in your home for 6 months, you know that you need to prepare yourself differently than if it is 2 days. And how many time a developer asked for something, did not get it in time, and did not conclude that it demonstrates the worker was incompetent? (I'm sure _you_ don't do that, rolling my eyes at the usual answer, but you have to admit that such conclusion is something that people do, including developers) Why in these articles, there is never reflection on the fact that if you don't give any estimate, your colleagues, the people you are supposed to work with, and not against, don't have the information they need to work properly? The tone is always adversarial: the bad guys want a time estimate. And, yes, of course, we have situations where the admin becomes the goals and these requests are ridiculous. But on the other hand, I also understand that developers are asked to follow more process when at the same time they act like teenage-rebel condescending kids. I'm not sure what is the distribution, but even if it is not 50-50, it tells so much about the level of reflection when the article is unable to conceive that, maybe, maybe, sometimes, the developer is not the victim genius surrounded by idiots. (in fact, in this article, there is the mention of "Some engineers think that their job is to constantly push back against engineering management, and that helping their manager find technical compromises is betraying some kind of sacred engineering trust". But, come on, this is a terrible flaw, you should be ashamed of being like that. This sentence is followed by a link to an article that, instead of highlighting how this behavior should be considered as a terrible flaw, frames it as "too idealistic")
• hyperman1 8mo ago
  Something I learned on this site: We're bad at estimating the average duration, but reasonable for the mean duration. If you get 10 tasks of seemingly equal duration, 9 will go well and 1 will hit a reef of unexpected troubles and take forever. So the practice of doubling is not that stupid. It leaves time in the first 9 to deal with the unexpected disaster.
  • boltzmann-brain 8mo ago
    except "work expands so as to fill the time available for its completion", and therefore, after each of the 9 tasks is completed, there is no time left for the 10th task. so this only works if the disaster happens very early, or if you do almost all of the tasks in parallel. neither is the expected case.
    • hyperman1 8mo ago
      I tend to have many tasks in parallel, as there are always multiple blocked on input from someone else. E.g. * 2-3 big programming tasks as focus for this week: I push one forward until I hit a wall, then task switch. * A backlog of about 5 dumb non-urgent tasks for when the brain is not braining or in meeting filled days. * 4-5 tasks where I keep asking people questions until the problem is understood. These tend to wake up when receiving information, take priority with 10-30 minutes of writing mails and looking up interesting cases, followed by a few days of waiting for an answer.
• bitwize 8mo ago
  > This is, of course, false. As every experienced software engineer knows, it is not possible to accurately estimate software projects. Hogwash. Has this person never run a business, or interacted with those who have? The business depends on estimates in order to quantitatively determine how much time, money, and resources to allocate to a project. Teams in the manufacturing and construction fields deliver estimates all the time. Why shouldn't IT people be held to the same standard? If you can't estimate, it's generally because your process isn't comprehensive enough. Tim Bryce said it's very straightforward, once you account for all the variables, including your bill of materials (what goes into the product), and the skill level and effectiveness rating (measured as the ratio of direct work to total time on the job) of the personnel involved. (You are tracking these things, aren't you?) https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/1928/Estimating--Getting-it-Right.aspx https://www.modernanalyst.com/Resources/Articles/tabid/115/I... > The pro-estimation dogma says that these questions ought to be answered during the planning process, so that each individual piece of work being discussed is scoped small enough to be accurately estimated. I’m not impressed by this answer. It seems to me to be a throwback to the bad old days of software architecture, where one architect would map everything out in advance, so that individual programmers simply had to mechanically follow instructions. If you're not dividing the work such that about ~60% of the time is spent in analysis and design and only ~15% in programming, you've got your priorities backwards. In the "bad old days", systems got delivered on time and under budget, and they shipped in working order, rather than frustrating users with a series of broken or half-working systems. This is because PRIDE, the scientific approach to systems analysis and design, was the standard. It still is in places like Japan. Not so much America, where a lot of software gets produced it's true, but very little of it is any good.
• zmj 8mo ago
  I was prepared to disagree with the thesis that estimation is impossible. I've had a decent record at predicting a project timeline that actually tracked with the actual development. I agree with the idea that most of the work is unknown, but it's bounded uncertainty: you can still assert "this blank space on the map is big enough to hold a wyvern, but not an adult dragon" and plan accordingly. But the author's assessment of the role that estimates play in an organization also rings true. I've seen teams compare their estimates against their capacity, report that they can't do all this work; priorities and expected timelines don't change. Teams find a way to deliver through some combination of cutting scope or cutting corners. The results are consistent with the author's estimation process - what's delivered is sized to fit the deadline. A better thesis might have been "estimates are useless"?
• toonalfrink 8mo ago
  I find that function point estimation, potentially adjusted with COCOMO factors, is pretty decent. I find it strange that no one is talking about these methods
• andrewingram 8mo ago
  Ambiguity increasingly feels like the crux of estimation. By that I mean the extent to which you have a clear idea of what needs to be done before you start the work. I do a lot of fussy UI finesse work, which on the surface are small changes, so people are tempted to give them small estimates. But they often take a while because you’re really learning what needs to be done as you’re doing it. On the other end of the spectrum I’ve seen tickets that are very large in terms of the magnitude of the change, but very well specified and understood — so don’t actually take that long (the biggest bottleneck seems to be the need to break down the work into reviewable units). In the LLM age, I think the ambiguity angle is going to much more apparent, as the raw size of the change becomes even less of an input into how long it takes.
• impute 8mo ago
  The only reliable way to estimate is to find another relatively similar project and compare it to that. You can say stuff like this new project is roughly similar in scope to Project X but maybe it's about 20% more complicated due to more scope so it will probably take about 20% longer than what Project X took. The key is to keep data on how long past projects actually took (which not a lot of organizations do). But once you have that real data, you can understand all the unknown unknowns that came up and assume that similar things will come up on the new project.
  • bmitch3020 8mo ago
    Except if you've already done a very similar project before, the unknowns are now knowns. And more importantly, problems already have developed solutions that can be copied or reused, and not developed. So a very similar project should be an overestimate, and a repeated task should take a fraction of the first time.
  • jweatherby 8mo ago
    In my experience that's where story points come in. "This comparable project took this number of story points, therefore <new project> should be similar, resulting in a comparable amount of time." The usage of story points help to adjust for complexity. The story points are that data point in the past used to indicate the future.
• nazgul17 8mo ago
  At my previous workplace, we were developing a greenfield project, years in the making and kinda already brownish. Our managers were using our estimates to choose the right amount of work to fit into a sprint (fortnight). Am I misinterpreting things or there is no overlap with the circumstances argued in the OP? Also, in that case, how do we make quality tradeoffs when all features are necessary for the end product?
• aleph_minus_one 8mo ago
  > When you have weeks or months until your deadline, you might spend a lot of time thinking airily about how you could refactor the codebase to make your new feature fit in as elegantly as possible. When you have hours, you will typically be laser-focused on finding an approach that will actually work. No, when I have hours, I am laser-focused on pissing off the manager who gave me so little necessary time to do the task. :-)
• __coder__ 8mo ago
  For me, estimates are done to make the job of management easier and make life of the developer harder.
• Huston1992 8mo ago
  if i have to estimate something > 2 days i just assume im guessing. usually means there's hidden complexity i haven't found yet. i estimate until the subtasks are small enough (like 4h chunks), otherwise its all just feeling based numbers.
• cainxinth 8mo ago
  When someone comes to me and says: “I need this project by this date,” I’ll look at the project and my calendar, and then say one of three things: - “That seems doable, but I’ll let you know if any problems arise.” - “That is going to be really tight. I’ll do my best, but if I think it can’t be done in that timeframe, I’ll let you know by the halfway point.” - “I can’t get that done that fast. I’ll need more time.” In the third case, when they follow up with “How much more?” I’ll give them a timeframe that fits the second case and includes the notification plan.
• cryptonector 8mo ago
  > Estimates are political tools for non-engineers in the organization. They help managers, VPs, directors, and C-staff decide on which projects get funded and which projects get cancelled. > Estimates define the work, not the other way around > The standard way of thinking about estimates is that you start with a proposed piece of software work, and you then go and figure out how long it will take. This is entirely backwards. Instead, teams will often start with the estimate, and then go and figure out what kind of software work they can do to meet it. So true. But there are times when the thing to be built is known and an estimate is needed [for political reasons, as TFA explains], which is why sometimes it's the other way around.
• cadamsdotcom 8mo ago
  This sort of stuff has parallels outside software - the book “how big things get done” is amazing, and one interesting thing it implies is that solar installations tend to go the best because they’re modular and lessons learned can be applied to the next phase of a project. Whereas the worst overruns are nuclear power plants; which are either switched on and working, or completely useless and taking up space! So my takeaways were: try to make estimates modular and work out how to carry learnings as your project goes on, and you’ll have an easier time hitting your estimates - and probably get a great reputation for delivering!
• zeodtr 8mo ago
  I think it's important not to waste too much time upfront on overly detailed estimates.