[HN Gopher] Estimates are difficult for developers and product o...
___________________________________________________________________
Estimates are difficult for developers and product owners
Author : todsacerdoti
Score : 123 points
Date : 2025-12-07 19:17 UTC (3 hours ago)
(HTM) web link (thorsell.io)
(TXT) w3m dump (thorsell.io)
| th0ma5 wrote:
| It's a shame that developers read these articles and not project
| managers.
| based2 wrote:
| https://en.wikipedia.org/wiki/Delphi_method >
| https://news.ycombinator.com/item?id=26368011
|
| https://blog.pragmaticengineer.com/yes-you-should-estimate/ >
| https://news.ycombinator.com/item?id=27006853
|
| https://josephmate.github.io/PowersOf2/ Complexity Estimator
|
| https://earthly.dev/blog/thought-leaders/ >
| https://news.ycombinator.com/item?id=27467999
|
| https://jacobian.org/2021/may/20/estimation/ >
| https://news.ycombinator.com/item?id=27687265
|
| https://tomrussell.co.uk/writing/2021/07/19/estimating-large... >
| https://news.ycombinator.com/item?id=27906886
|
| https://www.scalablepath.com/blog/software-project-estimatio...
|
| https://estinator.dk/ >
| https://news.ycombinator.com/item?id=28104934
|
| https://news.ycombinator.com/item?id=28662856 How do you do
| estimates in 2021?
|
| https://web.archive.org/web/20170603123809/http://www.tuicoo...
| Always Multiply Your Estimates by p >
| https://news.ycombinator.com/item?id=28667174
|
| https://lucasfcosta.com/2021/09/20/monte-carlo-forecasts.htm... >
| https://news.ycombinator.com/item?id=28769331
|
| https://tinkeredthinking.com/index.php?id=833 >
| https://news.ycombinator.com/item?id=28955154
|
| https://blog.abhi.se/on-impact-effort-prioritization >
| https://news.ycombinator.com/item?id=28979210
|
| https://www.shubhro.com/2022/01/30/hacks-engineering-estimat...
|
| https://www.paepper.com/blog/posts/monte-carlo-for-better-ti...
|
| https://drmaciver.substack.com/p/task-estimation-101 >
| https://news.ycombinator.com/item?id=32177425
|
| https://morris.github.io/e7/#?t=
|
| https://stevemcconnell.com/17-theses-software-estimation-exp...
|
| https://www.doomcheck.com/ >
| https://news.ycombinator.com/item?id=34440872
|
| https://github.com/kimmobrunfeldt/git-hours
|
| https://pm.stackexchange.com/questions/34768/why-are-develop... >
| https://news.ycombinator.com/item?id=35316808
|
| https://erikbern.com/2019/04/15/why-software-projects-take-l... >
| https://news.ycombinator.com/item?id=36720573
|
| https://news.ycombinator.com/item?id=42173575
|
| https://www.thecaringtechie.com/p/8-guaranteed-ways-to-annoy... >
| https://news.ycombinator.com/item?id=43146871
|
| https://news.ycombinator.com/item?id=43873604
| teddyh wrote:
| <https://www.joelonsoftware.com/2000/03/29/painless-
| software-...>
| truelson wrote:
| I preffered:
| https://www.joelonsoftware.com/2007/10/26/evidence-based-
| sch...
|
| 20-25 years later, this is still where we are at :)
| truelson wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| When you make a plan, you have the least information you will
| ever have about the goal/problem.
| thfuran wrote:
| Re-planning when you gain enough information to know you need
| to isn't a failure -- _not_ re-planning then would be -- but
| repeatedly finding yourself re-planning when you had or should
| have had that information before the initial plan is.
| csours wrote:
| > SEEN as failure
|
| emphasis added
| thfuran wrote:
| Yes, and rightly so, sometimes.
| csours wrote:
| Yes, sometimes, but negotiating this can be the whole
| ballgame.
| js8 wrote:
| 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 wrote:
| > technically it is irrational
|
| Only if your company operates in a vacuum, without investors or
| customers
| poguemahoney wrote:
| 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.
| codingdave wrote:
| 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 wrote:
| 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?
| TheOccasionalWr wrote:
| 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 wrote:
| I think that we are agreeing that Kanban and estimates
| aren't really analogous
| ecaradec wrote:
| 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.
| codingdave wrote:
| Kanban avoids pre-conceived release dates. Sorry if my
| comments on estimates muddied that point, but the takeaway
| should be that whether you use estimates or not, release
| dates are the root of the problem.
| zkmon wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| The attitude with belief that software work cannot be
| compared with any other work in other domains, is not
| going to help. There are far more complex projects out
| there. Complexity is not feature limited to the work
| artifacts. It could arise from overall context - funding,
| worker issues, climate, raw material, political factors,
| technical issues. But still, estimates can't be avoided.
| louthy wrote:
| > The attitude with belief that software work cannot be
| compared with any other work in other domains, is not
| going to help.
|
| I didn't say that, at all. But it is an extreme form of
| abstract complexity which is different to the more
| tangible and physical complexity that you might have in
| say a jet engine. That is not to say a jet engine isn't
| complex, it is and obviously so; but in many ways I think
| most people don't fully understand the extreme complexity
| of a medium to large software project because, on the
| surface, we've apparently captured a lot of it behind
| reusable libraries and the like. The reality is much more
| nuanced due to the fact that most software engineering is
| not following a technique of provably sound composition
| of components and therefore complexity emerges and is a
| sum of its parts. That summing of complexity creeps up on
| a development team and emerges as bugs, security issues,
| difficulty in planning, and difficulty in maintenance,
| etc.
|
| My singular argument is: reduce complexity, improve
| predictability.
|
| > But still, estimates can't be avoided.
|
| I also didn't state that estimates can be avoided. I ran
| a tech company for 20 years and I needed to be able to
| tell everyone else in the company when things are likely
| to be done. That's just a fact of life.
| jph wrote:
| 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
|
| 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 wrote:
| 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://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.
| Marsymars wrote:
| > 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.
| TheOccasionalWr wrote:
| So now you have 4 wrong estimates to work with :) To have some
| predictability you should have small features. That's the only
| thing that can give you strong estimates. No industry has
| solved giving strong and correct estimates - it's in the name,
| it's estimation!
| torginus wrote:
| This sounds like that if you don't trust a fortune teller, you
| can mitigate it by going to 4 different fortune tellers, and
| then somehow combining their predictions into your much more
| certain future.
| yen223 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| camel_gopher wrote:
| A rule that has suited me well is to take an estimate,
| double it, and increase by an order of magnitude for
| inexperienced developers. So a task the say would take
| two weeks ends up being 4 months. For experienced
| developers, halve the estimate and increase by an order
| of magnitude. So your 10 days estimate would be 5 weeks.
| yetihehe wrote:
| 10 days was already after I used this algorithm. Previous
| several tasks on that codebase were estimated pretty
| good. Problem with this is that some tasks can indeed
| take SEVERAL orders of magnitude more time that you
| thought.
|
| One of the hardest problems with estimating for me is
| that I mostly do really new tasks that either no one
| wants to do because they are arduous, or no one knows how
| to do yet. Then I go and do them anyway. Sometimes on
| time, mostly not. But everybody working with me already
| knows, that it may be long, but I will achieve the
| result. And in rare instances other developers ask me how
| did I managed to find the bug so fast. This time I was
| doing something I have never before done in my life and I
| missed some code dependencies that needed changing when I
| was revieving how to do that task.
| QuercusMax wrote:
| The biggest estimation effort I ever took part in was a
| whole-system rewrite[1] where we had a very detailed
| functional test plan describing everything the system
| should do. The other lead and I went down the list,
| estimated how long everything would take to re-implement,
| and came up with an estimate of 2 people, 9 months.
|
| We knew that couldn't possibly be right, so we doubled
| the estimate and tripled the team, and ended up with 6
| people for 18 months - which ended up being almost
| exactly right.
|
| [1]: We were moving from a dead/dying framework and
| language onto a modern language and well-supported
| platform; I think we started out with about 1MLOC on the
| old system and ended up with about 700K on the rewrite.
| bdangubic wrote:
| I'll send my friend that has a construction company to
| build your next 3500 sq ft house for $13.6 million
| dollars :)
| bumby wrote:
| Something often overlooked in cost/schedule estimates is
| the nature of joint probability of actions slipping.
| Action A slips and causes action B to slip. I think
| software is tougher to estimate because the number of
| interfaces is often much higher, and sometimes more
| hidden, than in hardware.
| bdangubic wrote:
| as opposed to say building a house where framing can
| totally slip while we run electricity and build a roof
| floating in mid-air
|
| software is only tougher to estimate if incompetent
| people (vast majority of the industry, like 4+ million)
| is doing the estimating :)
| Scarblac wrote:
| That's a factor four or five ir so, so still less than an
| order of magnitude.
| njovin wrote:
| The next natural progression of this line of discussion
| between "the business" and engineering is for them to agree
| on a time range as an estimate. Engineering doesn't want to
| say it'll be done in 6 weeks, but they feel okay saying it
| will take between 4 and 20 weeks so this estimate is
| accepted.
|
| You can guess what happens next, which is that around week
| 8 the business is getting pretty angry that their 4-week
| project is taking twice as much time as they thought, while
| the engineering team has encountered some _really_ nasty
| surprises and is worried they 'll have to push to 24 weeks.
| skeeter2020 wrote:
| it is still better to give a range though because 1. it
| explicitly states the degree of unknown and 2. no boss is
| going to accept 4-20 weeks, which means you start talking
| about how you can estimate with better accuracy and the
| work required to do so, which is a major goal of planning
| & estimation.
| zdragnar wrote:
| There's two things here that get overlooked.
|
| First, people asking for estimates know they aren't going
| to get everything they want, and they are trying to
| prioritize which features to put on a roadmap based on the
| effort-to-business-value ratio. High impact with low effort
| wins over high impact high effort almost every time.
|
| Second, there's a long tail of things that have to be
| coordinated in meat space as soon as possible after the
| software launches, but can take weeks or months to
| coordinate. Therefore, they need a reasonable date to pick-
| think ad spend, customer training, internal training,
| compliance paperwork etc.
|
| "It is impossible to know" is only ever acceptable in pure
| science, and that is only for the outcome of the
| hypothesis, not the procedure of conducting the experiment.
| skeeter2020 wrote:
| My take: if they have not done the work to get to at
| least some degree of a spec, and they won't give you time
| to review and investigate, they get nothing more than a
| vague, relative t-shirt size.
| collingreen wrote:
| > "as soon as possible after the software launches"
|
| This isn't true, just desired, and is one of the main
| roots of the conflict here. OF COURSE you would like to
| start selling in advance and then have billing start with
| customers the instant the "last" pr is merged. That isn't
| a realistic view of the software world though and
| pretending it is while everyone knows otherwise starts to
| feel like bad faith. Making software that works, then
| having time to deploy it, make changes from early
| feedback, and fix bugs is important. THEN all the other
| business functions should start the cant-take-back parts
| of their work that need to coordinate with the rest of
| the world. Trying to squeeze some extra days from the
| schedule is a business bet you can make but it would be
| nice if the people taking this risk were the ones who had
| to crunch or stay up all night or answer the page.
|
| Trying to force complicated and creative work into a fake
| box just so you can make a gantt chart slightly narrower
| only works on people a couple times before they start to
| resent it. 10x that if management punishes someone when
| that fantasy gantt chart isn't accurate and 100x that if
| the one punished is the person who said "it's impossible
| to know" and then was forced into pretending to know
| instead of the person doing the forcing.
| SoftTalker wrote:
| The last director I had would ask "is it a day, a week, a
| month, or a year" he understood that's about as granular as
| it's possible to be.
|
| And he really only used them in comparison to estimates for
| other tasks, not to set hard deadlines for anything.
| skeeter2020 wrote:
| This is essentially t-shirt sizing without all the baggage
| that comes from time. Your boss is trying to use the
| relative magnitude but it's inevitable that people will (at
| least internally) do math like "7 day tasks is the same as
| one week task", or worse over-rotate on the precision you
| get from day/week/month, or even worse immediately map to
| the calendar. Suggestion: don't use time.
| cnity wrote:
| If you pretend not to use time, everyone will do an
| implicit time mapping in their head anyway. I've never
| seen it go any other way.
| seviu wrote:
| Surprisingly prob yes
|
| But still we are much better at estimating complexity
|
| Time estimations usually tends to be overly optimistic. I
| don't know why. Maybe the desire to please the PO. Or the
| fact that we never seem to take into account factors such
| as having a bad day, interruptions, context switch.
|
| T-shirt sizes or even story points are way more
| effective.
|
| The PO can later translate it to time after the team
| reaches certain velocity.
|
| I have been developing software for over twenty years, I
| still suck at giving time estimates.
| XorNot wrote:
| Knowing nothing else about him, I like him based on this
| alone.
|
| I've been in planning sessions where someone would
| confidently declare something would take half a day, was
| surprised when I suggested that it would take longer then
| that since they were basically saying "this'll be finished
| mid-afternoon today"...and was still working on it like 3
| weeks later.
| dgunay wrote:
| Besides the usual unknown unknowns, I've also seen this
| happen with tasks that involve a lot of coordination in
| the SDLC. Oh the PR went up at at 2pm PST? Coworkers in
| EST won't review it until tomorrow. Maybe some back and
| forth = another day until it clears review. Then QA
| happens. QA is heavily manual and takes a few hours,
| maybe with some false starts and handholding from
| engineering. Another day passes. Before you know it the
| ticket that took an hour of programming has taken a week
| to reach production.
| fallinditch wrote:
| Here's my observation: ballparking an estimate for a whole
| project, in my experience, tends to be more accurate than
| estimating each task and adding them together.
|
| I like to think of this as 'pragmatic agile': for sure
| break it down into tasks in a backlog, but don't get hung
| up on planning it out to the Nth degree because then that
| becomes more waterfall and you start to lose agility.
| Scarblac wrote:
| > I honestly don't know what the PO and TL gains with this
| absurd obscenity
|
| There are marketing campaigns that need to be set up, users
| informed, manuals written. Sales people want to sell the new
| feature. People thinking about road maps need to know how
| many new features to can fit in a quarter.
|
| Development isn't the only thing that exists.
| Scarblac wrote:
| Another reason is that figuring out what the software to be
| written should actually do, and how it should work, is work
| that is part of the project and the time it will take needs to
| be estimated.
|
| As well as the actual development work that will result, which
| isn't known yet at the time of estimation.
| IanCal wrote:
| Repetitive and easy or worth automating are not the same. The
| fundamental problem is that a setup capable of solving any of
| the requests that come to it is as complex as just a whole
| programming language and then you're back to square one.
| wpietri wrote:
| And I'd add that the need for them is a sign they aren't worth
| doing.
|
| As you say, worthwhile software is usually novel. And to
| justify our expense, it needs to be valuable. So to decide
| whether a project is worth doing, we're looking at some sort of
| estimate of return on investment.
|
| That estimate will also, at least implicitly, have a range.
| That range is determined by both the I and the R. If you don't
| have a precise estimate of return, making your estimate of
| investment more precise doesn't help anything. And I've never
| seen an estimate of return both precise and accurate; business
| is even less certain than software.
|
| In my opinion, effort put into careful estimates is almost
| always better put into early, iterative delivery and product
| management that maximizes the information gained. Shipping
| early and often buys much clearer information on both I and R
| than you can ever get in a conference room.
|
| Of course all of this only matters if running an effective
| business is more important than managerial soap opera and
| office politics. Those often require estimates in much the same
| way they're required from Star Trek's engineers: so the people
| with main character syndrome have something to dramatically
| ignore or override to prove their dominance over the NPCs and
| material reality.
| bpt3 wrote:
| The solution you described is basically agile, and that
| definitely includes estimates and deadlines.
| Mtinie wrote:
| It's Agile philosophically, and how it should be.
|
| But that is rarely how it works. In the dozens of different
| projects across ten or twelve companies I've had insight
| into, "doing Agile" is analogous with "we have a scrum
| master, hold stand ups, and schedule iterations" while the
| simple reality is "Agilefall."
| bpt3 wrote:
| Agreed, but the parent poster said that estimates
| shouldn't be done at all, which is not a legitimate
| argument to make in any scenario.
| collingreen wrote:
| I, and others, don't agree with the blanket statement
| that "no estimates" is not a legitimate argument in any
| scenario. Can you expand on why you think there isn't a
| single case where estimates don't add value? Similarly,
| is there anything specifically in that post's claims that
| you think was incorrect, leading to their false
| conclusion?
| wild_egg wrote:
| I missed that part of the manifesto
| mpyne wrote:
| There are agile methods that forgo estimates and deadlines
| though
|
| This is what "agile" is: https://agilemanifesto.org/
|
| More specific methodologies that say they are agile may use
| concepts like estimates (story points or time or whatever),
| but even with Scrum I've never run into a Scrum-imposed
| "deadline". In Scrum the sprint ends, yes, but sprints
| often end without hitting all the sprint goals and that, in
| conjunction with whatever you were able to deliver, just
| informs your backlog for the next sprint.
|
| Real "hard" deadlines are usually imposed by the business
| stakeholders. But with agile methods the thing they try to
| do most of all isn't manage deadlines, but maximize pace at
| which you can understand and solve a relevant business
| problem. That can often be just as well done by iteratively
| shipping and adjusting at high velocity, but without a lot
| of time spent on estimates or calendar management.
| davidhyde wrote:
| < "Those often require estimates in much the same way they're
| required from Star Trek's engineers: so the people with main
| character syndrome have something to dramatically ignore or
| override to prove their dominance over the NPCs and material
| reality."
|
| This is so good.
| 9dev wrote:
| > As you say, worthwhile software is usually novel.
|
| This is an interesting assumption. I'd argue that the
| overwhelming majority of software is the most boring LoB CRUD
| apps you can imagine, and not novel at all. Yet, people need
| to estimate the tasks on these projects as well.
| wpietri wrote:
| And starting in the late 1970s, there were tools available
| to simplify building LoB CRUD apps. [1] That has continued
| with things like Rails and Salesforce and no-code tooling.
|
| If something is truly boring in software, it gets turned
| into a library or a tool for non-programmers to use. Our
| value is always driven by the novelty of the need.
|
| And no, people don't need to estimate the tasks. My dad did
| LoB apps in the 1970s to the 1990s. E.g., order entry and
| shop floor management systems for office furniture
| factories. His approach was to get something basic working,
| see how it worked for the users, and then iteratively
| improve things until they'd created enough business
| advantage and/or cost savings to move on. Exploratory,
| iterative work like that can at best be done with broad
| ballpark estimates.
|
| I grant that people _want_ estimates. But that is usually
| about managerial fear of waste and /or need for control.
| But I think there are better ways to solve those problems.
|
| [1] e.g., https://en.wikipedia.org/wiki/DBase
| bpt3 wrote:
| If software developers want to be then seriously as a
| profession, they need to be able to provide and justify
| estimates for their work.
|
| Everything you said could apply to a new bridge, building,
| pharmaceutical compound, or anything else that is the result of
| a process with some known and some unknown steps.
| XorNot wrote:
| Pharmaceutical compounds frequently don't make it to market
| after significant investment.
|
| No one in that industry is giving estimates based on
| developing brand new drugs - they're giving estimates related
| to manufacturing lead times, unalterable physics time lines,
| and typical time to navigate administrative tasks which are
| well known and generally predictable (but also negotiable:
| regulations have a human on the other end). All of this
| _after_ they have a candidate drug in hand.
|
| Same story with bridge building basically: no one puts an
| estimate on coming up with a brand new bridge design: they're
| a well understood, scalable engineering constructions which
| are the mostly gated by your ability to collect the data
| needed to use them - i.e. a field survey team etc. - and also
| once again, regulatory processes and accountability.
| bpt3 wrote:
| Yes, that's my point. There's way more uncertainty in
| trying to bring a new drug to market or build a new bridge
| than creating yet another CRUD app, yet somehow they are
| any able to break these efforts into tasks that can be
| estimated and tracked and many software engineers think
| they should be exempt from any accountability to schedule
| or budget.
| wild_egg wrote:
| > Everything you said could apply to a new bridge, building,
| pharmaceutical compound
|
| "Everything"? So
|
| > 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.
|
| Also applies to bridges? Bridges require a ton of manual
| human input at every stage of construction, regardless of how
| predictable and repetitive the work is. With software, we can
| write software to make those tasks disappear. I've yet to see
| the bridge that can build itself.
| bpt3 wrote:
| 1. When you have meaningful software that can build itself
| (and I'm not talking about the compilation process), let me
| know.
|
| 2. You can estimate the duration of each step of a process,
| regardless of how much human involvement is required.
| raw_anon_1111 wrote:
| There is very little novel about most B2B CRUD and internal
| bespoke apps that most developers are doing. The novel part if
| any is implementing the business vertical logic
| vegetablepotpie wrote:
| As a project manager, it sounds like you're making excuses.
| Just give me a number, trust your gut!
|
| We have a fundamental failure to communicate, _what_ we 're
| doing. The game project managers and finance believe we're all
| playing is a _regression towards the mean_ , where everything
| is additive and rounds up to nice consistent formulaic sums.
| Whereas software development follows power law distributions. A
| good piece of software can deliver 10x, 100x, or 1000x the cost
| to produce it (ex: distribution, cost of delivering another
| copy of software is near 0 once written). You don't get that
| sort of upside with many other investments. Finance is happy
| with an NPV 8% above what they invest in. This means that when
| software people talk, everything they say sounds foreign, and
| everyone assumes it's because of jargon. It's not. The fish
| don't know they're swimming in water. When the fisherman comes,
| everyone is caught off guard.
|
| So we get what the author talks about
|
| > The estimates stopped being estimates. They became safety
| railings against being held accountable for unreasonable
| expectations.
|
| We. Pad. Like. Crazy. Yes this is inefficient. Some project
| managers recognize this. We get theory of constraints. But
| rather than cull the layers of hierarchy that lead to the
| padding in the first place, all the blame for failure goes back
| to developers. Get hit on the head enough and you will stop
| acting in good faith and pad to save your ability to feed and
| cloth yourself.
| joombaga wrote:
| It's not obvious to me that we should avoid padding, or why
| it's seen as undesirable.
| vegetablepotpie wrote:
| Padding ties up capital, it reduces credibility, it delays
| deployment, it adds costs through delay. It is bad for
| organizations. However, it is a great solution if you're a
| worker in a bureaucratic environment that can tolerate
| large costs, but is intolerant of 1-day of schedule slips.
| It's a great solution for complacent management, who are
| confused about the game they're playing and wants to report
| that they're "on track", which means "not late".
|
| The _agile_ solution of incremental value delivery is a
| compromise, and can produce good outcomes for functional
| changes. But agile has unacceptable failure modes when
| working on infrastructure and satisfying system
| constraints. Agile can work okay for programmers, but it 's
| not a solution for _engineers_. Acknowledging, owning, and
| managing risk is more scalable, but you have to have
| leaders who acknowledge that they exist and have the
| maturity to take on that responsibility.
| Trasmatta wrote:
| > As a project manager, it sounds like you're making excuses.
| Just give me a number, trust your gut!
|
| If we're just making up numbers, why don't you just make it
| up yourself and save the developers the trouble?
| vegetablepotpie wrote:
| Ah! But I want you to _own_ it. If you say it first... you
| own it. And I do not have to get you to agree to it.
| lloeki wrote:
| From another thought-experiment-y perspective:
|
| Say you have problem A to solve. Then either one of those is
| true:
|
| 1) it has been solved before, ergo by virtue of software having
| a zero cost of copying (contrary to, say, a nail, a car, or a
| bridge), so there is no actual problem to be solved.
|
| 2) it hasn't been solved before, ergo it is a _new_ problem,
| and thus at any moment you may turn a stone and discover
| something that was not foreseen (whether they are rabbits,
| yaks, bikesheds, dragons, or what have you eldritch horrors)
| and thus of unknown cost.
|
| Any task that cannot be obviously fit into one or the other can
| nonetheless be split into an assembly of both.
|
| Thus any attempt at estimates is as futile as gambling to win,
| tasks are only ever done when they're done, and "successful
| estimators" are kings of retconning.
|
| It's all make-believe.
| epolanski wrote:
| 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 wrote:
| 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 wrote:
| > but occasionally they will run over
|
| 86% is more than "occasionally".
| epolanski wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| In those cases, you should be asked for estimates to eliminate
| the unknowns.
| chickensong wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| twerka-stonk wrote:
| 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.
| rendall wrote:
| The Fibonacci scale isn't sacred; it's just a coarse, non-
| linear scale that keeps people from pretending to have more
| precision than they actually have. Any non-linear sequence
| would work as long as it forces you to acknowledge
| uncertainty as the numbers grow.
|
| As for "just estimate in time," the problem is that teams are
| consistently bad at doing that directly. Mixing "how hard is
| this" with "how long will it take" collapses two separate
| variables: intrinsic complexity and local throughput. Story
| points deliberately avoid that conflation. The team's
| velocity is what translates points into time at the sprint
| level, and that translation only stabilizes if the underlying
| unit is complexity rather than hours.
|
| The whole point of the method is to strip away the illusion
| of precision. Time estimates look concrete, but they degrade
| immediately under uncertainty and project pressure. Relative
| complexity estimates survive discussion, converge reliably,
| and don't invite the fallacy that a complex task with a high
| risk of surprises somehow has an exact hour count.
|
| That's why the technique exists. Estimating time directly
| sounds simpler, but in practice it produces worse forecasts
| because it hides uncertainty instead of exposing it.
| freehorse wrote:
| 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 wrote:
| 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.
| hi_hi wrote:
| 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.
| sema4hacker wrote:
| 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 wrote:
| The one I heard was estimate, double it, and move to the next
| higher unit. 2 days? Nope, that's 4 weeks.
| mono442 wrote:
| 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 wrote:
| Maybe software industry should learn from other industries where
| people don't see estimates as something unthinkable?
| ricksunny wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 was previously
| in the way of forming the group dynamics we have now.
|
| 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.
| patrickmay wrote:
| This is a fantastic description of why Technical Program
| Managers (TPMs) can be force multipliers. Imagine involving
| someone who understands both the needs of Product and
| Engineering and whose job it is to allow both of them to
| focus on where they add the most value. We do exist!
| torginus wrote:
| Which if you try to do - those agile people will kill you for
| it.
|
| They wrangle a number out of you which goes into an user story
| estimate, which feeds into a Gantt chart they use to make their
| pretty powerpoints they present to upper management to say that
| the feature will make it into the Q4 release.
|
| If you move this number around the whole estimation will
| crumble, not that it wont in real life but you deprave them of
| two things - an illusion of control and somebody to blame when
| things go south.
| bdangubic wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| The biggest problem I've seen isn't the estimate itself but the
| telephone game that happens after. You say "probably 2-3 weeks"
| to your manager, who tells the PM "about 2 weeks", who tells
| sales "mid-month", who tells the customer "the 15th".
|
| By the time it reaches the customer, your rough guess with
| explicit uncertainty has become a hard commitment with legal
| implications. And when you miss it, the blame flows backward.
|
| What's worked for me: always giving estimates in writing with
| explicit confidence levels, and insisting that any external date
| includes at least a week of buffer that I don't know about. That
| way when the inevitable scope creep or surprise dependency shows
| up, there's room to absorb it without the fire drill.
| twerka-stonk wrote:
| 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 wrote:
| scrum lingo is silly because scrum itself is stupidity squared
| and hence the lingo also cannot be anything but that
| CrzyLngPwd wrote:
| 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%)
| pyrolistical wrote:
| 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 wrote:
| _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 wrote:
| Why is that a problem? It is an estimate. Not a hard
| commitment.
|
| By definition estimate can be wrong
| bdangubic wrote:
| thats fantastic as long as you are not the one paying for
| it
| deely3 wrote:
| How often you spend a week doing 2-day job?
| bdangubic wrote:
| 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
| Animats wrote:
| 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.
| osigurdson wrote:
| 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 wrote:
| An LLM's guess is as good as anyone's.
| hal-eisen wrote:
| https://youtu.be/QVBlnCTu9Ms?si=k_UolNc2o6UFGS9f
|
| #NoEstimates
|
| Yes, be agile. Yes, measure all the things.
|
| But estimation sets everyone up for disappointment.
| alphazard wrote:
| 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 wrote:
| 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".
| pizzafeelsright wrote:
| 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 wrote:
| I always say, "it's a prediction, not a promise."
| spjt wrote:
| 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 wrote:
| 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 wrote:
| this feels like language from another era
___________________________________________________________________
(page generated 2025-12-07 23:00 UTC)