- 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.
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.
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.
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.
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
What if the project involves trying one approach for a week, then assessing whether that approach still looks viable vs moving onto a different approach? This happens a lot with challenging projects, you basically just keep trying different things until one works.
Then you know that it's going to take at least, say two weeks, one week for the first implementation and a week to finish it if it works.
On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period.
So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending effort to narrow the estimate?
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 ;(
This why you should use confidence intervals for estimates. Use a 80% confidence interval, for example. 10% of the time, you should come in under the best case estimate. 10% of the time, it should take longer than the worst case estimate.
How do you know if your estimate is good? Would you rather bet on your estimate or on hitting one of 8 numbers on a 10-number roulette wheel? If you prefer one of the bets, adjust your estimates. If you're indifferent between the bets, the estimates accurately reflect your beliefs.
That’s why time limiting rather than estimating works for me. It forces me to contend with the question: “can I get this done today?” That’s usually an easier question to answer because it’s to tightly time bound. I’m not always correct but I’ll know tomorrow if I wasn’t, rather than next month!
When I’m asked on longer time frames, I’m much less confident but it’s still more concrete than the other way around.
It really depends. Anyone doing meaningful work will have hard time giving estimates.
But churning up the next CRUD application with now special requirements can have no unknown variables. The question of course remains, why would anyone want to waste their time reinventing a spreadsheet.
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)
I've worked on codebases all the way tens of millions of lines of code. Obviously not in the sense of knowing all the dusty corners of such codebases, but still, I did enough work on them that I had to navigate my way around millions of loc. It's not easy! The problem is that you can't possibly know even a sizeable fraction of such a codebase well. Instead you can know small corners well and know your way around the internal and external interfaces so you can find gotchas and answer questions as you research. The knowledge you build is hard to communicate to others, too, so bringing others up to speed is not easy either. So for me TFA hits all the right notes.
But I've also seen things like the ZFS team at Sun deliver something unbelievably good that started as a skunkworks project that senior management didn't really know about until there was enough to show to justify a large investment. Sun was like DARPA: not micromanaged from the top. Sun failed, of course, but not because of this.
That I wouldn't know, but I know it took longer than anticipated, and towards thee end Sun pulled a lot of engineers from other projects and put them on ZFS for the final push.
^ This report from 2020 analyzed about 50,000 IT projects in a wide range of market segments, and they found that 50% exceeded their deadline. This seems to suggest that your conclusion holds more generally than just your specific context.
On a personal level, I hardly ever see a developer's estimate turn out to be right, on whatever scale. I'm wondering what the pro estimate folks in this thread work on that they're able to estimate accurately.
> 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.
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.
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.
I've been on teams that tried various methods of estimating and the issue I always encounter is that everyone estimates work differently, but usually people will side with the person with the most context.
For instance someone says a ticket is two days' work. For half the team that could be four days because people are new to the team or haven't touched that codebase, etc. But because the person who knows the ticket and context well enough says 2, people tend to go with what they say.
We end up having less of those discussions you describe to come to an agreement that works more on an average length of time the ticket should take to complete.
And then the org makes up new rules that SWEs should be turning around PRs in less than 24 hours and if reviews/iterating on those reviews takes longer than two days then our metrics look bad and there could be consequences.
Remember, estimation is in points not days. It doesn't matter if it's 2 days work for a senior engineer or 4 days for junior devs, it's still the same number of points, e.g. 8 points. This is intentional. Skill is accounted for in the fact that a team of all senior devs might deliver 200 points a sprint, whereas if half the senior devs got replaced with junior devs the team might only deliver 100. This is intentional, so that estimation is about the team, not any person.
And yes, when there's a task that one person happens to know most, people will often defer to them. But that in itself is educational, as the experienced dev explains why the given task is easy/hard. And every task is different, so the person you're deferring to will be different, and you still often get the two or three people who know the task best disagreeing until they hash it out, etc. And very often it's another person who can point out "well it would be that easy except three sprints ago I did x and so you'll now need to do y...". And of course plenty of tasks really are brand-new so everyone's figuring it out together.
If you're really not having actual discussions around complexity in planning poker, then the facilitator/lead/manager might be doing it wrong. You do have to create an environment where people are expected to speak up and disagree, to demonstrate that this is welcomed and expected and rewarded, and not just some kind of checkbox exercise where the most senior dev gives their estimation and everyone agrees. This is also a reason why it's literally done with cards where everyone is forced to put their number on the table at the same time, so that you don't wind up with some senior person always going first and then everyone else just nodding and agreeing.
I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing.
I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.
> I've never met someone for whom points didn't eventually turn into a measurement of time
The goal isn't to avoid time estimation completely, that would be crazy. People estimate how many points get delivered per sprint and sprints have fixed lengths of time. You can do the math, you're supposed to.
The process is quite easy to implement. And it does wind up with extraordinary efficacy gains on a lot of teams, that's the whole reason why it's so popular. But you do have to actually learn about it. Here:
If it works for you, then it's a good method, but in my opinion the most transparent way to avoid a false sense of precision for time estimation (as with all else) is by explicitly including error bars, rather than changing the units-of-measure.
Error bars are complicated, and who's to say how large they should be? It winds up being a lot of pointless arguing over arbitrary precision.
The Fibonnaci sequence of point values has wound up just being a lot simpler for most people, as it encapsulates both size and error, since error tends to grow proportionally with size.
I.e. nobody is arguing over whether it's 10h +/- 1h, versus 12h +/- 1h, versus 12h +/- 2h, versus 11h +/- 3h. It's all just 5 points, or else 8 points, or else 13 points. It avoids discussion over any more precision than is actually reliably meaningful.
I worked on a product that was built around planning an estimation with ranged estimates (2-4h, 1-3d, etc)
2-12d conveys a very different story than 6-8d. Are the ranges precise? Nope, but they're useful in conveying uncertainty, which is something that gets dropped in any system that collapses estimates to a single point.
That said, people tend to just collapse ranges, so I guess we all lose in the end.
In agile, 6-8d is considered totally reasonable variance, while 2-12d simply isn't permitted. If that's the level of uncertainty -- i.e. people simply can't decide on points -- you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing once you have a more accurate estimate. You would never just blindly decide to do it or not if you had no idea if it could be 2 or 12 days. That's a big benefit of the approach, to de-risk that kind of variance up front.
> you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing
That's just too slow for business in my experience though. Rightly or wrongly, they want it now, not in a couple of sprints.
So what we do is we put both the investigation and the implementation in the same sprint, use the top of the range for the implementation, and re-evaluate things mid-sprint once the investigation is done.
Of course this messes up predictability and agile people don't like it, but they don't have better ideas either on how to handle it.
Not sure if we're not enough agile or too agile for scrum.
That's definitely one way of doing it! And totally valid.
I think it often depends a lot on who the stakeholders are and what their priorities are. If the particular feature is urgent then of course what you describe is common. But when the priority is to maximize the number of features you're delivering, I've found that the client often prefers to do the bounded investigation and then work on another feature that is better understood within the same sprint, then revisit the investigation results at the next meeting.
But yes -- nothing prevents you from making mid-sprint reevaluations.
If you measure how long a hundred "3-day tasks" actually take, in practice you'll find a range that is about 2-12. The variance doesn't end up getting de-risked. And it doesn't mean the 3-day estimate was a bad guess either. The error bars just tend to be about that big.
If a story-sized task takes 4x more effort than expected, something really went wrong. If it's blocked and it gets delayed then fine, but you can work on other stories in the meantime.
I'm not saying it never happens, but the whole reason for the planning poker process is to surface the things that might turn a 3 point story into a 13 point story, with everyone around the table trying to imagine what could go wrong.
You should not be getting 2-12 variance, unless it's a brand-new team working on a brand new project that is learning how to do everything for the first time. I can't count how many sprint meetings I've been in. That level of variance is not normal for the sizes of stories that fit into sprints.
I think it really depends on how teams use their estimates. If you're locking in an estimate and have to stick with it for a week or a month, you're right, that's terrible.
If you don't strictly work on a Sprint schedule, then I think it's reasonable to have high variance estimates, then as soon as you learn more, you update the estimate.
I've seen lots of different teams do lots of different things. If they work for you and you're shipping with reliable results then that's excellent.
Having implemented it myself, I agree it is easy to implement. My argument is that it is overly difficult to maintain. My experience is that incentives to corrupt the point system are too high for organizations to resist.
Funnily enough - I work closely with a former director of engineering at Atlassian (the company whose guide you cite) and he is of the opinion that pointing had become "utterly dishonest and a complete waste of time". I respect that opinion.
If you have citations on pointing being effective I'd be very interested. I consider myself reasonably up to date on SWE productivity literature and am not aware of any evidence to that point - I have yet to see it.
I guess my experiences are quite the opposite. Maintaining the process couldn't be easier. I don't even know what it means to "corrupt" points...? Or for points to become "dishonest"? I'm genuinely baffled.
I'm not aware of any citations, just like I'm not aware of any citations for most common development practices. It seems to be justified more in a practical sense -- as a team or business, you try it out, and see if it improves productivity and planning. If so, you keep it. I've worked at several places that adopted it, to huge success, solving a number of problems. I've never once seen a place choose to stop it, or find something that worked better. If you have a citation that there is something that works better than points estimation, then please share!
It's just wisdom of the crowds, or two heads are better than one. Involving more people in making estimates, avoiding false precision, and surfacing disagreement -- how is that not going to result in higher-quality estimates?
By "dishonest" I'm saying they become measurements of time, which is what we were trying to avoid.
Stepping back - my experience is that points are solving a problem good organizations don't have.
The practice I see work well is that a senior person comes up with a high level plan fror a project with confidence intervals on timeline and quality and has it sanity checked by peers. Stakeholders understand the timeline and scope to be an evolving conversation that we iterate on week-by-week. Our rough estimates are enough to see when the project is truly off-track and we can have a discussion about timelines and resourcing.
I just don't see what points do for me other than attempt to "measure velocity". In principle there's a metric that's useful for upper management, but the moment they treat it as a target engineers juice their numbers.
"estimation is in points, not days" doesn't tell me anything. Is not like tasks have an intrinsic attribute that everyone can agree on (e.g. the sky is blue)
How are you estimating the points if not thinking about how hard the task is for you and how long is it going to take you?
And then another matter is that points do not correlate to who later takes that work. If you are 5 seniors and 3 juniors and average on a task being a 3, but the task falls to a junior, they will take longer as is expected for his experience.
Points are not intrinstic or objective attributes, like the sky being blue. The scale is arbitrarily chosen by any given team, and relative to past work. But a common reference point is that 1 point is the "smallest" feature worth tracking (sometimes 1/2), and 20 points is usually the largest individual feature a team can deliver in a sprint. So it's common for teams to be delivering something between e.g. 50 and 200 points per sprint. Teams very quickly develop a "feel" for points.
> And then another matter is that points do not correlate to who later takes that work.
Yes, this is by design. Points represent complexity, not time. An experienced senior dev might tend to deliver 30 points per sprint, while a junior dev might usually deliver 10. If a team swaps out some junior devs for senior devs, you will expect the team to deliver more points per sprint.
So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team?
> An experienced senior dev might tend to deliver 30 points per sprint
Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time. Isn't complexity directly proportional to uncertainty factors, and therefore inversely proportional to confidence of time to completion?
> So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team?
Basically, yup. It takes a few sprints to start to establish a meaningfully reliable sense of velocity, and the estimation accuracy is why planning poker takes a couple of hours of real discussion over feature complexity, rather than just a few minutes of superficial guesses. But the end result is a far more accurate ability to estimate what a team can reliably deliver in a sprint, and is really good at bringing stakeholders down to earth in terms of what can actually realistically be delivered.
> Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time.
What's ironic? And no, it's not about "someone", it's about the the team. Different people on the team will be able to deliver different numbers of points depending on their skill, experience, etc. This is a major reason for not using time -- it actively recognizes that different people take different amounts of time, that things like sick days and meetings are taken into account, etc.
> Isn't complexity directly proportional to uncertainty factors
Yes, this is an explicit assumption of the Fibonnaci-style points usually used.
> and therefore inversely proportional to confidence of time to completion?
Yes, which is precisely why stories over a certain size are disallowed (the feature must be broken up into parts), and why sprints are measured in a very small number of weeks -- to avoid the accumulation of too much uncertainty.
I've never been involved in planning poker where everyone didn't converge on points = days at least in their own minds. "Hm, that would take me about a day, so that's one point."
Otherwise, it would be impossible to have 20-point stories done in a 10-business-day sprint! Under the usual assumption that a single person is responsible for the whole story.
For the teams I've been on, a point has usually been more like a third of a day or half a day, i.e. 2-3 hours of uninterrupted concentration, and the 1/2 point card is used rarely. Sounds like you've probably used 1/2 point stories a lot more...
But this is why points are arbitrary. Each team decides whatever precise scale it wants. And it really depends on the type of work you're doing too -- whether the smallest stories tend to be things that are day-sized or things that are 2-hour sized.
Yeah we had half-point stories. Never remember getting as high as 20. I think we topped out at about 13 and those were usually split if they could be. It's been years since I did planning poker, sort of surprised to hear that it's still in use.
Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points.
Sorry if it comes through as rude, but this is how I keep repeatedly being told story points work.
If you look at all those properties together, story points are completely useless.
The only moment time it makes sense is when you have a SHARED understanding of the smallest point AND you can translate it to time. When you do that, story points are useful. Also, they become time, so there is no reason to use points.
> Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points.
Literally none of that is anything I've ever encountered on any team.
They're not specific to a person, they're to a team.
They have nothing to do with the smallest task ever faced.
They are obviously for summing and are obviously units.
They effectively get translated into time in the sense that the team has a history of delivering an average of n points per e.g. 2 weeks.
Every person I met gave me a different statement, so I don't fail to believe you, it's just that the definition of story points is different for everybody
I'm sure everyone has their own idiosyncratic interpretations, but I believe I've got enough experience to tell you that what I'm explaining is pretty standard.
Here are literally the top two Google results for "story points" and they both seem to align entirely with what I said:
I don't doubt that what you're describing as story points is something somebody told you. I'm just telling you that their definition was highly idiosyncratic and extremely non-standard. When discussing these things, using the standard definitions is helpful.
The definition of story points like the one I have mentioned has been provided by a certified scrum master and in a different context,by a certified scrum coach.
I appreciate your effort, but I don't believe there is any formal definition.
It's redefined per team, it's redefined by the team too if needed.
So people want an estimate (uncertain) based on a number that's also nebulous. It kills me.
Use time ranges, you get a sense for risk AND have an estimated delivery date.
The adjustment people make with numbers can still be made on a per team basis using time ranges, I don't see why we have to use a proxy
> The only moment time it makes sense is when you have a SHARED understanding of the smallest point AND you can translate it to time. When you do that, story points are useful.
I’d like to disagree on that one. A single story point shouldn’t be translated to time, but should reflect the relative complexity between tasks (ie. a 7 is harder than a 3 and so on).
You could assign relative complexity based on a number of things:
- number of integrations to other systems,
- is the area well known to the team,
- is the code well tested,
- is CI/CD set up,
- do we need a lot of alignment or can we just get started,
- etc.
So you’re not estimating time, but complexity or hardness.
Then, supposing you have a stable team, you can go back six months and find out “we do on average 90 points per month” or similar
When you do what you just said "I am not estimating time, I'm estimating risk".
"This will take between 1 and 3 days" gives you both: the risk (complexity, hardness) which is represented by the gap, and time: how long it takes.
When a non engineer asks for an estimate, they usually mean one of these two things:
1. How long it takes?
2. Have you had experience with something similar before?
The second one can come also through the question "how challenging do you think that is?" To which we answer "easy but long" "hard" (never done it) or things like that. That's easier to answer, but doesn't translate to dates.
For the first one, you CANNOT use what you just described, since it doesn't represent time, so you cannot give dates in any form.
> For the first one, you CANNOT use what you just described, since it doesn't represent time, so you cannot give dates in any form.
That's the purpose of story points and planning poker. They don't represent time guarantees or delivery dates. That's not a bug, it's a feature.
They represent estimated effort, with a recognition that uncertainty is generally roughly proportional to size. Which is why point estimates are usually restricted to approximately Fibonnaci sequences values (or sometimes doubling). Often it will be limited to 1, 2, 3, 5, 8, 13, 20, where stories aren't allowed to be larger than 20 -- if they are, you need to break them apart.
So to be clear, when you say that estimates are composed of two parts -- time and risk -- planning poker intentionally conflates them into a single number. If a task is both large and truly high-risk, then it should be broken into a research story and an implementation story, where the size of the research story can be better estimated, and then implementation waits for the next sprint depending on what research tells us. If it's small and high-risk, then you basically just "try", and accept that it might not get delivered, and then revisit in the next sprint whether it's worth trying again and if it needs to be revised.
My most productive team did no time estimates at all (short of very very rough project estimates i.e. "yeah I'll work on this project for at least the next quarter then we'll see"), and instead of spending endless time in planning meetings determining how complex a task was, we instead spent that time just doing the thing.
I agree it's best if working in isolation, but if you need to synchronise then estimations make sense.
If you need 3 months to implement something, and another team 1 week, and both need to be ready at the same time; then if you actually know those estimations the second team can wait until then and do something immediately useful in between.
We do similar but sprints are somewhat flexible, more like versions. We chuck the features we want from the top of most needed, split into stories and estimate like you mentioned using brainstorming between devs and QA. Estimation happens by relatively comparing complexity of each new story compared to previously implemented stories, conservativy picking average one up if there is variance in estimates. QA is involved to determine how long it will take to test the feature or sometimes what uncertainty is there if this is even possible automatically.
In the end we have stable developer velocity metric and a really close estimate for each new version.
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...
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
Let me be clear -- nobody finds planning poker or story estimation fun. The same way nobody finds writing tests or documentation fun. So of course it'll be a breath of fresh air if it's not part of your job.
But the fact remains that in most environments, it's extremely useful for medium-term planning and especially in surfacing high-risk features that can send people down the wrong path for a long time. And it's meant to benefit stakeholders -- the people paying the developers' salaries -- not individual developers. It's about de-risking.
And if you really have the kind of team you seem to describe where everybody only works on their specific type of task and can't even estimate anybody else's work, then that's a danger situation when they leave or get sick or whatever and nobody else can step in and everyone's blocked because the only person who can do X is gone. Usually, you should be actively getting other developers to work on these features (usually the easier/smaller ones) and involving them in the estimation.
Because you often estimate something like three or four times as many tasks as actually get included in the sprint. You can't possibly know in advance which features will actually wind up in the sprint until you've considered all the possible candidates. You estimate, then the PM confers with stakeholders to prioritize what's actually most important and figure out the "puzzle" of which pieces add up to a coherent sprint, and then work starts.
To the developer, it seems like short-term sprint planning. But to the PM and stakeholders, it's very much medium-term planning because they're picking tasks for this sprint in light of what they also estimate the following couple sprints will look like (given current information, which is always going to change).
It's not as bad as it sounds, because when you're re-estimating something you already estimated in the past 2 planning pokers, it's usually pretty quick. You're just seeing if the previous estimate needs to be revised based on what the team has learned since. Most time is usually spent on newly proposed features, or features that have significantly changed or been split up.
> The same way nobody finds writing tests or documentation fun
I'm not sure if it's the fun category, but at least they are useful and because of that, satisfying to do. In fact when I finish a solid suite of tests or good, clear documentation, I find it very satisfying. I can't say the same for poker/estimation. I've found to be them a complete waste of time in every job I've had and therefore soul sucking.
> you seem to describe where everybody only works on their specific type of task and can't even estimate anybody else's work, then that's a danger situation when they leave or get sick or whatever and nobody else can step in and everyone's blocked because the only person who can do X is gone
you're conflating the ability to estimate accurately with the ability to implement.
Just because I can't estimate a task accurately doesn't mean I can't do it.
Estimates are for the team, not for an individual.
As the team grows and shrinks, the number of points delivered per sprint are expected to similarly rise and fall. A new person joining will likely take time to ramp up the number of points they're contributing.
Because, for whatever psychological reason, estimating in time leads to a false sense of accuracy, people pointlessly argue over whether something will take 5 days vs. 6, and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc.
Estimating in points that are basically a Fibonacci sequence keep estimation precision limited and avoids implying false guarantees. Yes, in the end the chosen stories are based on summing to a number of points that is roughly equivalent to what the team has achieved per-sprint in the recent past, so in that sense it is ultimately estimating days in the end. But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep both team expectations and management expectations more reasonable.
Can't you do that by just limiting the precision? You can only vote 1, 2, 3, 5 or 8 days. Not sure what "points" are adding. As far as I can tell, it's an attempt to account for estimation difficulties by introducing a "velocity" concept. But I think it makes things more complex without actually solving the issue.
> and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc.
> But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep both team expectations and management expectations more reasonable.
The post is about project planning, not sprint planning.
> It prevents you from estimating things longer than a sprint, because it assumes that's impossible.
And yet, management wants estimates for a whole project. Projects have to get paid for somehow, and project estimates are a key part of that in many many organizations. Ever wonder why government IT is SO BAD?
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.
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.
Oof. Exactly. Simple things get complicated when you find out that there were unstated requirements, hidden booby traps, etc. And then there's random interrupts -- unrelated stuff that comes up and takes your time and focus. If you run a lean ship then interrupt management is critical, but ideally you can have a few people who are understood to take critical interrupts and thus their schedules will slip.
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.
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.
> 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).
The PMI project management methodology even pre-scribes this (after the project is over, to reflect, and then to gather collected learnings and objective stats so as to help better estimation of future projects), but the problem is many engineers see project management a administrative burden rather than as a tool, and they have a tinkerer's mind-set rather than a scientist's mind-set.
Good project management practice is also not to use
point estimates but intervals: something is going to take "betweek [i;j] person days". PERT-estimates are even three-point estimates of work (best case, expected case, worst case), so you model the uncertainty explicitly rather than by some alchemist formula ("double and add 20%").
Incidentally, I found out empirically that the best technical people tend to be the worst at estimating their own time needed to complete a task. That's because the best are often also a bit over-confident, perhaps. Letting each team member estimate a task and adding a 20% correction for unforseen issues has worked well to make my projects be delivered on time.
Tip: Push back if management tells you how long you have; either explain to them what you can give to them in the time they dictate or reject their task order and say you will come back when you have calculated how long the project takes, which can only be rationally determined once the scope is clear(er).
Check out/google: PMI PMP methodology and also PMBOK (project management body of knowledge) > "Organizational Process Assets" (OPAs) > "Lessons Learned Repository"
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.
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.
> 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. :-)
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?
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.
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.
Engineer: “It will take me two days [of work].” Sales:”We will have your fix ready in three calendar days [today + 2].”
Actual work that week gives employee 3 hours of non-meeting time, each daily meeting adds 0.5 hours of high-urgency administrative work. Friday’s we have a mandatory all-hands town halls…
Repeat that cycle for every customer facing issue, every demo facing issue, and internal political issue and you quickly drive deep frustrations and back talking.
I think there’s a fundamental truth: no one in their right minds, not even motivated engineers, actually hears anything but calendar when getting “days” estimates. It’s a terrible misrepresentation almost all the time, and engineers do a disservice when they yield to pressure to deliver them outside the broader planning process.
Project schedules should be the only place that time commitments come from, since they’re informed with necessary resource availability.
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.
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.
With respect, I think this approach is actually harmful to everyone in the org because you're trying to twist reality to fit a premise that is just impossible to make true: that estimates of how long it takes to build software are reliable.
The reluctance to accept the reality that it cannot be made true achieves nothing positive for anybody. Rather it results in energy being lost to heat that could otherwise be used for productive work.
This isn't about respect between functions, this isn't about what ought to be professionally acceptable in the hypothetical. It's about accepting and working downstream of a situation based in objective truth.
Believe me, I wish it were true that software estimates could be made reliable. Everyone does. It would make everything involved in making and selling software easier. But, unfortunately, it's not easy. That's why so few organisations succeed at it.
I don't present easy answers to the tensions that arise from working downstream of this reality. Yes, it's easier to make deals contingent on firm delivery dates when selling. Yes, it's easier to plan marketing to concrete launch dates. Yes, it's easier to plan ahead when you have reliable timeframes for how long things take.
But, again unfortunately that is simply not the reality we live in. It is not easy. Flexibility, forward planning and working to where the puck is going to be, and accepting redundancy, lost work, or whatever if it never arrives there is part of it.
That I think is what people in different functions are best served rallying and collaborating around. One team, who build, market and sell software with the understanding that reliable estimates are not possible. There simply is no other way.
> you're trying to twist reality to fit a premise that is just impossible to make true: that estimates of how long it takes to build software are reliable.
It's not binary, it's a continuum.
With experience, it's possible to identify whether the new project or set of tasks is very similar to work done previously (possibly many times) or if it has substantial new territory with many unknowns.
The more similarity to past work, the higher the chance that reasonably accurate estimates can be created. More tasks in new territory increases unknowns and decreases estimate accuracy. Some people work in areas where new projects frequently are similar to previous projects, some people work in areas where that is not the case. I've worked in both.
Paying close attention to the patterns over the years and decades helps to improve the mapping of situation to estimate.
Yes, but where reliability is concerned, a continuum is a problem. You can't say with any certainty where any given thing is on the continuum, or even define its bounds.
This is exactly what makes estimates categorically unreliable. The ones that aren't accurate will surprise you and mess things up.
In that sense, it does compress to being binary. To have a whole organisation work on the premise that estimates are reliable, they all have to be, at least within some pretty tight error bound (a small number of inaccuracies can be absorbed, but at some point the premise becomes de facto negated by inaccuracies).
Software estimates for projects that don't involve significant technical risk can be made reliable, with sufficient discipline. Not all teams have that level of discipline but I've seen existence proofs of it working well and consistently.
If you can't make firm delivery commitments to customers then they'll find someone who can. Losing customers, or not signing them in the first place, is the most harmful thing to everyone in the organization. Some engineers are oddly reluctant to accept that reality.
That assumes you’re working in some kind of agency or consulting environment where you repeatedly produce similar or even distinct things. As opposed to a product company that has already produced and is humming along, which is when most people get hired.
Estimating the delivery of a product whose absence means zero product for the customer is very different. A company that’s already humming along can be slow on a feature and customers wouldn’t even know. A company that’s not already humming is still trying to persuade customers that they deserve to not die.
Not at all. This can work fine in product development, as long as you limit the level of technical risk. On the other hand, if you're doing something really novel and aren't certain that it can work at all then making estimates is pointless. You have to treat it like a research program with periodic checkpoints to decide whether to continue / stop / pivot.
There is an enterprise methodology that increases precision of project estimation.
1. Guess the order of magnitude of the task (hours vs days/months/years)
2. Add known planning overhead that is almost order of magnitude more.
Example: if we guess that task will take 30min, but actually it took 60min - that’s 100% error (30min error/30min estimate).
But if the methodology is used correctly, and we spend 2h in a planning meeting, same estimate and same actual completion time results in only 20% error, because we increased known and reliable part of the estimate
(30min error / 2h30min estimate)
There’s no binary switch between estimable and not. Depends a lot on industry and novelty of work. Then estimates will be given in ranges and padded as needed by previous work. This gets a project into regularity.
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.
> 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.
Former Test Engineer here. It was always fun when everyone else’s deadline slipped but ours stayed the same. Had to still ship on the same date even if I didn’t have silicon until much later than originally planned.
I think you were estimating time to build things that were out of R&D and you had specifications that were actual specifications you were building up to.
In SaaS my experience is: someone makes up an idea not having any clue how existing software is working or is laid out, has no specifications beside vague not organized bunch of sentences. Software development team basically starts R&D to find out specifications and what is possible - but is expected to deliver final product.
I had the same experience when doing an exercise implementing `mmap` for `xv6` -- that was the last lab. There was no specification except for a test file. Passing that test file is relatively easy and I could game it. I consulted the manpage of `mmap` but it is pretty far from a specification, so eventually I had to write a lot of tests in Linux to figure out what it can do and what it can't do (what happens when I over-mmap? what happens when I write back pass EOF? etc.), and write the same tests for `xv6` so that I could test my implementation. Not sure about hardware, but it is really hard to get a clear specification for software.
This aligns with my experience in the semi industry. SWEs tend to see trimming scope as moving the goalpost and do not consider as an option. Providing advance notice is mostly about client management, and clients are often surprisingly receptive to partial solutions.
> Trim features, push date, bring in extra help, or crunch.
There are problems with all of these. The company knows they can sell X of the product for $Y (often X is a bad guess, but sometimes it has statistical range - I'll ignore this for space reasons but it is important!). X times Y equals gross profit. If the total costs to make the feature are too high the whole shouldn't be done.
If you trim features - the affects either the number you can sell, or the price you can sell for (sometimes both).
If you push the date that also affects things - some will buy from a competitor (if possible - and the later date makes it more likely the competitors releases with that feature).
Bring in extra help means the total costs goes up. And worse if you bring them in too late that will slow down the delivery.
Crunch is easiest - but that burns out your people and so is often a bad answer long term.
This is why COMPANIES NEED ACCURATE ESTIMATES. They are not optional to running a company. That they are impossible does not change the need. We pretend they are possible because you cannot run a company without - and mostly we get by. However they are a fundamental requirement.
If your business model needs the impossible then it's a bad business model. If your margins are too thin to absorb the schedule uncertainty then don't produce software.
Alternatively treat it like a bet and accept it may not pay off, just like any other business where uncertainty is the norm (movies, books, music).
> This is why COMPANIES NEED ACCURATE ESTIMATES. They are not optional to running a company.
Sure, but even accurate estimates are only accurate as long as the assumptions hold.
Market conditions change, emergency requests happen, people leave, vendor promises turn out to be less than accurate.
And most estimates for non-routine work involve some amount of risk (R&D risk, customer risk, etc.).
So pounding the table and insisting on ACCURATE ESTIMATES without a realistic backup plan isn’t good business, it’s just pushing the blame onto the SWE team when (not if) something goes south.
I would settle for accurate estimates being a requirement if sticking to the estimate and allocations is as well. Every project I've been a part of that has run over on timeline or budget had somebody needling away at resources or scope in some way. If you need accuracy to be viable, then the organization cannot undermine the things that make it possible to stay on track.
Also, if you need accuracy stay away from questionable vendors of 3rd party products, as much as possible since they are chaos generators on any project involved.
In my work we have our core banking system designed in 80s on top of Oracle DB so everything is just boxes around it, with corresponding flexibility towards modern development methodologies. The complexity of just doing a trimmed copy of production servers for say user acceptance test phase is quite something, connecting and syncing to hundreds of internal systems.
Needless to say estimates vs reality have been swinging wildly in all directions since forever. The processes, red tape, regulations and politics are consistently extreme so from software dev perspective its a very lengthy process while actual code changes take absolutely tiny time in whole project.
They don't NEED them, but better project estimates can reduce the error bars on other dependent estimates (e.g. estimated sales, estimated ship dates, estimated staffing requirements, etc...), and that might be useful to a business (or not).
This is true, but the problem is that engineers are being asked to over-extrapolate given the evidence, and expected to own that extrapolation despite the paucity of evidence to make a good estimate.
I *HATE* estimating roadmaps, because it feels unfair. I'm happy to estimate a sprint.
Yes. I took over the project management of a job where the previous project manager had spent a year planning it out, but development had not yet started. The client was furious, understandably.
I abandoned the plans from the previous PM and discussed the job with the developer who ballpark estimated that the work would take 2 months. After a quick analysis I adjusted this to 14 weeks.
But the account manager thought this sounded too long and insisted that we plug everything in to a Gantt chart, define the shit out of everything, map the dependencies, etc, which showed that the development would only take 6 weeks.
In another life, I would do things like measure the cost in developer time of bugs making it into developer repos vs. the cost in time of running tests in CI to catch such bugs, so evidence based decision making. It was mostly ignored, and at first I was surprised. A multi million dollar organization of people making negative EV plays, which I chalked up to the political pressures being more important than the wastage. More on that later.
As far as estimates go, I've also struggled with the industries cult(ural) rituals. I tried to put forward a Gaussian based approach that took into account not only the estimate of time, but the expected uncertainty, which is still probably off the mark, but at least attempts to measure some of the variance. But again, the politics and the rigidity of the clergy that has built around software development blocked it.
On the bright side, all this has helped me in my own development and when I think about software development and estimating projects. I know that outcomes become more chaotic as the number of pieces and steps compound in a project (i.e. the projects normal curve widens). You may not even get the project at all as defined at the outset, so my normals approach is still not quite the right tool.
I think this kind of thinking can be helpful when working solo or in a small group who are exposed to market forces. But for solo and small groups, the challenge isn't so much about the estimates, it's about how you're going to fight a battalion of mercenaries hired by big VC money and Big Tech. They can often afford to be inefficient, dump in the market, because their strategy is built around market control. These aren't practices small players can afford, so you need to get creative, and try to avoid these market participant kill boxes. And this is why, coming back to my earlier point, that often times, inefficient practices and politics plays a big role. Their trying to marshal a large number of troops into position and can afford to lose a few battles in order to win the war. The big money plays by a different set of rules, so don't worry if their doing it wrong. Just recognize your in the army soldier!
It's sad how software organizations refuse to learn from history. The US Navy was using PERT to manage huge, risky projects back in the 1950s with pretty good results. It can give you a Gaussian distribution of project completion dates based on best / middle / worst case estimates for individual tasks with dependencies.
It's definitely unfair in a sense. But companies that make over-extrapolated roadmap estimates from not enough evidence systematically outcompete those who don't, because their customers greatly prefer companies who give a date and then try their best to hit it over companies who say they don't know when the product will be ready for X and you'll just have to wait and see.
I get that, and I don't mind giving guidance on roadmaps, it's just the ownership when stuff outside my control goes wrong that bothers me. I shouldn't be responsible for product going in circles on little details with the customer causing req churn, yet I have been held accountable for missing estimates under that exact circumstance.
Yes, the key part of estimation is not that we need to say how large must be the (time) box to contain the project, but rather how much of a project can we pack into a box no larger than what the business could bear.
Hence the separation into must-haves, highly desirable, and nice-to-haves. Hence the need for modularity and extensibility: you if don't get to build everything in one go, and can't always even predict what parts would be left outside the scope, you have more of a lego-like structure.
BTW maybe if we finally shook off the polite lie of planning how much work a project could be, and instead started to think in terms of possible deliverables within different time frames, the conversation would become saner.
I agree whole-heartedly with the source article as well as this comment. The point is that the work of estimation is most of the work. We can have better estimates if we break things down to bite-sized chunks, but "when will this be done" is largely impossible and comes down to many external factors. Laypeople understand this implicitly in other contexts.
My favorite metaphor is building something like a new shopping mall. If you ask for an estimate you first need to architect the entire thing. This is equivalent to breaking down the task into sprints. In most companies the entire architecture phase is given very little value, which is insane to me.
Once we have our blueprints, we have other stakeholders, which is where things really go off the rails. For the mall, maybe there is an issue with a falcon that lives on the land and now we need to move the building site, or the fixtures we ordered will take 3 extra months to be delivered. This is the political part of estimating software and depends a lot on the org itself.
Then, finally building. This is the easy part if we cleared the precursor work. Things can still go wrong: oops we hit bedrock, oops a fire broke out, oos the design wasn't quite right, oops we actually want to change the plan.
But yes, estimates are important to businesses. But businesses have a responsibility to compartmentalize the difference. Get me to a fully ticketed and approved epic and most engineers can give you a pretty good estimate. That is what businesses want, but they consider the necessary work when they Slack you "how long to build a mall?"
I've also seen it argued that real world estimates for things like construction projects are so good because 99% of it is do-overs from similar projects in the past; everyone knows what it takes to pour a column or frame a floor or hang a beam.
Whereas with software most of what was done previously is now an import statement so up to 80-100% of the project is the novel stuff. Skilled leaders/teams know to direct upfront effort toward exploring the least understood parts of the plan to help reduce down-stream risk but to really benefit from that instinct the project plan has to regularly incorporating its findings.
Real world estimates for construction projects are often way off. Especially for remodeling or renovation of older buildings, where the most serious problems can remain hidden until you get into the demolition phase.
Indeed yes. Union Station in Toronto has been like this; twenty years in and no end in sight because every wall they open reveals more problems to solve.
I agree. Software engineering is basically the only industry that pretends this is professionally acceptable. Imagine if government staff asked when a bridge would be done or how much it would cost and the lead engineer just said "it's impossible to estimate accurately, so we wont. It's a big project tho".
Estimating in software is very hard, but that's not a good reason to give up on getting better at it
Government contractor's estimation is based on what number is politically acceptable, not how much the project would realistically take. 90% of public projects were overbudget [0].
But you're pretty spot on, as 'professionally acceptable' indeed means politically acceptable most of the time. Being honest and admitting one's limit is often unacceptable.
Yes, my claim is absolutely not that they're good at it haha.
Estimation is a real problem in a lot of industries, including ours, and I think that's probably common ground here -- I suppose my differing position is that I think the solution is to get better at it, not to refuse to do it.
I've been on projects where I've seen the budget explode and projects where I've seen the budget kept tight and on track. The latter is very hard and requires effort from ALL sides to work, but it's almost always achievable.
I actually empathize a little bit more with megaprojects because generally the larger the budget the harder it will be to keep on track in my experience. Most estimates we're asked to give in our day jobs are not even multi-million dollar estimates.
Also I'm using budget and estimate interchangeably but these are of course different things -- that's one of my nitpicks is that we often treat these as the same thing when we talk about estimating being hard. A lot of individual estimates can be very wrong without affecting the ultimate budget.
Contractor estimates are just as prone to schedule slippage and cost overruns as anything estimated by software engineers. I doubt anyone's ever argued that giving wrong estimates is hard or impossible. Only that approximately correct ones are, and other industries seem to struggle with that just as much as software. Authors don't finish books by deadlines, so fans are left in the cold. Tunnels take twice as long and cost twice as much. Renovations take a year instead of 3 months and empty your bank account.
Saying "I don't know" is arguably more honest, even if it's not useful for budgets or planning.
> Contractor estimates are just as prone to schedule slippage and cost overruns as anything estimated by software engineers
I completely agree. That's why I chose that example: They're also awful at it, especially these days in North America in particular. But any contractor that tried to put in a bid claiming "it'll be done when it's done and cost what it costs" would not be considered professionally competent enough to award a multi-million dollar budget.
- Prioritize whatever is most valuable and/or can stand on its own
If you just say “I don’t know” and have no target, even if that’s more honest, the project is less likely to ever be shipped at all in any useful form.
Ever heard of Big Dig in Boston, for example? Or the Joint Strike Fighter?
Estimations in government contracts are as ridiculous as in software. They just pretend to be able to estimate when things will be done, when, in fact, the contractors are as clueless.
Not being able to say "it is impossible to estimate", does not mean your estimate will be correct. That estimation is usually a lie.
Not a good analogy. Once you build a bridge, it’s done. Software nowadays is never “done”, and requirements constantly change. It’s more akin to building a rope bridge and trying to upgrade it to accommodate cars while it’s in active use.
Sounds like you don't have a good process for handling scope changes. I should know, the place I'm at now it's lacklustre and it makes the job a lot harder.
Usually management backs off if they have a good understanding of the impact a change will make. I can only give a good estimate of impact if I have a solid grip on the current scope of work and deadlines. I've found management to be super reasonable when they actually understand the cost of a feature change.
When there's clear communication and management decides a change is important to the product then great, we have a clear timeline of scope drift and we can review if our team's ever pulled up on delays.
I feel like some people in this thread are talking about estimates and some are talking about deadlines. Of course we should be able to give estimates. No, they're probably not very accurate. In many industries it makes sense to do whatever necessary to meet the estimate which has become a deadline. While we could do that in software, there often isn't any ramifications of going a bit overtime and producing much more value. Obviously this doesn't apply to all software. Like gamedev, especially before digital distribution.
I think it's obvious that all software teams do some kind of estimates, because it's needed for prioritization. Giving out exact dates as estimates/deadlines is often completely unecessary.
The real problem is software teams being given deadlines without being consulted about any sort of estimates. "This needs to be done in 60 days." Then we begin trading features for time and the customer winds up getting a barely functioning MVP, just so we can say we made the deadline and fix all the problems in phase 2.
OK, so that sounds fine. Software delivers value to customers when it's better than nothing some of the time. Even if it barely functions then they're probably happier with having it than not, and may be willing to fund improvements.
Sure, so extract the customer's definition of done as part of requirements analysis process and write it down. Get them to agree in writing, including the explicit exclusion of other things that aren't part of their idea of done.
When the government asks how much project X costs they find ten companies that promise the moon and then deliver a wheel of cheese for five times the estimated cost.
Incorrect analogy. Bridge construction is a clearly algorithmic process. All bridges resemble each other, and from an engineering perspective, designing one is not rocket science. Construction itself is a set of well-studied steps that can be easily calculated. If I were to write my operating system 100 times, I could give an estimate accurate to within 10%, but every task I’ve ever done in life is unique, and I have nothing to compare it to except intuitive judgments. Returning to bridges: there is 1% of projects that are unique, and their design can take decades, while construction might not even begin
Software engineering isn't some magical, special branch of engineering in which no one piece of software resembles another, no well-studied steps can be replicated, and the design of which is equivalent to rocket science.
If you're truly creating such unique and valuable software that it is to be compared to the world's engineering megaprojects in its challenge then perhaps it is beyond being beholden to a budget. Who am I to say?
But 99.9% of this industry isn't doing that and should probably be able to estimate their work.
I’m not talking about difficulty; I’m talking about uniqueness—uniqueness for me personally. There are people who spend their whole lives designing bridges. I, on the other hand, have been writing software for 15 years, and almost every task I encounter is unlike the previous one. I’m not saying it’s difficult, but solving it requires gaining new experience that will be useless for future tasks. Sometimes, I have to do something similar to a previous task, but in 90 percent of cases, I first need to create documentation on how it currently works, figure out how to turn a task description consisting of a 15-word headline into a set of concrete actions, and then test it.
>>>> In a functioning org, there are lot of professionals depending on correct estimation to do their job.
A side effect is, no there aren't. Allow me to explain that catty remark.
The experienced pro's have figured out how to arrange their affairs so that delivery of software doesn't matter, i.e., is someone else's problem. The software either arrives or it doesn't.
For instance, my job is in technology development for "hardware" that depends on elaborate support software. I make sure that the hardware I'm working on has an API that I can code against to run the tests that I need. My department has gone all-in on vibe coding.
Customers aren't waiting because the mantra of all users is: "Never change anything," and they can demand continued support of the old software. New hardware with old software counts as "revenue" so the managers are happy.
I think the hardest part of estimation often gets glossed over: genuine technical unknowns. Not "we didn’t think hard enough," but cases where the work itself is exploratory.
The most effective approach that I've found to prevent delays in large scale software projects is to carve out a dedicated team to deal with critical bugs, L3 support tickets, and urgent minor enhancements. Don't count them in capacity planning. They serve to insulate the feature teams from distractions. Rotate those assignments for each project so that everyone takes a turn.
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.
That's why the right way to do it is to have a hard deadline given to engineers, then the engineers cut whatever scope is needed to actually wrap something up by the deadline
It all starts with sales and marketing cramming every possible feature and half-rumour they heard about competitors' features into a 6 month project deadline. That's a long time, 6 months, no? How hard can it be? Respectfully, it'll be done when it's done.
we are the ones qualified to say what needs to be cut to provide reasonable certainty for the deadline. it is not the job of non-technical stakeholders to mitigate risk in technical projects
> "when it's done" is somehow acceptable for the rest of the business to function.
Well, it is the truth. It won't be done before it is done. It is understandable that there is a business that needs to function, but the issue here is the question of asking for an estimate like you've already solved the problem, instead of actually sitting down with the engineer to discuss the business problems that need to be solved. That's what engineers are there for: To solve business problems. Estimates are irrelevant as the solution will be designed with the business constraints in mind.
> it's quite doable to break a large project down into a series of sprints
This too comes across like the problem is already solved. You don't need to break problems down into sprints. That is a ridiculous way to operate. This kind of thing only shows up where there is some weird effort to separate engineers from their jobs.
In fact, "sprint" comes from Scrum, which was designed to be a transitionary exercise to get engineers more comfortable with Agile, which is all about removal of managers. It is intended to teach engineers to think and act more like managers so that when you get rid of the managers completely that they don't flounder. If you are doing it as more than a temporary thing, you've entirely missed the point.
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.
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.
I'm a dev, not a salesperson, but let's be realistic. A company tells you "yeah we're interested in signing at $1M/yr, but we really need this feature, when will you have it by?", to which saying "eh we don't know - it'll be done when it's done" will lead to the company saying "ok well reach out when you have it, we can talk again then" (or just "eh ok then not a good fit sorry bye"), and in the meantime they'll go shopping around and may end up signing with someone else.
Having a promised date lets you keep the opportunity going and in some cases can even let you sign them there and then - you sign them under the condition that feature X will be in the app by date Y. That's waaaay better for business, even if it's tougher for engineers.
“Sign up and pay at least part of it now and we’ll prioritize the feature”.
I’ve seen enough instances of work being done for a specific customer that doesn’t then result in the customer signing up (or - once they see they can postpone signing the big contract by continuing to ask for “just one more crucial feature”, they continue to do so) to ever fall for this again.
Why do that if your competitor already has it? I'd just go talk to the competitor instead. If you aren't able to ballpark when the feature will be done, why should I trust you will once I pay part of the price?
Because you have other benefits, so we'd really like to switch over to you, but we can't unless you support this dealbreaker feature that your competitor we're currently using has.
Just to consider the opposite viewpoint, I sometimes wonder if it's not better that they do churn in that case.
Assuming the sales team is doing their job properly, there are other prospects who may not need that feature, and not ramming the feature in under time constraints will lead to a much better product.
Eventually, their feature will be built, and it will have taken the time that it needed, so they'll probably churn back anyway, because the product from the vendor they did get to ram their feature in is probably not very good.
I understand the intuition, but it's a misunderstanding of how software sales operates. There's no tradeoff between prospects who need new features and prospects who don't, because salespeople love that second category and you'll have no problem hiring as many as you need to handle all of them.
Unless its the first time they are hearing about it, when a customer asks about a feature, sales should've done their homework and checked with the team doing the work to get a rough estimate instead of pulling a number out of their behinds.
In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects.
I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought about and carefully accounted for, BUT in the specific case where it's their own days of effort, those don't feel like money.
Also, the software itself presumably has some impact or outcome and quite often dates can matter for that. Especially if there are external commitments.
The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development.
1. Think about what product/system you want built.
2. Think about how much you're willing to invest to get it (time and money).
3. Cap your time and money spend based on (2).
4. Let the team start building and demo progress regularly to get a sense of whether they'll actually be able to deliver a good enough version of (1) within time/budget.
If it's not going well, kill the project (there needs to be some provision in the contract/agreement/etc. for this). If it's going well, keep it going.
The exact same way you'd treat any other investment decision.
In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising.
You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.
You mean… by making a forward-looking estimates of cost, time-to-value, return? (even if it's implicit, not documented, vibes-based?).
When devs refuse to estimate, it just pushes the estimating up the org chart. Execs still have to commit resources and do sequencing. They’ll just do it with less information.
Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.
Sorry, I edited the plumbing refence out of my comment because I saw a sibling post that made a similar point.
I agree there is less uncertainty in plumbing - but not none. My brother runs a plumbing company and they do lose money on jobs sometimes, even with considerable margin. Also when I've needed to get n quotes, the variation was usually considerable.
I think one big situational difference is that my brother is to some extent "on the hook" for quotes (variations / exclusions / assumptions aside) and the consequences are fairly direct.
Whereas as an employee giving an estimate to another department, hey you do your best but there are realistically zero consequences for being wrong. Like maybe there is some reputational cost? But either me or that manager is likely to be gone in a few years, and anyway, it's all the company's money...
I bet if SWEs were seeing anywhere near that 1.5k per day they’d be more inclined to pay attention.
But when you get paid less than half that it doesn’t feel like a problem to worry about. At 300/day of take-home pay, one more day here or there really isn’t going to make a difference.
If you hired someone to do some work on your house, and they refused to give an estimate, would you be happy?
If you had a deadline - say thanksgiving or something - and you asked “will the work be done by then” and the answer was “I’m not going to tell you” would you hire the person?
The no estimates movement has been incredibly damaging for Software Engineering.
If work on a house was specified like a typical software project, no builder would even return your call.
"I'd like to have my roof reshingled, but with glass tiles and it should be in the basement, and once you are half way I'll change my mind on everything and btw, I'm replacing your crew every three days".
Sure, for roofing jobs or other large repairs, that’s true. But for remodeling it’s pretty different.
When I’ve engaged with a contractor for remodeling, I usually have some vague idea like “we should do something about this porch and deck and we’d like it to look nice.”
The contractor then talks to you about _requirements_, _options_, and _costs_. They then charges for architectural plans and the option to proceed with a budget and rough timeline.
Then they discover problems (perhaps “legacy construction”) and the scope creeps a bit.
And often the timeline slips by weeks or months for no discernible reason.
Which sounds exactly like a lot of software projects. But half of your house is torn up so you can’t easily cut scope.
Painting a wall has no “if then else”. You dont need to test to see if the wall has been painted.
I guess a fair analogy would be if the home owner just said “Make my home great and easy to use” by Thanksgiving without too many details, and between now ans thanksgiving refines this vision continuously, like literally changing the color choice half way or after fully painting a wall… then its really hard to commit.
If a home owner has a very specific list of things with no on the job adjustments, then usually you can estimate(most home contract work)
All software requests are somewhere in between former and latter, most often leaning towards the former scenario.
When there are huge unknowns, such as in the case of a remodel where who knows what you might find once the drywall is removed, then yes. I happily worked with a contractor on a basement renovation with no estimate for this exact reason.
If it’s something where they have fewer unknowns and more control and lots of experience building the same thing, then I would expect an estimate: building a deck, re-roofing a house, etc
For any slightly complicated project on a house the estimate assumes everything goes right, which everyone knows it probably won't. It's just a starting point, not a commitment.
Definitely so. Most business people that I've worked with do understand that. And provided problems are communicated early enough can manage expectations.
Where I've seen issues is when there is a big disconnect and they don't hear about problems until it's way too late.
These are just bad contractors. I used to work for a remodeling company. We came in under time on the vast majority of projects because the guy who ran the company knew what he was doing and built slack into the schedule.
But it's the reality of engineering. If reality is unacceptable, that's not reality's problem.
But the problem is, the sales world has its own reality. The reality there is that "we don't know when" really is unacceptable, and "unacceptable" takes the form of lost sales and lost money.
So we have these two realities that do not fit well together. How do we make them fit? In almost every company I've been in, the answer is, badly.
The only way estimates can be real is if the company has done enough things that are like the work in question. Then you can make realistic (rough) estimates of unknown work. But even then, if you assign work that we know how to do to a team that doesn't know how to do it, your estimates are bogus.
I don't know that it's the reality of engineering. (Edit: in fact there are some comments for this post providing counterexamples, an interesting one is the hardware world).
It's what we software engineers like to tell ourselves because it cuts us slack and shifts the blame to others for budget and time overruns. But maybe it's also our fault and we can do better?
And the usual argument of "it's not like physical engineering, software is about always building something new" because that's only true for a minority of projects. Most projects that fail or overrun their limits are pretty vanilla, minor variations of existing stuff. Sometimes just deploying a packaged software with minor tweaks for your company (and you must know this often tends to fail or overrun deadlines, amazingly).
I know another "engineering" area where overruns are unacceptable to me and I don't cut people slack (in the sense it's me who complains): home building/renovation contractors. I know I'm infuriated whenever they pull deadlines out of their asses, and then never meet them for no clear reason. I know I'm upset when they stumble over the slightest setbacks, and they always fail to plan for them (e.g. "we didn't expect this pipe to run through here", even though they've done countless renovations... everything is always a surprise to them). I know I'm infuriated when they adopt the attitude of "it'll be done when it's done" (though usually they simply lie about upfront deadlines/budgets).
Maybe that's how others see us from outside software engineering. We always blame others, we never give realistic deadlines, we always act surprised with setbacks.
Part of it is absolutely our fault; part of it is the industry.
In the electronics world, when you need <common functionality>, you can find an off-the-shelf part that fits your requirements, fit that part in and it'll work. When you need logic in a hardware device, nobody's rolling their own CPU from discrete parts - they just take the cheapest microcontroller fitting the requirements.
In the software world we don't seem to have this concept of building blocks for common functionality even decades into the industry. Most software projects are some flavor of CRUD app with custom logic operating on the CRUDed objects. You'd think all the complexity would be in the custom logic, but actually it's at best 50-50 and at worst most of the complexity is in the whole CRUD bullshit and not what happens to the object once it's CRUD'ed.
How come in 2026 there's still no way to have an off-the-shelf component I can buy to do "I have a table of objects on the server, and I want to expose this as a UI to the client"? Why do I still see people writing this by hand in React/$JS-framework-of-the-day and messing around with things like OpenAPI and/or writing serializers/deserializers by hand? I swear most of the work I see in the web development space is the minutia between client/server communication.
I think there are several reasons:
* overengineering/resume-driven-development: even if there was to be an off-the-shelf component to do the task, people would probably avoid it and prefer to bullshit around reimplementing a (worse) solution. That's already the case where people are using React/SPAs/etc for views that do no need any interactivity and could just be an HTML form.
* political choices influencing tech selection: more often than not some tech or service provider is selected based on political reasons and not technical, and then the engineering challenge becomes as to how to shoehorn this ill-fitting part into our solution.
* aversion to paid software: hardware engineers are expected and allowed to select parts that cost money. I've never been on a software project where we had an explicit budget for licensing software. Reaching for paid software became the least resort option I'd have to fight for and burn political points, while spending 10x the cost building a (shittier) replica in-house was considered fine.
Due to the last point there's also little incentive for software providers to build and sell such components, so the market is quite small and not competitive, with the (very few) competitors having their own dealbreakers. Firebase will give you the instant database and UI, but then you're forever tied to paying them rent. You can't just license the server component and install it in-house like you can buy an FPGA.
Sales gets fired (or not paid) for missing their estimates (quotas, forecasts) and often have little empathy for engineering being unable to estimate accurately.
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.
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-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/Cpjour...>
Martin Fowler cites this in his 2005 essay about agile programming, "The New Methodology"<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-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.
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.
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.
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.
> 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.
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"?
> 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.)
As a person that has never encountered a complex software project that can be accurately estimated, I am being a bit skeptical.
The author did make examples of when estimation is possible: easy projects with a very short time horizons (less than an a couple of days, I'd say).
I'd love to hear some examples of more complex software projects that can be estimated within a reasonable variance.
However, I think it should also be acknowledged that the point of the article seems to be in a different direction: it _doesn't really matter_ that you have a good time estimate, because asking for an estimate is just a somewhat strange way for the management chain to approach you and then tell you how much time you have to deliver.
> easy projects with a very short time horizons (less than an a couple of days, I'd say).
The example I quoted said hours, not days. But even taking your claim of days as estimable, I have seen much better.
An example of weeks-long projects I regularly estimate accurately would be things like “in our Django monolith, add this new field/model, and update the state machine with these new transitions, and update the API, and surface the feature in the UI, including standard e2es and UT coverage”. With a team of 10-15 we regularly hit days-to-weeks estimates with in the ballpark of 90% accuracy. (Ie 1-in-10 slips)
An example of year-long projects I have seen waterfall’d successfully are IP protocol implementations where the RFC is clear, base frameworks exist, and the org has engineers with decades of individual experience implementing protocols in the same framework. IOW you have senior-staff or principal engineers on the project.
> the point of the article seems to be in a different direction: it _doesn't really matter_ that you have a good time estimate
I think the idea that you always start with time and define the work is also myopic. In some dysfunctional orgs I’m sure this is true, but it’s not the whole picture.
For the fully-generalized principle at play here, I’m a big believer in the “cost / time / scope” tradeoff triangle. In other words, pick two as your free parameters, and the third is then determined. Sometimes time is the output of a calculation, and resource/scope are the input. Sometimes time can be the input and scope the output. It depends.
But the article opens by claiming it’s impossible to estimate time, given a fixed scope and cost(resource) input, which is simply false/over-generalizing.
> An example of year-long projects I have seen waterfall’d successfully are IP protocol implementations where the RFC is clear, base frameworks exist, and the org has engineers with decades of individual experience implementing protocols in the same framework.
Article responds to you with:
“For most of us, the majority of software work is not like this. We work on poorly-understood systems and cannot predict exactly what must be done in advance. Most programming in large systems is research…”
It is good to target the strongest point, not the weakest.
Yeah, that's a cop-out. All the easy things are easy! Well, yes, they are. It's the hard ones that -you know- are hard. That the easy things are easy is no real objection to TFA, it's just pedantry.
> (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.)
Maybe, just maybe, it's because "the heavyweight process/rituals required to be accurate" might not be productive, and because being startups, and therefore small organizations, it's easier for everyone to know who's pulling their weight and who isn't, therefore "heavyweight process/rituals" add nothing and cost too much.
Mature organizations tend to "implement the heavyweight process/rituals required to be accurate" precisely because they are too large for everyone to know everyone, and so senior management loses touch with reality and starts feeling anxious about whether their R&D spend is yielding value. This is totally understandable, and we have to have empathy for executives, but there is tremendous danger in this approach. How many mature market leaders have had their lunch eaten by disruptive innovators (invariably startups)? And why? Maybe those "heavyweight" processes kill innovation! That urge to accurately measure what the org's devs are doing can be counterproductive.
All measures but one (so far) are gameable. So far only KTLO fraction, which one should couple with promoting a management culture that allows subjective value judgements to make it up and down the chain. Management of knowledge work essentially is a social problem, not a scientific one.
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.
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.
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.
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.
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
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.
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 :)
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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?
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.
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.
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.
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.
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.)
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.
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.
Even more evidence of how versatile that French phrase is. There's just so many acceptable meanings to it, and every one of them points to the same conclusion: bounds enable art.
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.
> 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.
I love this - it's very similar to what the book Shape Up (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.
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?
> 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.
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.
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.
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.
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.
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
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?)
> 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.
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.
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.
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.
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")
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.
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.
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.
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.
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.
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.
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
What if the project involves trying one approach for a week, then assessing whether that approach still looks viable vs moving onto a different approach? This happens a lot with challenging projects, you basically just keep trying different things until one works.
Then you know that it's going to take at least, say two weeks, one week for the first implementation and a week to finish it if it works.
On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period.
So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending effort to narrow the estimate?
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.
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 ;(
This why you should use confidence intervals for estimates. Use a 80% confidence interval, for example. 10% of the time, you should come in under the best case estimate. 10% of the time, it should take longer than the worst case estimate.
How do you know if your estimate is good? Would you rather bet on your estimate or on hitting one of 8 numbers on a 10-number roulette wheel? If you prefer one of the bets, adjust your estimates. If you're indifferent between the bets, the estimates accurately reflect your beliefs.
(The roulette wheel is from the book, How to Measure Anything by Hubbard. Confidence interval estimates are from LiquidPlanner, https://web.archive.org/web/20120508001704/http://www.liquid...)
That’s why time limiting rather than estimating works for me. It forces me to contend with the question: “can I get this done today?” That’s usually an easier question to answer because it’s to tightly time bound. I’m not always correct but I’ll know tomorrow if I wasn’t, rather than next month!
When I’m asked on longer time frames, I’m much less confident but it’s still more concrete than the other way around.
It really depends. Anyone doing meaningful work will have hard time giving estimates. But churning up the next CRUD application with now special requirements can have no unknown variables. The question of course remains, why would anyone want to waste their time reinventing a spreadsheet.
>why would anyone want to waste their time reinventing a spreadsheet
I hope this is tongue in cheek, right? If not, here are some reasons:
1) spreadsheets embed "functions" via macros and macros are often flagged as malicious. Just combining native functions can get pretty complex.
2) in a spreadsheet, everybody sees the input, which is not always ideal
3) data types are controlled by users for the entire column or sheet, which can mess up formulas
I could probably think of additional reasons.
I like this approach, it's more accurate than T-shirt sizing.
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)
I've worked on codebases all the way tens of millions of lines of code. Obviously not in the sense of knowing all the dusty corners of such codebases, but still, I did enough work on them that I had to navigate my way around millions of loc. It's not easy! The problem is that you can't possibly know even a sizeable fraction of such a codebase well. Instead you can know small corners well and know your way around the internal and external interfaces so you can find gotchas and answer questions as you research. The knowledge you build is hard to communicate to others, too, so bringing others up to speed is not easy either. So for me TFA hits all the right notes.
But I've also seen things like the ZFS team at Sun deliver something unbelievably good that started as a skunkworks project that senior management didn't really know about until there was enough to show to justify a large investment. Sun was like DARPA: not micromanaged from the top. Sun failed, of course, but not because of this.
Did ZFS deliver on a tight timeline that was well established before any work began?
That I wouldn't know, but I know it took longer than anticipated, and towards thee end Sun pulled a lot of engineers from other projects and put them on ZFS for the final push.
Estimating the time to transfer the needed data and one round of prototype is valuable information in that case.
https://thestory.is/en/journal/chaos-report/
^ This report from 2020 analyzed about 50,000 IT projects in a wide range of market segments, and they found that 50% exceeded their deadline. This seems to suggest that your conclusion holds more generally than just your specific context.
On a personal level, I hardly ever see a developer's estimate turn out to be right, on whatever scale. I'm wondering what the pro estimate folks in this thread work on that they're able to estimate accurately.
> 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.
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.
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.
I've been on teams that tried various methods of estimating and the issue I always encounter is that everyone estimates work differently, but usually people will side with the person with the most context.
For instance someone says a ticket is two days' work. For half the team that could be four days because people are new to the team or haven't touched that codebase, etc. But because the person who knows the ticket and context well enough says 2, people tend to go with what they say.
We end up having less of those discussions you describe to come to an agreement that works more on an average length of time the ticket should take to complete.
And then the org makes up new rules that SWEs should be turning around PRs in less than 24 hours and if reviews/iterating on those reviews takes longer than two days then our metrics look bad and there could be consequences.
But that's another story.
Remember, estimation is in points not days. It doesn't matter if it's 2 days work for a senior engineer or 4 days for junior devs, it's still the same number of points, e.g. 8 points. This is intentional. Skill is accounted for in the fact that a team of all senior devs might deliver 200 points a sprint, whereas if half the senior devs got replaced with junior devs the team might only deliver 100. This is intentional, so that estimation is about the team, not any person.
And yes, when there's a task that one person happens to know most, people will often defer to them. But that in itself is educational, as the experienced dev explains why the given task is easy/hard. And every task is different, so the person you're deferring to will be different, and you still often get the two or three people who know the task best disagreeing until they hash it out, etc. And very often it's another person who can point out "well it would be that easy except three sprints ago I did x and so you'll now need to do y...". And of course plenty of tasks really are brand-new so everyone's figuring it out together.
If you're really not having actual discussions around complexity in planning poker, then the facilitator/lead/manager might be doing it wrong. You do have to create an environment where people are expected to speak up and disagree, to demonstrate that this is welcomed and expected and rewarded, and not just some kind of checkbox exercise where the most senior dev gives their estimation and everyone agrees. This is also a reason why it's literally done with cards where everyone is forced to put their number on the table at the same time, so that you don't wind up with some senior person always going first and then everyone else just nodding and agreeing.
> is in points not days
I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing.
I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.
> I've never met someone for whom points didn't eventually turn into a measurement of time
The goal isn't to avoid time estimation completely, that would be crazy. People estimate how many points get delivered per sprint and sprints have fixed lengths of time. You can do the math, you're supposed to.
The point is that points avoid a false sense of precision: https://news.ycombinator.com/item?id=46748310
The process is quite easy to implement. And it does wind up with extraordinary efficacy gains on a lot of teams, that's the whole reason why it's so popular. But you do have to actually learn about it. Here:
https://www.atlassian.com/agile/project-management/estimatio...
If it works for you, then it's a good method, but in my opinion the most transparent way to avoid a false sense of precision for time estimation (as with all else) is by explicitly including error bars, rather than changing the units-of-measure.
Error bars are complicated, and who's to say how large they should be? It winds up being a lot of pointless arguing over arbitrary precision.
The Fibonnaci sequence of point values has wound up just being a lot simpler for most people, as it encapsulates both size and error, since error tends to grow proportionally with size.
I.e. nobody is arguing over whether it's 10h +/- 1h, versus 12h +/- 1h, versus 12h +/- 2h, versus 11h +/- 3h. It's all just 5 points, or else 8 points, or else 13 points. It avoids discussion over any more precision than is actually reliably meaningful.
I worked on a product that was built around planning an estimation with ranged estimates (2-4h, 1-3d, etc)
2-12d conveys a very different story than 6-8d. Are the ranges precise? Nope, but they're useful in conveying uncertainty, which is something that gets dropped in any system that collapses estimates to a single point.
That said, people tend to just collapse ranges, so I guess we all lose in the end.
> 2-12d conveys a very different story than 6-8d.
In agile, 6-8d is considered totally reasonable variance, while 2-12d simply isn't permitted. If that's the level of uncertainty -- i.e. people simply can't decide on points -- you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing once you have a more accurate estimate. You would never just blindly decide to do it or not if you had no idea if it could be 2 or 12 days. That's a big benefit of the approach, to de-risk that kind of variance up front.
> you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing
That's just too slow for business in my experience though. Rightly or wrongly, they want it now, not in a couple of sprints.
So what we do is we put both the investigation and the implementation in the same sprint, use the top of the range for the implementation, and re-evaluate things mid-sprint once the investigation is done. Of course this messes up predictability and agile people don't like it, but they don't have better ideas either on how to handle it.
Not sure if we're not enough agile or too agile for scrum.
That's definitely one way of doing it! And totally valid.
I think it often depends a lot on who the stakeholders are and what their priorities are. If the particular feature is urgent then of course what you describe is common. But when the priority is to maximize the number of features you're delivering, I've found that the client often prefers to do the bounded investigation and then work on another feature that is better understood within the same sprint, then revisit the investigation results at the next meeting.
But yes -- nothing prevents you from making mid-sprint reevaluations.
If you measure how long a hundred "3-day tasks" actually take, in practice you'll find a range that is about 2-12. The variance doesn't end up getting de-risked. And it doesn't mean the 3-day estimate was a bad guess either. The error bars just tend to be about that big.
If a story-sized task takes 4x more effort than expected, something really went wrong. If it's blocked and it gets delayed then fine, but you can work on other stories in the meantime.
I'm not saying it never happens, but the whole reason for the planning poker process is to surface the things that might turn a 3 point story into a 13 point story, with everyone around the table trying to imagine what could go wrong.
You should not be getting 2-12 variance, unless it's a brand-new team working on a brand new project that is learning how to do everything for the first time. I can't count how many sprint meetings I've been in. That level of variance is not normal for the sizes of stories that fit into sprints.
I think it really depends on how teams use their estimates. If you're locking in an estimate and have to stick with it for a week or a month, you're right, that's terrible.
If you don't strictly work on a Sprint schedule, then I think it's reasonable to have high variance estimates, then as soon as you learn more, you update the estimate.
I've seen lots of different teams do lots of different things. If they work for you and you're shipping with reliable results then that's excellent.
> The process is quite easy to implement
Having implemented it myself, I agree it is easy to implement. My argument is that it is overly difficult to maintain. My experience is that incentives to corrupt the point system are too high for organizations to resist.
Funnily enough - I work closely with a former director of engineering at Atlassian (the company whose guide you cite) and he is of the opinion that pointing had become "utterly dishonest and a complete waste of time". I respect that opinion.
If you have citations on pointing being effective I'd be very interested. I consider myself reasonably up to date on SWE productivity literature and am not aware of any evidence to that point - I have yet to see it.
I guess my experiences are quite the opposite. Maintaining the process couldn't be easier. I don't even know what it means to "corrupt" points...? Or for points to become "dishonest"? I'm genuinely baffled.
I'm not aware of any citations, just like I'm not aware of any citations for most common development practices. It seems to be justified more in a practical sense -- as a team or business, you try it out, and see if it improves productivity and planning. If so, you keep it. I've worked at several places that adopted it, to huge success, solving a number of problems. I've never once seen a place choose to stop it, or find something that worked better. If you have a citation that there is something that works better than points estimation, then please share!
It's just wisdom of the crowds, or two heads are better than one. Involving more people in making estimates, avoiding false precision, and surfacing disagreement -- how is that not going to result in higher-quality estimates?
By "dishonest" I'm saying they become measurements of time, which is what we were trying to avoid.
Stepping back - my experience is that points are solving a problem good organizations don't have.
The practice I see work well is that a senior person comes up with a high level plan fror a project with confidence intervals on timeline and quality and has it sanity checked by peers. Stakeholders understand the timeline and scope to be an evolving conversation that we iterate on week-by-week. Our rough estimates are enough to see when the project is truly off-track and we can have a discussion about timelines and resourcing.
I just don't see what points do for me other than attempt to "measure velocity". In principle there's a metric that's useful for upper management, but the moment they treat it as a target engineers juice their numbers.
"estimation is in points, not days" doesn't tell me anything. Is not like tasks have an intrinsic attribute that everyone can agree on (e.g. the sky is blue)
How are you estimating the points if not thinking about how hard the task is for you and how long is it going to take you?
And then another matter is that points do not correlate to who later takes that work. If you are 5 seniors and 3 juniors and average on a task being a 3, but the task falls to a junior, they will take longer as is expected for his experience.
Here, you might want to read about it:
https://www.atlassian.com/agile/project-management/estimatio...
Points are not intrinstic or objective attributes, like the sky being blue. The scale is arbitrarily chosen by any given team, and relative to past work. But a common reference point is that 1 point is the "smallest" feature worth tracking (sometimes 1/2), and 20 points is usually the largest individual feature a team can deliver in a sprint. So it's common for teams to be delivering something between e.g. 50 and 200 points per sprint. Teams very quickly develop a "feel" for points.
> And then another matter is that points do not correlate to who later takes that work.
Yes, this is by design. Points represent complexity, not time. An experienced senior dev might tend to deliver 30 points per sprint, while a junior dev might usually deliver 10. If a team swaps out some junior devs for senior devs, you will expect the team to deliver more points per sprint.
So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team?
> An experienced senior dev might tend to deliver 30 points per sprint
Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time. Isn't complexity directly proportional to uncertainty factors, and therefore inversely proportional to confidence of time to completion?
> So the PM must have the velocity of the team to be able to estimate timescales for the project, which is what they care about, and this velocity metric is only as good as the estimation of complexity points of a team?
Basically, yup. It takes a few sprints to start to establish a meaningfully reliable sense of velocity, and the estimation accuracy is why planning poker takes a couple of hours of real discussion over feature complexity, rather than just a few minutes of superficial guesses. But the end result is a far more accurate ability to estimate what a team can reliably deliver in a sprint, and is really good at bringing stakeholders down to earth in terms of what can actually realistically be delivered.
> Seems a bit ironic that complexity doesn't measure time but then we are measuring how much complexity can someone deliver on average on a given time.
What's ironic? And no, it's not about "someone", it's about the the team. Different people on the team will be able to deliver different numbers of points depending on their skill, experience, etc. This is a major reason for not using time -- it actively recognizes that different people take different amounts of time, that things like sick days and meetings are taken into account, etc.
> Isn't complexity directly proportional to uncertainty factors
Yes, this is an explicit assumption of the Fibonnaci-style points usually used.
> and therefore inversely proportional to confidence of time to completion?
Yes, which is precisely why stories over a certain size are disallowed (the feature must be broken up into parts), and why sprints are measured in a very small number of weeks -- to avoid the accumulation of too much uncertainty.
I've never been involved in planning poker where everyone didn't converge on points = days at least in their own minds. "Hm, that would take me about a day, so that's one point."
Funny, I've never been on a team that did.
Otherwise, it would be impossible to have 20-point stories done in a 10-business-day sprint! Under the usual assumption that a single person is responsible for the whole story.
For the teams I've been on, a point has usually been more like a third of a day or half a day, i.e. 2-3 hours of uninterrupted concentration, and the 1/2 point card is used rarely. Sounds like you've probably used 1/2 point stories a lot more...
But this is why points are arbitrary. Each team decides whatever precise scale it wants. And it really depends on the type of work you're doing too -- whether the smallest stories tend to be things that are day-sized or things that are 2-hour sized.
Yeah we had half-point stories. Never remember getting as high as 20. I think we topped out at about 13 and those were usually split if they could be. It's been years since I did planning poker, sort of surprised to hear that it's still in use.
> sort of surprised to hear that it's still in use.
Why? It's not like it was some fad that didn't work. When things work, organizations tend to stick with them.
Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points.
Sorry if it comes through as rude, but this is how I keep repeatedly being told story points work.
If you look at all those properties together, story points are completely useless.
The only moment time it makes sense is when you have a SHARED understanding of the smallest point AND you can translate it to time. When you do that, story points are useful. Also, they become time, so there is no reason to use points.
> Because story points MUST be specific per person based on the smallest task they ever faced, they cannot be summed up because they are not units, and points do not translate to time, we cannot talk about story points.
Literally none of that is anything I've ever encountered on any team.
They're not specific to a person, they're to a team.
They have nothing to do with the smallest task ever faced.
They are obviously for summing and are obviously units.
They effectively get translated into time in the sense that the team has a history of delivering an average of n points per e.g. 2 weeks.
Every person I met gave me a different statement, so I don't fail to believe you, it's just that the definition of story points is different for everybody
I'm sure everyone has their own idiosyncratic interpretations, but I believe I've got enough experience to tell you that what I'm explaining is pretty standard.
Here are literally the top two Google results for "story points" and they both seem to align entirely with what I said:
https://www.atlassian.com/agile/project-management/estimatio...
https://www.mountaingoatsoftware.com/blog/what-are-story-poi...
I don't doubt that what you're describing as story points is something somebody told you. I'm just telling you that their definition was highly idiosyncratic and extremely non-standard. When discussing these things, using the standard definitions is helpful.
The definition of story points like the one I have mentioned has been provided by a certified scrum master and in a different context,by a certified scrum coach.
I appreciate your effort, but I don't believe there is any formal definition. It's redefined per team, it's redefined by the team too if needed.
So people want an estimate (uncertain) based on a number that's also nebulous. It kills me.
Use time ranges, you get a sense for risk AND have an estimated delivery date.
The adjustment people make with numbers can still be made on a per team basis using time ranges, I don't see why we have to use a proxy
> The only moment time it makes sense is when you have a SHARED understanding of the smallest point AND you can translate it to time. When you do that, story points are useful.
I’d like to disagree on that one. A single story point shouldn’t be translated to time, but should reflect the relative complexity between tasks (ie. a 7 is harder than a 3 and so on).
You could assign relative complexity based on a number of things:
- number of integrations to other systems, - is the area well known to the team, - is the code well tested, - is CI/CD set up, - do we need a lot of alignment or can we just get started, - etc.
So you’re not estimating time, but complexity or hardness.
Then, supposing you have a stable team, you can go back six months and find out “we do on average 90 points per month” or similar
An estimate is composed of two parts:
When you do what you just said "I am not estimating time, I'm estimating risk"."This will take between 1 and 3 days" gives you both: the risk (complexity, hardness) which is represented by the gap, and time: how long it takes.
When a non engineer asks for an estimate, they usually mean one of these two things:
The second one can come also through the question "how challenging do you think that is?" To which we answer "easy but long" "hard" (never done it) or things like that. That's easier to answer, but doesn't translate to dates.For the first one, you CANNOT use what you just described, since it doesn't represent time, so you cannot give dates in any form.
> For the first one, you CANNOT use what you just described, since it doesn't represent time, so you cannot give dates in any form.
That's the purpose of story points and planning poker. They don't represent time guarantees or delivery dates. That's not a bug, it's a feature.
They represent estimated effort, with a recognition that uncertainty is generally roughly proportional to size. Which is why point estimates are usually restricted to approximately Fibonnaci sequences values (or sometimes doubling). Often it will be limited to 1, 2, 3, 5, 8, 13, 20, where stories aren't allowed to be larger than 20 -- if they are, you need to break them apart.
So to be clear, when you say that estimates are composed of two parts -- time and risk -- planning poker intentionally conflates them into a single number. If a task is both large and truly high-risk, then it should be broken into a research story and an implementation story, where the size of the research story can be better estimated, and then implementation waits for the next sprint depending on what research tells us. If it's small and high-risk, then you basically just "try", and accept that it might not get delivered, and then revisit in the next sprint whether it's worth trying again and if it needs to be revised.
> For the first one, you CANNOT use what you just described, since it doesn't represent time, so you cannot give dates in any form.
Exactly - that’s the point.
Story points assigned to a SINGLE task is not for estimating time spent on that task.
Story points can - given prior data - give you an estimate of time spent on a GROUP of future tasks
My most productive team did no time estimates at all (short of very very rough project estimates i.e. "yeah I'll work on this project for at least the next quarter then we'll see"), and instead of spending endless time in planning meetings determining how complex a task was, we instead spent that time just doing the thing.
How did you align with other teams?
I agree it's best if working in isolation, but if you need to synchronise then estimations make sense.
If you need 3 months to implement something, and another team 1 week, and both need to be ready at the same time; then if you actually know those estimations the second team can wait until then and do something immediately useful in between.
We do similar but sprints are somewhat flexible, more like versions. We chuck the features we want from the top of most needed, split into stories and estimate like you mentioned using brainstorming between devs and QA. Estimation happens by relatively comparing complexity of each new story compared to previously implemented stories, conservativy picking average one up if there is variance in estimates. QA is involved to determine how long it will take to test the feature or sometimes what uncertainty is there if this is even possible automatically.
In the end we have stable developer velocity metric and a really close estimate for each new version.
Our small team uses the Fibonacci sequence to estimate, and it works well for us.
Yep. My last manager would just ask "Is it a day, a week, a month, or a year?"
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.
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...
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
Let me be clear -- nobody finds planning poker or story estimation fun. The same way nobody finds writing tests or documentation fun. So of course it'll be a breath of fresh air if it's not part of your job.
But the fact remains that in most environments, it's extremely useful for medium-term planning and especially in surfacing high-risk features that can send people down the wrong path for a long time. And it's meant to benefit stakeholders -- the people paying the developers' salaries -- not individual developers. It's about de-risking.
And if you really have the kind of team you seem to describe where everybody only works on their specific type of task and can't even estimate anybody else's work, then that's a danger situation when they leave or get sick or whatever and nobody else can step in and everyone's blocked because the only person who can do X is gone. Usually, you should be actively getting other developers to work on these features (usually the easier/smaller ones) and involving them in the estimation.
How does it help with medium-term planning when it's just pointing tasks in one sprint?
Because you often estimate something like three or four times as many tasks as actually get included in the sprint. You can't possibly know in advance which features will actually wind up in the sprint until you've considered all the possible candidates. You estimate, then the PM confers with stakeholders to prioritize what's actually most important and figure out the "puzzle" of which pieces add up to a coherent sprint, and then work starts.
To the developer, it seems like short-term sprint planning. But to the PM and stakeholders, it's very much medium-term planning because they're picking tasks for this sprint in light of what they also estimate the following couple sprints will look like (given current information, which is always going to change).
It's not as bad as it sounds, because when you're re-estimating something you already estimated in the past 2 planning pokers, it's usually pretty quick. You're just seeing if the previous estimate needs to be revised based on what the team has learned since. Most time is usually spent on newly proposed features, or features that have significantly changed or been split up.
> The same way nobody finds writing tests or documentation fun
I'm not sure if it's the fun category, but at least they are useful and because of that, satisfying to do. In fact when I finish a solid suite of tests or good, clear documentation, I find it very satisfying. I can't say the same for poker/estimation. I've found to be them a complete waste of time in every job I've had and therefore soul sucking.
> you seem to describe where everybody only works on their specific type of task and can't even estimate anybody else's work, then that's a danger situation when they leave or get sick or whatever and nobody else can step in and everyone's blocked because the only person who can do X is gone
you're conflating the ability to estimate accurately with the ability to implement.
Just because I can't estimate a task accurately doesn't mean I can't do it.
How single estimate accounts for different ability of each team member? E.g. Somebody new joining in will need more time.
Estimates are for the team, not for an individual.
As the team grows and shrinks, the number of points delivered per sprint are expected to similarly rise and fall. A new person joining will likely take time to ramp up the number of points they're contributing.
What is the benefit of estimating points rather than days? Feels like you're still ultimately estimating days in the end.
Because, for whatever psychological reason, estimating in time leads to a false sense of accuracy, people pointlessly argue over whether something will take 5 days vs. 6, and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc.
Estimating in points that are basically a Fibonacci sequence keep estimation precision limited and avoids implying false guarantees. Yes, in the end the chosen stories are based on summing to a number of points that is roughly equivalent to what the team has achieved per-sprint in the recent past, so in that sense it is ultimately estimating days in the end. But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep both team expectations and management expectations more reasonable.
tl;dr: Psychology.
Can't you do that by just limiting the precision? You can only vote 1, 2, 3, 5 or 8 days. Not sure what "points" are adding. As far as I can tell, it's an attempt to account for estimation difficulties by introducing a "velocity" concept. But I think it makes things more complex without actually solving the issue.
Let me repeat myself:
> and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc.
> But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep both team expectations and management expectations more reasonable.
The post is about project planning, not sprint planning.
> It prevents you from estimating things longer than a sprint, because it assumes that's impossible.
And yet, management wants estimates for a whole project. Projects have to get paid for somehow, and project estimates are a key part of that in many many organizations. Ever wonder why government IT is SO BAD?
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.
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.
Oof. Exactly. Simple things get complicated when you find out that there were unstated requirements, hidden booby traps, etc. And then there's random interrupts -- unrelated stuff that comes up and takes your time and focus. If you run a lean ship then interrupt management is critical, but ideally you can have a few people who are understood to take critical interrupts and thus their schedules will slip.
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.
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.
> 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).
The PMI project management methodology even pre-scribes this (after the project is over, to reflect, and then to gather collected learnings and objective stats so as to help better estimation of future projects), but the problem is many engineers see project management a administrative burden rather than as a tool, and they have a tinkerer's mind-set rather than a scientist's mind-set.
Good project management practice is also not to use point estimates but intervals: something is going to take "betweek [i;j] person days". PERT-estimates are even three-point estimates of work (best case, expected case, worst case), so you model the uncertainty explicitly rather than by some alchemist formula ("double and add 20%").
Incidentally, I found out empirically that the best technical people tend to be the worst at estimating their own time needed to complete a task. That's because the best are often also a bit over-confident, perhaps. Letting each team member estimate a task and adding a 20% correction for unforseen issues has worked well to make my projects be delivered on time.
Tip: Push back if management tells you how long you have; either explain to them what you can give to them in the time they dictate or reject their task order and say you will come back when you have calculated how long the project takes, which can only be rationally determined once the scope is clear(er).
Check out/google: PMI PMP methodology and also PMBOK (project management body of knowledge) > "Organizational Process Assets" (OPAs) > "Lessons Learned Repository"
How long does it take to do a crossword puzzle or play a game of chess?
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.
How long does it take to solve a Rubik's cube for the first time?
How long does it take to learn to juggle 3 items? 4? 5?
How much time will it take you to measure the coast of England between Brighton and Seaton?
Usually less than 2 days, with a 90% confidence.
Chess games usually have time limits, so pretty easy. Cross words depend on the size and difficulty.
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.
> 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. :-)
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?
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.
> 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.
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.
Engineer: “It will take me two days [of work].” Sales:”We will have your fix ready in three calendar days [today + 2].”
Actual work that week gives employee 3 hours of non-meeting time, each daily meeting adds 0.5 hours of high-urgency administrative work. Friday’s we have a mandatory all-hands town halls…
Repeat that cycle for every customer facing issue, every demo facing issue, and internal political issue and you quickly drive deep frustrations and back talking.
I think there’s a fundamental truth: no one in their right minds, not even motivated engineers, actually hears anything but calendar when getting “days” estimates. It’s a terrible misrepresentation almost all the time, and engineers do a disservice when they yield to pressure to deliver them outside the broader planning process.
Project schedules should be the only place that time commitments come from, since they’re informed with necessary resource availability.
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.
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.
With respect, I think this approach is actually harmful to everyone in the org because you're trying to twist reality to fit a premise that is just impossible to make true: that estimates of how long it takes to build software are reliable.
The reluctance to accept the reality that it cannot be made true achieves nothing positive for anybody. Rather it results in energy being lost to heat that could otherwise be used for productive work.
This isn't about respect between functions, this isn't about what ought to be professionally acceptable in the hypothetical. It's about accepting and working downstream of a situation based in objective truth.
Believe me, I wish it were true that software estimates could be made reliable. Everyone does. It would make everything involved in making and selling software easier. But, unfortunately, it's not easy. That's why so few organisations succeed at it.
I don't present easy answers to the tensions that arise from working downstream of this reality. Yes, it's easier to make deals contingent on firm delivery dates when selling. Yes, it's easier to plan marketing to concrete launch dates. Yes, it's easier to plan ahead when you have reliable timeframes for how long things take.
But, again unfortunately that is simply not the reality we live in. It is not easy. Flexibility, forward planning and working to where the puck is going to be, and accepting redundancy, lost work, or whatever if it never arrives there is part of it.
That I think is what people in different functions are best served rallying and collaborating around. One team, who build, market and sell software with the understanding that reliable estimates are not possible. There simply is no other way.
> you're trying to twist reality to fit a premise that is just impossible to make true: that estimates of how long it takes to build software are reliable.
It's not binary, it's a continuum.
With experience, it's possible to identify whether the new project or set of tasks is very similar to work done previously (possibly many times) or if it has substantial new territory with many unknowns.
The more similarity to past work, the higher the chance that reasonably accurate estimates can be created. More tasks in new territory increases unknowns and decreases estimate accuracy. Some people work in areas where new projects frequently are similar to previous projects, some people work in areas where that is not the case. I've worked in both.
Paying close attention to the patterns over the years and decades helps to improve the mapping of situation to estimate.
Yes, but where reliability is concerned, a continuum is a problem. You can't say with any certainty where any given thing is on the continuum, or even define its bounds.
This is exactly what makes estimates categorically unreliable. The ones that aren't accurate will surprise you and mess things up.
In that sense, it does compress to being binary. To have a whole organisation work on the premise that estimates are reliable, they all have to be, at least within some pretty tight error bound (a small number of inaccuracies can be absorbed, but at some point the premise becomes de facto negated by inaccuracies).
Software estimates for projects that don't involve significant technical risk can be made reliable, with sufficient discipline. Not all teams have that level of discipline but I've seen existence proofs of it working well and consistently.
If you can't make firm delivery commitments to customers then they'll find someone who can. Losing customers, or not signing them in the first place, is the most harmful thing to everyone in the organization. Some engineers are oddly reluctant to accept that reality.
> If you can't make firm delivery commitments to customers then they'll find someone who can.
Rather: the customer will find someone who can confidently pretend that thet can make firm delivery commitments.
That assumes you’re working in some kind of agency or consulting environment where you repeatedly produce similar or even distinct things. As opposed to a product company that has already produced and is humming along, which is when most people get hired.
Estimating the delivery of a product whose absence means zero product for the customer is very different. A company that’s already humming along can be slow on a feature and customers wouldn’t even know. A company that’s not already humming is still trying to persuade customers that they deserve to not die.
Not at all. This can work fine in product development, as long as you limit the level of technical risk. On the other hand, if you're doing something really novel and aren't certain that it can work at all then making estimates is pointless. You have to treat it like a research program with periodic checkpoints to decide whether to continue / stop / pivot.
There is an enterprise methodology that increases precision of project estimation.
1. Guess the order of magnitude of the task (hours vs days/months/years)
2. Add known planning overhead that is almost order of magnitude more.
Example: if we guess that task will take 30min, but actually it took 60min - that’s 100% error (30min error/30min estimate).
But if the methodology is used correctly, and we spend 2h in a planning meeting, same estimate and same actual completion time results in only 20% error, because we increased known and reliable part of the estimate (30min error / 2h30min estimate)
There’s no binary switch between estimable and not. Depends a lot on industry and novelty of work. Then estimates will be given in ranges and padded as needed by previous work. This gets a project into regularity.
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.
> 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.
Former Test Engineer here. It was always fun when everyone else’s deadline slipped but ours stayed the same. Had to still ship on the same date even if I didn’t have silicon until much later than originally planned.
Yep, you and layout folks drew the short straws.
What was the thing you were estimating? R&D?
I think you were estimating time to build things that were out of R&D and you had specifications that were actual specifications you were building up to.
In SaaS my experience is: someone makes up an idea not having any clue how existing software is working or is laid out, has no specifications beside vague not organized bunch of sentences. Software development team basically starts R&D to find out specifications and what is possible - but is expected to deliver final product.
I had the same experience when doing an exercise implementing `mmap` for `xv6` -- that was the last lab. There was no specification except for a test file. Passing that test file is relatively easy and I could game it. I consulted the manpage of `mmap` but it is pretty far from a specification, so eventually I had to write a lot of tests in Linux to figure out what it can do and what it can't do (what happens when I over-mmap? what happens when I write back pass EOF? etc.), and write the same tests for `xv6` so that I could test my implementation. Not sure about hardware, but it is really hard to get a clear specification for software.
This aligns with my experience in the semi industry. SWEs tend to see trimming scope as moving the goalpost and do not consider as an option. Providing advance notice is mostly about client management, and clients are often surprisingly receptive to partial solutions.
> Trim features, push date, bring in extra help, or crunch.
There are problems with all of these. The company knows they can sell X of the product for $Y (often X is a bad guess, but sometimes it has statistical range - I'll ignore this for space reasons but it is important!). X times Y equals gross profit. If the total costs to make the feature are too high the whole shouldn't be done.
If you trim features - the affects either the number you can sell, or the price you can sell for (sometimes both).
If you push the date that also affects things - some will buy from a competitor (if possible - and the later date makes it more likely the competitors releases with that feature).
Bring in extra help means the total costs goes up. And worse if you bring them in too late that will slow down the delivery.
Crunch is easiest - but that burns out your people and so is often a bad answer long term.
This is why COMPANIES NEED ACCURATE ESTIMATES. They are not optional to running a company. That they are impossible does not change the need. We pretend they are possible because you cannot run a company without - and mostly we get by. However they are a fundamental requirement.
If your business model needs the impossible then it's a bad business model. If your margins are too thin to absorb the schedule uncertainty then don't produce software.
Alternatively treat it like a bet and accept it may not pay off, just like any other business where uncertainty is the norm (movies, books, music).
> This is why COMPANIES NEED ACCURATE ESTIMATES. They are not optional to running a company.
Sure, but even accurate estimates are only accurate as long as the assumptions hold.
Market conditions change, emergency requests happen, people leave, vendor promises turn out to be less than accurate.
And most estimates for non-routine work involve some amount of risk (R&D risk, customer risk, etc.).
So pounding the table and insisting on ACCURATE ESTIMATES without a realistic backup plan isn’t good business, it’s just pushing the blame onto the SWE team when (not if) something goes south.
I would settle for accurate estimates being a requirement if sticking to the estimate and allocations is as well. Every project I've been a part of that has run over on timeline or budget had somebody needling away at resources or scope in some way. If you need accuracy to be viable, then the organization cannot undermine the things that make it possible to stay on track.
Also, if you need accuracy stay away from questionable vendors of 3rd party products, as much as possible since they are chaos generators on any project involved.
In my work we have our core banking system designed in 80s on top of Oracle DB so everything is just boxes around it, with corresponding flexibility towards modern development methodologies. The complexity of just doing a trimmed copy of production servers for say user acceptance test phase is quite something, connecting and syncing to hundreds of internal systems.
Needless to say estimates vs reality have been swinging wildly in all directions since forever. The processes, red tape, regulations and politics are consistently extreme so from software dev perspective its a very lengthy process while actual code changes take absolutely tiny time in whole project.
Companies need accurate estimates like I need accurate stock market forecasts.
They don't NEED them, but better project estimates can reduce the error bars on other dependent estimates (e.g. estimated sales, estimated ship dates, estimated staffing requirements, etc...), and that might be useful to a business (or not).
This is true, but the problem is that engineers are being asked to over-extrapolate given the evidence, and expected to own that extrapolation despite the paucity of evidence to make a good estimate.
I *HATE* estimating roadmaps, because it feels unfair. I'm happy to estimate a sprint.
Yes. I took over the project management of a job where the previous project manager had spent a year planning it out, but development had not yet started. The client was furious, understandably.
I abandoned the plans from the previous PM and discussed the job with the developer who ballpark estimated that the work would take 2 months. After a quick analysis I adjusted this to 14 weeks.
But the account manager thought this sounded too long and insisted that we plug everything in to a Gantt chart, define the shit out of everything, map the dependencies, etc, which showed that the development would only take 6 weeks.
The project ended up taking 14 weeks.
In another life, I would do things like measure the cost in developer time of bugs making it into developer repos vs. the cost in time of running tests in CI to catch such bugs, so evidence based decision making. It was mostly ignored, and at first I was surprised. A multi million dollar organization of people making negative EV plays, which I chalked up to the political pressures being more important than the wastage. More on that later.
As far as estimates go, I've also struggled with the industries cult(ural) rituals. I tried to put forward a Gaussian based approach that took into account not only the estimate of time, but the expected uncertainty, which is still probably off the mark, but at least attempts to measure some of the variance. But again, the politics and the rigidity of the clergy that has built around software development blocked it.
On the bright side, all this has helped me in my own development and when I think about software development and estimating projects. I know that outcomes become more chaotic as the number of pieces and steps compound in a project (i.e. the projects normal curve widens). You may not even get the project at all as defined at the outset, so my normals approach is still not quite the right tool.
I think this kind of thinking can be helpful when working solo or in a small group who are exposed to market forces. But for solo and small groups, the challenge isn't so much about the estimates, it's about how you're going to fight a battalion of mercenaries hired by big VC money and Big Tech. They can often afford to be inefficient, dump in the market, because their strategy is built around market control. These aren't practices small players can afford, so you need to get creative, and try to avoid these market participant kill boxes. And this is why, coming back to my earlier point, that often times, inefficient practices and politics plays a big role. Their trying to marshal a large number of troops into position and can afford to lose a few battles in order to win the war. The big money plays by a different set of rules, so don't worry if their doing it wrong. Just recognize your in the army soldier!
It's sad how software organizations refuse to learn from history. The US Navy was using PERT to manage huge, risky projects back in the 1950s with pretty good results. It can give you a Gaussian distribution of project completion dates based on best / middle / worst case estimates for individual tasks with dependencies.
https://en.wikipedia.org/wiki/Program_evaluation_and_review_...
You estimate your best and then during the project the people who keep changing the spec every two weeks ask why the deadline is slipping.
It's definitely unfair in a sense. But companies that make over-extrapolated roadmap estimates from not enough evidence systematically outcompete those who don't, because their customers greatly prefer companies who give a date and then try their best to hit it over companies who say they don't know when the product will be ready for X and you'll just have to wait and see.
I get that, and I don't mind giving guidance on roadmaps, it's just the ownership when stuff outside my control goes wrong that bothers me. I shouldn't be responsible for product going in circles on little details with the customer causing req churn, yet I have been held accountable for missing estimates under that exact circumstance.
Yes, the key part of estimation is not that we need to say how large must be the (time) box to contain the project, but rather how much of a project can we pack into a box no larger than what the business could bear.
Hence the separation into must-haves, highly desirable, and nice-to-haves. Hence the need for modularity and extensibility: you if don't get to build everything in one go, and can't always even predict what parts would be left outside the scope, you have more of a lego-like structure.
BTW maybe if we finally shook off the polite lie of planning how much work a project could be, and instead started to think in terms of possible deliverables within different time frames, the conversation would become saner.
I agree whole-heartedly with the source article as well as this comment. The point is that the work of estimation is most of the work. We can have better estimates if we break things down to bite-sized chunks, but "when will this be done" is largely impossible and comes down to many external factors. Laypeople understand this implicitly in other contexts.
My favorite metaphor is building something like a new shopping mall. If you ask for an estimate you first need to architect the entire thing. This is equivalent to breaking down the task into sprints. In most companies the entire architecture phase is given very little value, which is insane to me.
Once we have our blueprints, we have other stakeholders, which is where things really go off the rails. For the mall, maybe there is an issue with a falcon that lives on the land and now we need to move the building site, or the fixtures we ordered will take 3 extra months to be delivered. This is the political part of estimating software and depends a lot on the org itself.
Then, finally building. This is the easy part if we cleared the precursor work. Things can still go wrong: oops we hit bedrock, oops a fire broke out, oos the design wasn't quite right, oops we actually want to change the plan.
But yes, estimates are important to businesses. But businesses have a responsibility to compartmentalize the difference. Get me to a fully ticketed and approved epic and most engineers can give you a pretty good estimate. That is what businesses want, but they consider the necessary work when they Slack you "how long to build a mall?"
I've also seen it argued that real world estimates for things like construction projects are so good because 99% of it is do-overs from similar projects in the past; everyone knows what it takes to pour a column or frame a floor or hang a beam.
Whereas with software most of what was done previously is now an import statement so up to 80-100% of the project is the novel stuff. Skilled leaders/teams know to direct upfront effort toward exploring the least understood parts of the plan to help reduce down-stream risk but to really benefit from that instinct the project plan has to regularly incorporating its findings.
Real world estimates for construction projects are often way off. Especially for remodeling or renovation of older buildings, where the most serious problems can remain hidden until you get into the demolition phase.
Indeed yes. Union Station in Toronto has been like this; twenty years in and no end in sight because every wall they open reveals more problems to solve.
I agree. Software engineering is basically the only industry that pretends this is professionally acceptable. Imagine if government staff asked when a bridge would be done or how much it would cost and the lead engineer just said "it's impossible to estimate accurately, so we wont. It's a big project tho".
Estimating in software is very hard, but that's not a good reason to give up on getting better at it
Government contractor's estimation is based on what number is politically acceptable, not how much the project would realistically take. 90% of public projects were overbudget [0].
But you're pretty spot on, as 'professionally acceptable' indeed means politically acceptable most of the time. Being honest and admitting one's limit is often unacceptable.
[0]: https://www.strategy-business.com/article/Why-do-large-proje...
Yes, my claim is absolutely not that they're good at it haha.
Estimation is a real problem in a lot of industries, including ours, and I think that's probably common ground here -- I suppose my differing position is that I think the solution is to get better at it, not to refuse to do it.
I've been on projects where I've seen the budget explode and projects where I've seen the budget kept tight and on track. The latter is very hard and requires effort from ALL sides to work, but it's almost always achievable.
I actually empathize a little bit more with megaprojects because generally the larger the budget the harder it will be to keep on track in my experience. Most estimates we're asked to give in our day jobs are not even multi-million dollar estimates.
Also I'm using budget and estimate interchangeably but these are of course different things -- that's one of my nitpicks is that we often treat these as the same thing when we talk about estimating being hard. A lot of individual estimates can be very wrong without affecting the ultimate budget.
Contractor estimates are just as prone to schedule slippage and cost overruns as anything estimated by software engineers. I doubt anyone's ever argued that giving wrong estimates is hard or impossible. Only that approximately correct ones are, and other industries seem to struggle with that just as much as software. Authors don't finish books by deadlines, so fans are left in the cold. Tunnels take twice as long and cost twice as much. Renovations take a year instead of 3 months and empty your bank account.
Saying "I don't know" is arguably more honest, even if it's not useful for budgets or planning.
> Contractor estimates are just as prone to schedule slippage and cost overruns as anything estimated by software engineers
I completely agree. That's why I chose that example: They're also awful at it, especially these days in North America in particular. But any contractor that tried to put in a bid claiming "it'll be done when it's done and cost what it costs" would not be considered professionally competent enough to award a multi-million dollar budget.
The date is just a useful fiction to:
- Create urgency
- Keep scope creep under control
- Prioritize whatever is most valuable and/or can stand on its own
If you just say “I don’t know” and have no target, even if that’s more honest, the project is less likely to ever be shipped at all in any useful form.
Ever heard of Big Dig in Boston, for example? Or the Joint Strike Fighter?
Estimations in government contracts are as ridiculous as in software. They just pretend to be able to estimate when things will be done, when, in fact, the contractors are as clueless.
Not being able to say "it is impossible to estimate", does not mean your estimate will be correct. That estimation is usually a lie.
Not a good analogy. Once you build a bridge, it’s done. Software nowadays is never “done”, and requirements constantly change. It’s more akin to building a rope bridge and trying to upgrade it to accommodate cars while it’s in active use.
Sounds like you don't have a good process for handling scope changes. I should know, the place I'm at now it's lacklustre and it makes the job a lot harder.
Usually management backs off if they have a good understanding of the impact a change will make. I can only give a good estimate of impact if I have a solid grip on the current scope of work and deadlines. I've found management to be super reasonable when they actually understand the cost of a feature change.
When there's clear communication and management decides a change is important to the product then great, we have a clear timeline of scope drift and we can review if our team's ever pulled up on delays.
I feel like some people in this thread are talking about estimates and some are talking about deadlines. Of course we should be able to give estimates. No, they're probably not very accurate. In many industries it makes sense to do whatever necessary to meet the estimate which has become a deadline. While we could do that in software, there often isn't any ramifications of going a bit overtime and producing much more value. Obviously this doesn't apply to all software. Like gamedev, especially before digital distribution.
I think it's obvious that all software teams do some kind of estimates, because it's needed for prioritization. Giving out exact dates as estimates/deadlines is often completely unecessary.
The real problem is software teams being given deadlines without being consulted about any sort of estimates. "This needs to be done in 60 days." Then we begin trading features for time and the customer winds up getting a barely functioning MVP, just so we can say we made the deadline and fix all the problems in phase 2.
OK, so that sounds fine. Software delivers value to customers when it's better than nothing some of the time. Even if it barely functions then they're probably happier with having it than not, and may be willing to fund improvements.
When customers ask when feature X will be ready, they sure have an idea of done in their mind.
Sure, so extract the customer's definition of done as part of requirements analysis process and write it down. Get them to agree in writing, including the explicit exclusion of other things that aren't part of their idea of done.
When the government asks how much project X costs they find ten companies that promise the moon and then deliver a wheel of cheese for five times the estimated cost.
They miss estimates all the time though? It’s an observable fact
There is a bridge in my town that is finally nearing completion, hopefully, this year. It was estimated to be completed 2 years ago.
This changes when it’s a project that has fewer unknowns, where they’ve built the same thing several times before. The same is true in software.
Incorrect analogy. Bridge construction is a clearly algorithmic process. All bridges resemble each other, and from an engineering perspective, designing one is not rocket science. Construction itself is a set of well-studied steps that can be easily calculated. If I were to write my operating system 100 times, I could give an estimate accurate to within 10%, but every task I’ve ever done in life is unique, and I have nothing to compare it to except intuitive judgments. Returning to bridges: there is 1% of projects that are unique, and their design can take decades, while construction might not even begin
Software engineering isn't some magical, special branch of engineering in which no one piece of software resembles another, no well-studied steps can be replicated, and the design of which is equivalent to rocket science.
If you're truly creating such unique and valuable software that it is to be compared to the world's engineering megaprojects in its challenge then perhaps it is beyond being beholden to a budget. Who am I to say?
But 99.9% of this industry isn't doing that and should probably be able to estimate their work.
I’m not talking about difficulty; I’m talking about uniqueness—uniqueness for me personally. There are people who spend their whole lives designing bridges. I, on the other hand, have been writing software for 15 years, and almost every task I encounter is unlike the previous one. I’m not saying it’s difficult, but solving it requires gaining new experience that will be useless for future tasks. Sometimes, I have to do something similar to a previous task, but in 90 percent of cases, I first need to create documentation on how it currently works, figure out how to turn a task description consisting of a 15-word headline into a set of concrete actions, and then test it.
>>>> In a functioning org, there are lot of professionals depending on correct estimation to do their job.
A side effect is, no there aren't. Allow me to explain that catty remark.
The experienced pro's have figured out how to arrange their affairs so that delivery of software doesn't matter, i.e., is someone else's problem. The software either arrives or it doesn't.
For instance, my job is in technology development for "hardware" that depends on elaborate support software. I make sure that the hardware I'm working on has an API that I can code against to run the tests that I need. My department has gone all-in on vibe coding.
Customers aren't waiting because the mantra of all users is: "Never change anything," and they can demand continued support of the old software. New hardware with old software counts as "revenue" so the managers are happy.
I think the hardest part of estimation often gets glossed over: genuine technical unknowns. Not "we didn’t think hard enough," but cases where the work itself is exploratory.
The most effective approach that I've found to prevent delays in large scale software projects is to carve out a dedicated team to deal with critical bugs, L3 support tickets, and urgent minor enhancements. Don't count them in capacity planning. They serve to insulate the feature teams from distractions. Rotate those assignments for each project so that everyone takes a turn.
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.
That's why the right way to do it is to have a hard deadline given to engineers, then the engineers cut whatever scope is needed to actually wrap something up by the deadline
It all starts with sales and marketing cramming every possible feature and half-rumour they heard about competitors' features into a 6 month project deadline. That's a long time, 6 months, no? How hard can it be? Respectfully, it'll be done when it's done.
we are the ones qualified to say what needs to be cut to provide reasonable certainty for the deadline. it is not the job of non-technical stakeholders to mitigate risk in technical projects
> who have to put up with us
this kind of (self-)deprecation is exactly the kind of thing that makes it impossible to be happy as a technical person in a startup
> "when it's done" is somehow acceptable for the rest of the business to function.
Well, it is the truth. It won't be done before it is done. It is understandable that there is a business that needs to function, but the issue here is the question of asking for an estimate like you've already solved the problem, instead of actually sitting down with the engineer to discuss the business problems that need to be solved. That's what engineers are there for: To solve business problems. Estimates are irrelevant as the solution will be designed with the business constraints in mind.
> it's quite doable to break a large project down into a series of sprints
This too comes across like the problem is already solved. You don't need to break problems down into sprints. That is a ridiculous way to operate. This kind of thing only shows up where there is some weird effort to separate engineers from their jobs.
In fact, "sprint" comes from Scrum, which was designed to be a transitionary exercise to get engineers more comfortable with Agile, which is all about removal of managers. It is intended to teach engineers to think and act more like managers so that when you get rid of the managers completely that they don't flounder. If you are doing it as more than a temporary thing, you've entirely missed the point.
"us"
The most important part of the article is ”I gather as much political context as possible before I even look at the code.”
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.
"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."
Except managers also have expectations of what can be done
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.
I'm a dev, not a salesperson, but let's be realistic. A company tells you "yeah we're interested in signing at $1M/yr, but we really need this feature, when will you have it by?", to which saying "eh we don't know - it'll be done when it's done" will lead to the company saying "ok well reach out when you have it, we can talk again then" (or just "eh ok then not a good fit sorry bye"), and in the meantime they'll go shopping around and may end up signing with someone else.
Having a promised date lets you keep the opportunity going and in some cases can even let you sign them there and then - you sign them under the condition that feature X will be in the app by date Y. That's waaaay better for business, even if it's tougher for engineers.
“Sign up and pay at least part of it now and we’ll prioritize the feature”.
I’ve seen enough instances of work being done for a specific customer that doesn’t then result in the customer signing up (or - once they see they can postpone signing the big contract by continuing to ask for “just one more crucial feature”, they continue to do so) to ever fall for this again.
Why do that if your competitor already has it? I'd just go talk to the competitor instead. If you aren't able to ballpark when the feature will be done, why should I trust you will once I pay part of the price?
If the competitor already has it why are you talking to me? :)
Because you have other benefits, so we'd really like to switch over to you, but we can't unless you support this dealbreaker feature that your competitor we're currently using has.
No, parent said they’d go talk to the competitor. They didn’t say they were already with them. Don’t change the scenario.
Because you have other benefits, so we'd really like to use you, but we can't unless you support this dealbreaker feature that your competitor has.
Just to consider the opposite viewpoint, I sometimes wonder if it's not better that they do churn in that case. Assuming the sales team is doing their job properly, there are other prospects who may not need that feature, and not ramming the feature in under time constraints will lead to a much better product. Eventually, their feature will be built, and it will have taken the time that it needed, so they'll probably churn back anyway, because the product from the vendor they did get to ram their feature in is probably not very good.
I understand the intuition, but it's a misunderstanding of how software sales operates. There's no tradeoff between prospects who need new features and prospects who don't, because salespeople love that second category and you'll have no problem hiring as many as you need to handle all of them.
Unless its the first time they are hearing about it, when a customer asks about a feature, sales should've done their homework and checked with the team doing the work to get a rough estimate instead of pulling a number out of their behinds.
The top down push for timelines is because:
In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects.
I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought about and carefully accounted for, BUT in the specific case where it's their own days of effort, those don't feel like money.
Also, the software itself presumably has some impact or outcome and quite often dates can matter for that. Especially if there are external commitments.
The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development.
1. Think about what product/system you want built.
2. Think about how much you're willing to invest to get it (time and money).
3. Cap your time and money spend based on (2).
4. Let the team start building and demo progress regularly to get a sense of whether they'll actually be able to deliver a good enough version of (1) within time/budget.
If it's not going well, kill the project (there needs to be some provision in the contract/agreement/etc. for this). If it's going well, keep it going.
How would you decide between doing project (a) this quarter, or project (b)?
If you cannot (or refuse to) estimate cost or probability of success in a timebox you have no way to figure out ROI.
To rationally allocate money to something, someone has to do the estimate.
The exact same way you'd treat any other investment decision.
In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising.
You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.
You mean… by making a forward-looking estimates of cost, time-to-value, return? (even if it's implicit, not documented, vibes-based?).
When devs refuse to estimate, it just pushes the estimating up the org chart. Execs still have to commit resources and do sequencing. They’ll just do it with less information.
What you're asking is the equivalent of going to a company whose equity you've bought and asking them: what's the price going to be in 6 months' time?
Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.
Sorry, I edited the plumbing refence out of my comment because I saw a sibling post that made a similar point.
I agree there is less uncertainty in plumbing - but not none. My brother runs a plumbing company and they do lose money on jobs sometimes, even with considerable margin. Also when I've needed to get n quotes, the variation was usually considerable.
I think one big situational difference is that my brother is to some extent "on the hook" for quotes (variations / exclusions / assumptions aside) and the consequences are fairly direct.
Whereas as an employee giving an estimate to another department, hey you do your best but there are realistically zero consequences for being wrong. Like maybe there is some reputational cost? But either me or that manager is likely to be gone in a few years, and anyway, it's all the company's money...
How much plumbing knowledge do you have?
I bet if SWEs were seeing anywhere near that 1.5k per day they’d be more inclined to pay attention.
But when you get paid less than half that it doesn’t feel like a problem to worry about. At 300/day of take-home pay, one more day here or there really isn’t going to make a difference.
If you hired someone to do some work on your house, and they refused to give an estimate, would you be happy?
If you had a deadline - say thanksgiving or something - and you asked “will the work be done by then” and the answer was “I’m not going to tell you” would you hire the person?
The no estimates movement has been incredibly damaging for Software Engineering.
If work on a house was specified like a typical software project, no builder would even return your call.
"I'd like to have my roof reshingled, but with glass tiles and it should be in the basement, and once you are half way I'll change my mind on everything and btw, I'm replacing your crew every three days".
Sure, for roofing jobs or other large repairs, that’s true. But for remodeling it’s pretty different.
When I’ve engaged with a contractor for remodeling, I usually have some vague idea like “we should do something about this porch and deck and we’d like it to look nice.”
The contractor then talks to you about _requirements_, _options_, and _costs_. They then charges for architectural plans and the option to proceed with a budget and rough timeline.
Then they discover problems (perhaps “legacy construction”) and the scope creeps a bit.
And often the timeline slips by weeks or months for no discernible reason.
Which sounds exactly like a lot of software projects. But half of your house is torn up so you can’t easily cut scope.
But the correct response to that is not - "I'm not going to tell you how long that will take" it's "let's work out what you are trying to accomplish".
Though the "I'm replacing your crew every three days" does cut a little too close the bone...
Painting a wall has no “if then else”. You dont need to test to see if the wall has been painted.
I guess a fair analogy would be if the home owner just said “Make my home great and easy to use” by Thanksgiving without too many details, and between now ans thanksgiving refines this vision continuously, like literally changing the color choice half way or after fully painting a wall… then its really hard to commit.
If a home owner has a very specific list of things with no on the job adjustments, then usually you can estimate(most home contract work)
All software requests are somewhere in between former and latter, most often leaning towards the former scenario.
Building a house, adding an extension, replacing a bathroom, building a deck. Many unknowns - you'd still expect an estimate.
When there are huge unknowns, such as in the case of a remodel where who knows what you might find once the drywall is removed, then yes. I happily worked with a contractor on a basement renovation with no estimate for this exact reason.
If it’s something where they have fewer unknowns and more control and lots of experience building the same thing, then I would expect an estimate: building a deck, re-roofing a house, etc
My experience with contractors is limited, but in all nontrivial cases I recall they took longer than estimated and it ended up costing more.
Most businesses like to pretend change orders don't apply to software.
Then you need a new estimate. That is not hard to comprehend.
For any slightly complicated project on a house the estimate assumes everything goes right, which everyone knows it probably won't. It's just a starting point, not a commitment.
Definitely so. Most business people that I've worked with do understand that. And provided problems are communicated early enough can manage expectations.
Where I've seen issues is when there is a big disconnect and they don't hear about problems until it's way too late.
Anybody who worked with a local contractor knows that their estimate and the reality has no correlation.
When you ask for a firm estimate, you are basically asking to be lied to, and the contractor happily complies by telling you a lie.
These are just bad contractors. I used to work for a remodeling company. We came in under time on the vast majority of projects because the guy who ran the company knew what he was doing and built slack into the schedule.
I think this is unfair to sales.
I've made your argument before, but realistically, much of the word revolves around timelines and it's unreasonable to expect otherwise.
When will you recover from your injury so you can play the world cup?
When will this product arrive that I need for my child's birthday?
When will my car be repaired, that I need for a trip?
How soon before our competitors can we deliver this feature?
"It'll be done when it's done" is very unsatisfying in a lot or situations, if not downright unacceptable.
But it's the reality of engineering. If reality is unacceptable, that's not reality's problem.
But the problem is, the sales world has its own reality. The reality there is that "we don't know when" really is unacceptable, and "unacceptable" takes the form of lost sales and lost money.
So we have these two realities that do not fit well together. How do we make them fit? In almost every company I've been in, the answer is, badly.
The only way estimates can be real is if the company has done enough things that are like the work in question. Then you can make realistic (rough) estimates of unknown work. But even then, if you assign work that we know how to do to a team that doesn't know how to do it, your estimates are bogus.
I don't know that it's the reality of engineering. (Edit: in fact there are some comments for this post providing counterexamples, an interesting one is the hardware world).
It's what we software engineers like to tell ourselves because it cuts us slack and shifts the blame to others for budget and time overruns. But maybe it's also our fault and we can do better?
And the usual argument of "it's not like physical engineering, software is about always building something new" because that's only true for a minority of projects. Most projects that fail or overrun their limits are pretty vanilla, minor variations of existing stuff. Sometimes just deploying a packaged software with minor tweaks for your company (and you must know this often tends to fail or overrun deadlines, amazingly).
I know another "engineering" area where overruns are unacceptable to me and I don't cut people slack (in the sense it's me who complains): home building/renovation contractors. I know I'm infuriated whenever they pull deadlines out of their asses, and then never meet them for no clear reason. I know I'm upset when they stumble over the slightest setbacks, and they always fail to plan for them (e.g. "we didn't expect this pipe to run through here", even though they've done countless renovations... everything is always a surprise to them). I know I'm infuriated when they adopt the attitude of "it'll be done when it's done" (though usually they simply lie about upfront deadlines/budgets).
Maybe that's how others see us from outside software engineering. We always blame others, we never give realistic deadlines, we always act surprised with setbacks.
> maybe it's also our fault and we can do better?
Part of it is absolutely our fault; part of it is the industry.
In the electronics world, when you need <common functionality>, you can find an off-the-shelf part that fits your requirements, fit that part in and it'll work. When you need logic in a hardware device, nobody's rolling their own CPU from discrete parts - they just take the cheapest microcontroller fitting the requirements.
In the software world we don't seem to have this concept of building blocks for common functionality even decades into the industry. Most software projects are some flavor of CRUD app with custom logic operating on the CRUDed objects. You'd think all the complexity would be in the custom logic, but actually it's at best 50-50 and at worst most of the complexity is in the whole CRUD bullshit and not what happens to the object once it's CRUD'ed.
How come in 2026 there's still no way to have an off-the-shelf component I can buy to do "I have a table of objects on the server, and I want to expose this as a UI to the client"? Why do I still see people writing this by hand in React/$JS-framework-of-the-day and messing around with things like OpenAPI and/or writing serializers/deserializers by hand? I swear most of the work I see in the web development space is the minutia between client/server communication.
I think there are several reasons:
* overengineering/resume-driven-development: even if there was to be an off-the-shelf component to do the task, people would probably avoid it and prefer to bullshit around reimplementing a (worse) solution. That's already the case where people are using React/SPAs/etc for views that do no need any interactivity and could just be an HTML form.
* political choices influencing tech selection: more often than not some tech or service provider is selected based on political reasons and not technical, and then the engineering challenge becomes as to how to shoehorn this ill-fitting part into our solution.
* aversion to paid software: hardware engineers are expected and allowed to select parts that cost money. I've never been on a software project where we had an explicit budget for licensing software. Reaching for paid software became the least resort option I'd have to fight for and burn political points, while spending 10x the cost building a (shittier) replica in-house was considered fine.
Due to the last point there's also little incentive for software providers to build and sell such components, so the market is quite small and not competitive, with the (very few) competitors having their own dealbreakers. Firebase will give you the instant database and UI, but then you're forever tied to paying them rent. You can't just license the server component and install it in-house like you can buy an FPGA.
Anyone from a sales roll care to speak to this?
Sales gets fired (or not paid) for missing their estimates (quotas, forecasts) and often have little empathy for engineering being unable to estimate accurately.
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.
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-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/Cpjour...>
Martin Fowler cites this in his 2005 essay about agile programming, "The New Methodology"<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-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.
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
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.
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.
> 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.
The old guys in the 80's and 90's would say kiddingly multiply your original estimate time pi (3.14).
Several times, to be sure
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"?
> 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.)
> But plenty can be estimated more accurately.
As a person that has never encountered a complex software project that can be accurately estimated, I am being a bit skeptical.
The author did make examples of when estimation is possible: easy projects with a very short time horizons (less than an a couple of days, I'd say).
I'd love to hear some examples of more complex software projects that can be estimated within a reasonable variance.
However, I think it should also be acknowledged that the point of the article seems to be in a different direction: it _doesn't really matter_ that you have a good time estimate, because asking for an estimate is just a somewhat strange way for the management chain to approach you and then tell you how much time you have to deliver.
> easy projects with a very short time horizons (less than an a couple of days, I'd say).
The example I quoted said hours, not days. But even taking your claim of days as estimable, I have seen much better.
An example of weeks-long projects I regularly estimate accurately would be things like “in our Django monolith, add this new field/model, and update the state machine with these new transitions, and update the API, and surface the feature in the UI, including standard e2es and UT coverage”. With a team of 10-15 we regularly hit days-to-weeks estimates with in the ballpark of 90% accuracy. (Ie 1-in-10 slips)
An example of year-long projects I have seen waterfall’d successfully are IP protocol implementations where the RFC is clear, base frameworks exist, and the org has engineers with decades of individual experience implementing protocols in the same framework. IOW you have senior-staff or principal engineers on the project.
> the point of the article seems to be in a different direction: it _doesn't really matter_ that you have a good time estimate
I think the idea that you always start with time and define the work is also myopic. In some dysfunctional orgs I’m sure this is true, but it’s not the whole picture.
For the fully-generalized principle at play here, I’m a big believer in the “cost / time / scope” tradeoff triangle. In other words, pick two as your free parameters, and the third is then determined. Sometimes time is the output of a calculation, and resource/scope are the input. Sometimes time can be the input and scope the output. It depends.
But the article opens by claiming it’s impossible to estimate time, given a fixed scope and cost(resource) input, which is simply false/over-generalizing.
> An example of year-long projects I have seen waterfall’d successfully are IP protocol implementations where the RFC is clear, base frameworks exist, and the org has engineers with decades of individual experience implementing protocols in the same framework.
Article responds to you with:
“For most of us, the majority of software work is not like this. We work on poorly-understood systems and cannot predict exactly what must be done in advance. Most programming in large systems is research…”
It is good to target the strongest point, not the weakest.
> The example I quoted said hours, not days.
Yeah, that's a cop-out. All the easy things are easy! Well, yes, they are. It's the hard ones that -you know- are hard. That the easy things are easy is no real objection to TFA, it's just pedantry.
> (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.)
Maybe, just maybe, it's because "the heavyweight process/rituals required to be accurate" might not be productive, and because being startups, and therefore small organizations, it's easier for everyone to know who's pulling their weight and who isn't, therefore "heavyweight process/rituals" add nothing and cost too much.
Mature organizations tend to "implement the heavyweight process/rituals required to be accurate" precisely because they are too large for everyone to know everyone, and so senior management loses touch with reality and starts feeling anxious about whether their R&D spend is yielding value. This is totally understandable, and we have to have empathy for executives, but there is tremendous danger in this approach. How many mature market leaders have had their lunch eaten by disruptive innovators (invariably startups)? And why? Maybe those "heavyweight" processes kill innovation! That urge to accurately measure what the org's devs are doing can be counterproductive.
All measures but one (so far) are gameable. So far only KTLO fraction, which one should couple with promoting a management culture that allows subjective value judgements to make it up and down the chain. Management of knowledge work essentially is a social problem, not a scientific one.
Did you read the article? They go on explain how you actually do it, in a very reasonable way.
Hi! “Did you read the article” is generally not in compliance with the HN community guidelines. Please don’t do this.
Pedantic commentary isn't terribly useful either.
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.
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.
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.
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.
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.
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
Excellent example why anything else than work hours is pointless to estimate in.
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.
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 :)
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.
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.
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.
You can improve if you follow up the estimates. My team had several months when we were within +- 10% in the aggregate.
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?
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.
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.
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.
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.
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.
But how long it'll take you to make that PoC? Any idea? :P
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.
> 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.
Are you me? We do the same thing, and they also translate it into hours by averaging across the whole team's velocity.
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.
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?
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.
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.
For me, estimates are done to make the job of management easier and make life of the developer harder.
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.
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.
> 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.
> 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.)
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.
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.
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.
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.
Coming back at this with a fresh mind, whoever said it could also have meant that every painting should be displayed: it requires a wall to hang on.
As you say, it's not immediately clear what is meant.
Even more evidence of how versatile that French phrase is. There's just so many acceptable meanings to it, and every one of them points to the same conclusion: bounds enable art.
At my job we do all of our work estimations through a prediction market. Accurate predictions give real money payouts. Works great!
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.
> 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.
I love this - it's very similar to what the book Shape Up (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.
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?
> 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.
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
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
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.
Every engineer thinks politics don’t matter until they end up at a company/org where politics are all that matters…
Politics definitely matter. I just think Sean makes a bigger deal out of it than necessary.
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.
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.
> Planning is inaccurate, frustrating, and sadly necessary.
Right.
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
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.
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.
Extremely relatable. We seem to have a similar problem in product design.
> 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.
blog title police, always present https://news.ycombinator.com/item?id=46256631
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.
Bravo! Not a single mention of LLMs changing the calculus.
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.
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.
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.
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.
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.
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.
Agree. I feel people with less clarity about priorities of features waste too much time by asking accurate estimates
Software time estimations are always going to be bad, you might as well ask an LLM.
U5jjtkfjjxhdu88939994999992889398 929 88889993uej72737377787383883998
> 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.
> 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/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.
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 (2013)
original: https://web.archive.org/web/20170603123809/http://www.tuicoo...
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.
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.
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.
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.
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")
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.
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.
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.
I don’t disagree. But have you tried estimation using Claude or Cursor? If not, give it a try.