- 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.
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.
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)
^ 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.
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.
> 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.
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.
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.
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.
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.
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.
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?
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"
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.
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.
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.
> 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. :-)
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.
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.
> 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.
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, 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 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
>>>> 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.
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.
> "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.
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
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.
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.
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.
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.
My empirical findings (30 year time frame, dozens of projects, a few larger, some small many small-to-medium, median perhaps 18 calendar months with around four people on the core team):
1. Good estimates are possible.
- use intervals, not single numbers; intevals are asymmetric (worst case is far out compared to best and expected cases);
- calculate using PERT estimates;
- estimate by combining top-down and bottom-up estimates; when both agree, trust the estimate; otherwise, refine/revise the plan;
- let the assignee estimate their own work, but the manager correct it (because of (2));
2. Better engineers tend to underestimate their own time more than average performers.
If management tells you how long you got, look surprised and ask them how they can know that; then tell them you will now working on calculating how long it will really take. If their "gut instinct" and your professional estimate diverge, show them your plan, talk them through it, and ask them which part you should leave out (if you keep the time fixed, perhaps you can shrink the scope).
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.
> 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.
> (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.
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 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.
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.
This sort of stuff has parallels outside software - the book “how big things get done” is amazing, and one interesting thing it implies is that solar installations tend to go the best because they’re modular and lessons learned can be applied to the next phase of a project.
Whereas the worst overruns are nuclear power plants; which are either switched on and working, or completely useless and taking up space!
So my takeaways were: try to make estimates modular and work out how to carry learnings as your project goes on, and you’ll have an easier time hitting your estimates - and probably get a great reputation for delivering!
> 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 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 think we should not compare apples to oranges here.
A construction project is not an IT project.
In a construction project, many things can be easily estimated. I know how much concrete, steel, and other materials I need. I can estimate how long it will take to get them delivered. I can estimate how long it will take to build this one specific part.
Sure, there are unknowns, but they are usually (not always) due to human error, price changes, unreliable partners, or weather conditions. That's nothing you can predict upfront (maybe except weather, to a degree), but those factors usually blow up construction projects. Not the fact that it suddenly took you three times as long to build this wall because you had to do it completely differently than before, and couldn't have known that.
An IT project is totally different. As the article states (and I agree), most of the work happens in terra incognito. I cannot reliably estimate what I don't know.
Sure, there are situations where I can reliably estimate my work, but more often than not, I can't. Especially when the estimates go into weeks or months. There is no way to predict anything reliably for such a period of time, IMO.
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 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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?
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 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.
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?
> 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.
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.
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.
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 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.
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
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.
> 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.
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.
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.
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.
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")
> 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.
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.
jawns|1 month ago
- 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.
tfrancisl|1 month ago
unknown|1 month ago
[deleted]
xn|1 month ago
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.
dchuk|1 month ago
n4r9|1 month ago
scott_w|1 month ago
I prefer it over estimating which feels more like asking the length of a piece of string.
swat535|1 month ago
HEmanZ|1 month ago
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)
wesselbindt|1 month ago
^ 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.
cryptonector|1 month ago
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.
jkubicek|1 month ago
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.
jimbokun|1 month ago
firefoxd|1 month ago
It took 6 months. Why? Well it was a legacy app, and we learned that passwords were case insensitive because the customer sent a video of him entering his password that failed. On the video, we could see a sticky note on his monitor with the password written on it.
When we made all the necessary changes, the docker file failed to build. SRE accidentally deleted the deprecated image with PHP that had reached EOL.
Estimating is always fun.
shoo|1 month ago
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.
cryptonector|1 month ago
crazygringo|1 month ago
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.
spike021|1 month ago
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.
Fire-Dragon-DoL|1 month ago
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.
mgfist|1 month ago
t00|1 month ago
In the end we have stable developer velocity metric and a really close estimate for each new version.
lucketone|1 month ago
alexmonami|1 month ago
samastur|1 month ago
Great that it works for you.
csours|1 month ago
> 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?
n4r9|1 month ago
moribvndvs|1 month ago
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.
wreath|1 month ago
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.
jll29|1 month ago
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"
pan69|1 month ago
flyingcircus3|1 month ago
mmcnl|1 month ago
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?
lucketone|1 month ago
- manager’s refusal to acknowledge any uncertainty
- unclear requirements/expectations/system under change
- changing requirements
- negative consequence (“penalties”) for inaccurate estimate
I’m now also in the environment where I give ranges, but not everybody is.
marcosdumay|1 month ago
It's almost never fine, though. When it's fine, people aren't pressured into giving estimates.
> It likely is wrong, that's fine
The most you can do is say it. Communication demands effort from all involved parties, and way too many people in a position to demand estimates just refuse to put any effort into it.
ptmcc|1 month ago
hahn-kev|1 month ago
aleph_minus_one|1 month ago
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. :-)
jmpeax|1 month ago
This is the perfect approach, given that estimates are top down and work to fill the estimate is bottom up.
"When I estimate, I extract the range my manager is looking for, and only then do I go through the code and figure out what can be done in that time."
inadequatespace|1 month ago
notjustanymike|1 month ago
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.
davnicwil|1 month ago
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.
doix|1 month ago
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.
bluGill|1 month ago
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.
CuriouslyC|1 month ago
I *HATE* estimating roadmaps, because it feels unfair. I'm happy to estimate a sprint.
nine_k|1 month ago
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.
lubujackson|1 month ago
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?"
chrisfosterelli|1 month ago
Estimating in software is very hard, but that's not a good reason to give up on getting better at it
analog31|1 month ago
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.
subprotocol|1 month ago
nradov|1 month ago
kubb|1 month ago
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.
dorn64|1 month ago
9rx|1 month ago
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.
mgfist|1 month ago
boltzmann-brain|1 month ago
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
steele|1 month ago
rawgabbit|1 month ago
dfunckt|1 month ago
bgribble|1 month ago
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.
pocketarc|1 month ago
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.
xyzzy123|1 month ago
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_af|1 month ago
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.
iamflimflam1|1 month ago
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.
genghisjahn|1 month ago
combatentropy|1 month ago
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.
cpeterso|1 month ago
https://basecamp.com/shapeup/4.5-appendix-06
heyitsdaad|1 month ago
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.
jll29|27 days ago
1. Good estimates are possible.
- use intervals, not single numbers; intevals are asymmetric (worst case is far out compared to best and expected cases);
- calculate using PERT estimates;
- estimate by combining top-down and bottom-up estimates; when both agree, trust the estimate; otherwise, refine/revise the plan;
- let the assignee estimate their own work, but the manager correct it (because of (2));
2. Better engineers tend to underestimate their own time more than average performers.
If management tells you how long you got, look surprised and ask them how they can know that; then tell them you will now working on calculating how long it will really take. If their "gut instinct" and your professional estimate diverge, show them your plan, talk them through it, and ask them which part you should leave out (if you keep the time fixed, perhaps you can shrink the scope).
dasil003|1 month ago
> estimates are not by or for engineering teams.
It's surprising the nuance and variety of how management decisions are made in different orgs, a lot depends on personalities, power dynamics and business conditions that the average engineer has almost no exposure to.
When you're asked for an estimate, you've got to understand who's asking and why. It got to the point in an org I worked for once that the VP had to explicitly put a moratorium on engineers giving estimates because those estimates were being taken by non-technical stakeholders of various stripes and put into decks where they were remixed and rehashed and used as fodder for resourcing tradeoff discussions at the VP and executive level in such a way as to be completely nonsensical and useless. Of course these tradeoff discussions were important, but the way to have them was not to go to some hapless engineer, pull an overly precise estimate based on a bunch of tacit assumptions that would never bear out in reality, and then hoist that information up 4 levels of management to be shown to leadership with a completely different set of assumptions and context. Garbage in, garbage out.
These days I think of engineering level of effort as something that is encapsulated as primarily an internal discussion for engineering. Outwardly the discussion should primarily be about scope and deadlines. Of course deadlines have their own pitfalls and nuance, but there is no better reality check for every stakeholder—a deadline is an unambiguous constraint that is hard to misinterpret. Sometimes engineers complain about arbitrary deadlines, and there are legitimate complaints if they are passed down without any due diligence or at least a credible gut check from competent folks, but on balance I think a deadline helps engineering more than it hurts as it allows us to demand product decisions, designs, and other dependencies land in a timely fashion. It also prevents over-engineering and second system syndrome, which is just as dangerous a form of scope creep as anything product managers cook up when the time horizon is long and there is no sense of urgency to ship.
mmis1000|1 month ago
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.
shoknawe|1 month ago
heikkilevanto|1 month ago
theptip|1 month ago
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.)
etamponi|1 month ago
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.
cryptonector|1 month ago
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.
funrep|1 month ago
zmj|1 month ago
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"?
nickevante|1 month ago
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.
Glyptodon|1 month ago
coffeebeqn|1 month ago
ericyd|1 month ago
cadamsdotcom|1 month ago
Whereas the worst overruns are nuclear power plants; which are either switched on and working, or completely useless and taking up space!
So my takeaways were: try to make estimates modular and work out how to carry learnings as your project goes on, and you’ll have an easier time hitting your estimates - and probably get a great reputation for delivering!
bitwize|1 month ago
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.
impute|1 month ago
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.
jweatherby|1 month ago
The story points are that data point in the past used to indicate the future.
bmitch3020|1 month ago
paulddraper|1 month ago
Timelines can be estimated approximately.
I’ve never had a construction project finish exactly on time, but that doesn’t mean estimates are unwise.
xelah|23 days ago
A construction project is not an IT project.
In a construction project, many things can be easily estimated. I know how much concrete, steel, and other materials I need. I can estimate how long it will take to get them delivered. I can estimate how long it will take to build this one specific part. Sure, there are unknowns, but they are usually (not always) due to human error, price changes, unreliable partners, or weather conditions. That's nothing you can predict upfront (maybe except weather, to a degree), but those factors usually blow up construction projects. Not the fact that it suddenly took you three times as long to build this wall because you had to do it completely differently than before, and couldn't have known that.
An IT project is totally different. As the article states (and I agree), most of the work happens in terra incognito. I cannot reliably estimate what I don't know. Sure, there are situations where I can reliably estimate my work, but more often than not, I can't. Especially when the estimates go into weeks or months. There is no way to predict anything reliably for such a period of time, IMO.
etamponi|1 month ago
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 :)
wiether|1 month ago
Think of managers as kids in a toy/candy shop with a $X bill in hand.
If items don't have price, how are they suppose to choose? They want everything, but they are limited by their budget.
fogzen|1 month ago
Avoiding this degrading game is half the reason I preferred contracting.
mattacular|1 month ago
I always tell my teams just skip the middlemen and think of estimates as time from the jump. It's just easier that way. As soon as an estimate leaves an engineer's mouth, it is eagerly translated into time by everyone else at the business. That is all anyone else cares about. Better said - that is all anyone else can understand. We humans all have a shared and unambiguous frame of reference for what 1 hour is, or what 1 day is. That isn't true of any other unit of software estimation. It doesn't matter that what one engineer can accomplish in 1 hour or 1 day is different from the next. The same is true no matter what you're measuring in. You can still use buffers with time. If you insist on not thinking of your labor in terms of hours spent, you can map time ranges to eg. points along the Fibonacci sequence. That is still a useful way to estimate because it is certainly true as software complexity goes up, the time spent on it will be growing non-linearly.
tuna74|1 month ago
cube2222|1 month ago
I find that the best approach to solving that is taking a “tracer-bullet” approach. You make an initial end-to-end PoC that explores all the tricky bits of your project.
Making estimates then becomes quite a bit more tractable (though still has its limits and uncertainty, of course). Conversations about where to cut scope will also be easier.
mariusor|1 month ago
unknown|1 month ago
[deleted]
hyperman1|1 month ago
If you get 10 tasks of seemingly equal duration, 9 will go well and 1 will hit a reef of unexpected troubles and take forever.
So the practice of doubling is not that stupid. It leaves time in the first 9 to deal with the unexpected disaster.
boltzmann-brain|1 month ago
saghm|1 month ago
I've worked on multiple teams at completely different companies years apart that had the same weird rules around "story points" for JIRA: Fibbonacci numbers only, but also anything higher than 5 needs to be broken into subtasks. In practice, this just means, 1-5, except not 4. I have never been able to figure out why anyone thought this actually made any practical sense, or whether this apparently is either common enough to have been picked up by both teams or if I managed to somehow encounter two parallel instances of these rules developing organically.
avandekleut|1 month ago
rajman187|1 month ago
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.
fogzen|1 month ago
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.
andrewingram|1 month ago
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.
tossandthrow|1 month ago
At my team we think in terms of deliverables and commitments: "I can commit til deliver this by that date under these circumstances".
This mitigated the diverse nature Og thinking.
somewhereoutth|1 month ago
Choose 2. For example a large feature set can be made quickly, but it will be of poor quality.
Note that cost is somewhat orthogonal, throwing money at a problem does not necessarily improve the tradeoff, indeed sometimes it can make things worse.
jayanmn|1 month ago
cainxinth|1 month ago
- “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.
j45|1 month ago
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...
danabrams|1 month ago
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.
wbkang|1 month ago
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.
hosainnet|1 month ago
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.
publicdebates|1 month ago
This is exactly how all good art is done. There's an old French saying, une toile exige un mur.
dxdm|1 month ago
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.)
the_arun|1 month ago
nazgul17|1 month ago
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?
RickJWagner|1 month ago
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.
zabzonk|1 month ago
dcminter|1 month ago
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.
Jegber|1 month ago
makeset|1 month ago
oakashes|1 month ago
andychiare|1 month ago
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.
aloukissas|1 month ago
skeptrune|1 month ago
HEmanZ|1 month ago
tiberriver256|1 month ago
Software Estimation: Demystifying the black art by Steve McConnell should be 1st year reading in any software development major in college...
We've largely "solved" this problem in the industry we just have a problem of getting people to read and read the right things
tree888|1 month ago
As for reading… https://thecodelesscode.com/case/215?topic=documentation
khendron|1 month ago
Yes, he was telling me this tongue in cheek, but in my actual experience this has been eerily accurate.
__coder__|1 month ago
telliott1984|1 month ago
Planning is inaccurate, frustrating, and sadly necessary.
lucketone|1 month ago
Right.
zeodtr|1 month ago
fallinditch|1 month ago
toonalfrink|1 month ago
Huston1992|1 month ago
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.
cfhz|1 month ago
croisillon|1 month ago
danjl|1 month ago
badgersnake|1 month ago
cryptonector|1 month ago
> 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.
tuna74|1 month ago
The only reasonable way to estimate something is in work hours. Everything else is severely misguided.
Also, if you don't follow up any estimate is meaningless.
Falimonda|1 month ago
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.
wellpast|1 month ago
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.
amelius|1 month ago
o92992930999599|1 month ago
publicdebates|1 month ago
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.
cauch|1 month ago
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")
lifetimerubyist|1 month ago
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.
maximgeorge|1 month ago
[deleted]
ripped_britches|1 month ago
First impressions with this is they give really long estimates.
Also, due to coding agents, you can have them completely implement several different approaches and find a lot of unknown unknowns up front.
I was building a mobile app and couldn’t figure out whether I wanted to do two native apps or one RN/Expo app. I had two different agents do each one fully vibe coded and then tell me all the issues they hit (specific to my app, not general differences). Helped a ton.
cvwright|1 month ago
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.