- 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.
So far the only metric I've seen that works is KTLO fraction, where lower is better, because that means with the rest of the time you can be adding value, and that value is socially determinable by asking your peers and users. KTLO fraction can't be gamed because your peer managers will call you out on it if you try to cook it. To drive KTLO fraction down you also have to address tech debt that cause high KTLO fractions, and addressing that tech debt enables value-add because between spending less time on KTLO and having a cleaner architecture/design you enable the addition of valuable features.
Is it going to take more than two 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.
On the high end, could it take more than 2 years? 1 year? 6 months? Stop when you are 80% confident that it won't take longer than some period.
So your estimate might be between two weeks and six months. Is that an acceptable estimate for the "buyer"? If not, is it worth expending effort to narrow the estimate?
I prefer it over estimating which feels more like asking the length of a piece of string.
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.
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.
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.
In my experience this is a really hard conversation and you have to build a lot of relationship/trust (aka politics) within the company to be direct about it. But it saves you and your team from burnout, because it eliminates the expectation of “if you fall behind you’ll work 80hrs/wk until the timeline is caught up” which is what I’ve seen happen too many times.
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.
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.
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.
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.
And yes, when there's a task that one person happens to know most, people will often defer to them. But that in itself is educational, as the experienced dev explains why the given task is easy/hard. And every task is different, so the person you're deferring to will be different, and you still often get the two or three people who know the task best disagreeing until they hash it out, etc. And very often it's another person who can point out "well it would be that easy except three sprints ago I did x and so you'll now need to do y...". And of course plenty of tasks really are brand-new so everyone's figuring it out together.
If you're really not having actual discussions around complexity in planning poker, then the facilitator/lead/manager might be doing it wrong. You do have to create an environment where people are expected to speak up and disagree, to demonstrate that this is welcomed and expected and rewarded, and not just some kind of checkbox exercise where the most senior dev gives their estimation and everyone agrees. This is also a reason why it's literally done with cards where everyone is forced to put their number on the table at the same time, so that you don't wind up with some senior person always going first and then everyone else just nodding and agreeing.
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.
Literally none of that is anything I've ever encountered on any team.
They're not specific to a person, they're to a team.
They have nothing to do with the smallest task ever faced.
They are obviously for summing and are obviously units.
They effectively get translated into time in the sense that the team has a history of delivering an average of n points per e.g. 2 weeks.
I’d like to disagree on that one. A single story point shouldn’t be translated to time, but should reflect the relative complexity between tasks (ie. a 7 is harder than a 3 and so on).
You could assign relative complexity based on a number of things:
- number of integrations to other systems, - is the area well known to the team, - is the code well tested, - is CI/CD set up, - do we need a lot of alignment or can we just get started, - etc.
So you’re not estimating time, but complexity or hardness.
Then, supposing you have a stable team, you can go back six months and find out “we do on average 90 points per month” or similar
I agree it's best if working in isolation, but if you need to synchronise then estimations make sense.
If you need 3 months to implement something, and another team 1 week, and both need to be ready at the same time; then if you actually know those estimations the second team can wait until then and do something immediately useful in between.
In the end we have stable developer velocity metric and a really close estimate for each new version.
As the team grows and shrinks, the number of points delivered per sprint are expected to similarly rise and fall. A new person joining will likely take time to ramp up the number of points they're contributing.
Great that it works for you.
Does it take time? Sure. But what's the alternative? Not doing it is even worse, because you wind up with these endless never-finished "features" that turn out to be 20x harder than anyone thought, that engineers have sunk months and months and months into...
The truth is on most teams one or two people who are closest to the task have enough context to estimate, and probably only after they spent some time starting or prototyping the task.
Those people can give a reasonable estimate, in time not some strange point system.
Sometimes the estimate is wrong and that’s ok.
It’s fine to have a meeting catching everyone else up on the context but those pther people still likely don’t have enough to give an accurate estimate and shouldn’t be involved in estimation
> 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?
Estimating in points that are basically a Fibonacci sequence keep estimation precision limited and avoids implying false guarantees. Yes, in the end the chosen stories are based on summing to a number of points that is roughly equivalent to what the team has achieved per-sprint in the recent past, so in that sense it is ultimately estimating days in the end. But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep both team expectations and management expectations more reasonable.
tl;dr: Psychology.
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.
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.
The PMI project management methodology even pre-scribes this (after the project is over, to reflect, and then to gather collected learnings and objective stats so as to help better estimation of future projects), but the problem is many engineers see project management a administrative burden rather than as a tool, and they have a tinkerer's mind-set rather than a scientist's mind-set.
Good project management practice is also not to use point estimates but intervals: something is going to take "betweek [i;j] person days". PERT-estimates are even three-point estimates of work (best case, expected case, worst case), so you model the uncertainty explicitly rather than by some alchemist formula ("double and add 20%").
Incidentally, I found out empirically that the best technical people tend to be the worst at estimating their own time needed to complete a task. That's because the best are often also a bit over-confident, perhaps. Letting each team member estimate a task and adding a 20% correction for unforseen issues has worked well to make my projects be delivered on time.
Tip: Push back if management tells you how long you have; either explain to them what you can give to them in the time they dictate or reject their task order and say you will come back when you have calculated how long the project takes, which can only be rationally determined once the scope is clear(er).
Check out/google: PMI PMP methodology and also PMBOK (project management body of knowledge) > "Organizational Process Assets" (OPAs) > "Lessons Learned Repository"
How long does it take to learn to juggle 3 items? 4? 5?
How much time will it take you to measure the coast of England between Brighton and Seaton?
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?
- manager’s refusal to acknowledge any uncertainty
- unclear requirements/expectations/system under change
- changing requirements
- negative consequence (“penalties”) for inaccurate estimate
I’m now also in the environment where I give ranges, but not everybody is.
It'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.
Actual work that week gives employee 3 hours of non-meeting time, each daily meeting adds 0.5 hours of high-urgency administrative work. Friday’s we have a mandatory all-hands town halls…
Repeat that cycle for every customer facing issue, every demo facing issue, and internal political issue and you quickly drive deep frustrations and back talking.
I think there’s a fundamental truth: no one in their right minds, not even motivated engineers, actually hears anything but calendar when getting “days” estimates. It’s a terrible misrepresentation almost all the time, and engineers do a disservice when they yield to pressure to deliver them outside the broader planning process.
Project schedules should be the only place that time commitments come from, since they’re informed with necessary resource availability.
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. :-)
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."
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.
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.
It's not binary, it's a continuum.
With experience, it's possible to identify whether the new project or set of tasks is very similar to work done previously (possibly many times) or if it has substantial new territory with many unknowns.
The more similarity to past work, the higher the chance that reasonably accurate estimates can be created. More tasks in new territory increases unknowns and decreases estimate accuracy. Some people work in areas where new projects frequently are similar to previous projects, some people work in areas where that is not the case. I've worked in both.
Paying close attention to the patterns over the years and decades helps to improve the mapping of situation to estimate.
If you can't make firm delivery commitments to customers then they'll find someone who can. Losing customers, or not signing them in the first place, is the most harmful thing to everyone in the organization. Some engineers are oddly reluctant to accept that reality.
1. Guess the order of magnitude of the task (hours vs days/months/years)
2. Add known planning overhead that is almost order of magnitude more.
Example: if we guess that task will take 30min, but actually it took 60min - that’s 100% error (30min error/30min estimate).
But if the methodology is used correctly, and we spend 2h in a planning meeting, same estimate and same actual completion time results in only 20% error, because we increased known and reliable part of the estimate (30min error / 2h30min estimate)
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.
Former Test Engineer here. It was always fun when everyone else’s deadline slipped but ours stayed the same. Had to still ship on the same date even if I didn’t have silicon until much later than originally planned.
I think you were estimating time to build things that were out of R&D and you had specifications that were actual specifications you were building up to.
In SaaS my experience is: someone makes up an idea not having any clue how existing software is working or is laid out, has no specifications beside vague not organized bunch of sentences. Software development team basically starts R&D to find out specifications and what is possible - but is expected to deliver final product.
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.
Alternatively treat it like a bet and accept it may not pay off, just like any other business where uncertainty is the norm (movies, books, music).
Sure, but even accurate estimates are only accurate as long as the assumptions hold.
Market conditions change, emergency requests happen, people leave, vendor promises turn out to be less than accurate.
And most estimates for non-routine work involve some amount of risk (R&D risk, customer risk, etc.).
So pounding the table and insisting on ACCURATE ESTIMATES without a realistic backup plan isn’t good business, it’s just pushing the blame onto the SWE team when (not if) something goes south.
I *HATE* estimating roadmaps, because it feels unfair. I'm happy to estimate a sprint.
I abandoned the plans from the previous PM and discussed the job with the developer who ballpark estimated that the work would take 2 months. After a quick analysis I adjusted this to 14 weeks.
But the account manager thought this sounded too long and insisted that we plug everything in to a Gantt chart, define the shit out of everything, map the dependencies, etc, which showed that the development would only take 6 weeks.
The project ended up taking 14 weeks.
As far as estimates go, I've also struggled with the industries cult(ural) rituals. I tried to put forward a Gaussian based approach that took into account not only the estimate of time, but the expected uncertainty, which is still probably off the mark, but at least attempts to measure some of the variance. But again, the politics and the rigidity of the clergy that has built around software development blocked it.
On the bright side, all this has helped me in my own development and when I think about software development and estimating projects. I know that outcomes become more chaotic as the number of pieces and steps compound in a project (i.e. the projects normal curve widens). You may not even get the project at all as defined at the outset, so my normals approach is still not quite the right tool.
I think this kind of thinking can be helpful when working solo or in a small group who are exposed to market forces. But for solo and small groups, the challenge isn't so much about the estimates, it's about how you're going to fight a battalion of mercenaries hired by big VC money and Big Tech. They can often afford to be inefficient, dump in the market, because their strategy is built around market control. These aren't practices small players can afford, so you need to get creative, and try to avoid these market participant kill boxes. And this is why, coming back to my earlier point, that often times, inefficient practices and politics plays a big role. Their trying to marshal a large number of troops into position and can afford to lose a few battles in order to win the war. The big money plays by a different set of rules, so don't worry if their doing it wrong. Just recognize your in the army soldier!
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.
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?"
Whereas with software most of what was done previously is now an import statement so up to 80-100% of the project is the novel stuff. Skilled leaders/teams know to direct upfront effort toward exploring the least understood parts of the plan to help reduce down-stream risk but to really benefit from that instinct the project plan has to regularly incorporating its findings.
Estimating in software is very hard, but that's not a good reason to give up on getting better at it
But you're pretty spot on, as 'professionally acceptable' indeed means politically acceptable most of the time. Being honest and admitting one's limit is often unacceptable.
[0]: https://www.strategy-business.com/article/Why-do-large-proje...
Saying "I don't know" is arguably more honest, even if it's not useful for budgets or planning.
Estimations in government contracts are as ridiculous as in software. They just pretend to be able to estimate when things will be done, when, in fact, the contractors are as clueless.
Not being able to say "it is impossible to estimate", does not mean your estimate will be correct. That estimation is usually a lie.
There is a bridge in my town that is finally nearing completion, hopefully, this year. It was estimated to be completed 2 years ago.
This changes when it’s a project that has fewer unknowns, where they’ve built the same thing several times before. The same is true in software.
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.
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.
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.
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
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.
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.
I’ve seen enough instances of work being done for a specific customer that doesn’t then result in the customer signing up (or - once they see they can postpone signing the big contract by continuing to ask for “just one more crucial feature”, they continue to do so) to ever fall for this again.
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.
1. Think about what product/system you want built.
2. Think about how much you're willing to invest to get it (time and money).
3. Cap your time and money spend based on (2).
4. Let the team start building and demo progress regularly to get a sense of whether they'll actually be able to deliver a good enough version of (1) within time/budget.
If it's not going well, kill the project (there needs to be some provision in the contract/agreement/etc. for this). If it's going well, keep it going.
But when you get paid less than half that it doesn’t feel like a problem to worry about. At 300/day of take-home pay, one more day here or there really isn’t going to make a difference.
I've made your argument before, but realistically, much of the word revolves around timelines and it's unreasonable to expect otherwise.
When will you recover from your injury so you can play the world cup?
When will this product arrive that I need for my child's birthday?
When will my car be repaired, that I need for a trip?
How soon before our competitors can we deliver this feature?
"It'll be done when it's done" is very unsatisfying in a lot or situations, if not downright unacceptable.
But the problem is, the sales world has its own reality. The reality there is that "we don't know when" really is unacceptable, and "unacceptable" takes the form of lost sales and lost money.
So we have these two realities that do not fit well together. How do we make them fit? In almost every company I've been in, the answer is, badly.
The only way estimates can be real is if the company has done enough things that are like the work in question. Then you can make realistic (rough) estimates of unknown work. But even then, if you assign work that we know how to do to a team that doesn't know how to do it, your estimates are bogus.
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.
"I'd like to have my roof reshingled, but with glass tiles and it should be in the basement, and once you are half way I'll change my mind on everything and btw, I'm replacing your crew every three days".
I guess a fair analogy would be if the home owner just said “Make my home great and easy to use” by Thanksgiving without too many details, and between now ans thanksgiving refines this vision continuously, like literally changing the color choice half way or after fully painting a wall… then its really hard to commit.
If a home owner has a very specific list of things with no on the job adjustments, then usually you can estimate(most home contract work)
All software requests are somewhere in between former and latter, most often leaning towards the former scenario.
If it’s something where they have fewer unknowns and more control and lots of experience building the same thing, then I would expect an estimate: building a deck, re-roofing a house, etc
When you ask for a firm estimate, you are basically asking to be lied to, and the contractor happily complies by telling you a lie.
Personally I consider it more important to constantly narrow down any uncertainties over time, than having an initial estimate that holds. The closer it gets to any deadline, the less uncertainty I want (need) to have because the less options remain to react to changes.
And frankly, this usually not only applies to estimates but also to things that these estimates rely upon. The longer the timeline, the more room for circumstances and requirements to change.
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.
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.
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).
> 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.
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 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.
The example I quoted said hours, not days. But even taking your claim of days as estimable, I have seen much better.
An example of weeks-long projects I regularly estimate accurately would be things like “in our Django monolith, add this new field/model, and update the state machine with these new transitions, and update the API, and surface the feature in the UI, including standard e2es and UT coverage”. With a team of 10-15 we regularly hit days-to-weeks estimates with in the ballpark of 90% accuracy. (Ie 1-in-10 slips)
An example of year-long projects I have seen waterfall’d successfully are IP protocol implementations where the RFC is clear, base frameworks exist, and the org has engineers with decades of individual experience implementing protocols in the same framework. IOW you have senior-staff or principal engineers on the project.
> the point of the article seems to be in a different direction: it _doesn't really matter_ that you have a good time estimate
I think the idea that you always start with time and define the work is also myopic. In some dysfunctional orgs I’m sure this is true, but it’s not the whole picture.
For the fully-generalized principle at play here, I’m a big believer in the “cost / time / scope” tradeoff triangle. In other words, pick two as your free parameters, and the third is then determined. Sometimes time is the output of a calculation, and resource/scope are the input. Sometimes time can be the input and scope the output. It depends.
But the article opens by claiming it’s impossible to estimate time, given a fixed scope and cost(resource) input, which is simply false/over-generalizing.
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.
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"?
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.
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!
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.
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.
The story points are that data point in the past used to indicate the future.
Timelines can be estimated approximately.
I’ve never had a construction project finish exactly on time, but that doesn’t mean estimates are unwise.
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.
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 :)
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.
Avoiding this degrading game is half the reason I preferred contracting.
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.
Is that a problem? Well, how good are they now?
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.
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.
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.
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.
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.
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.
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.
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.
- “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.
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...
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.
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.
Our team would simply gather around, go through the tasks that were agreed with the business and on count of three, each of us simply raise a thumbs up if we thought we could ship it within two days - otherwise thumbs down.
It generally implied we collectively thought a task would take more than two days to ship, it may require breaking down, otherwise it’s good to go.
This is exactly how all good art is done. There's an old French saying, une toile exige un mur.
In case anyone else is wondering: The French phrase can be translated literally as "a canvas requires a wall", or less closely, "its boundaries are important for every picture".
(I am not a native French speaker and just piecing this together with a dictionary.)
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?
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.
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.
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.
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
As for reading… https://thecodelesscode.com/case/215?topic=documentation
Yes, he was telling me this tongue in cheek, but in my actual experience this has been eerily accurate.
Planning is inaccurate, frustrating, and sadly necessary.
Right.
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 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.
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.
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.
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.
> 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.
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")
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.
First impressions with this is they give really long estimates.
Also, due to coding agents, you can have them completely implement several different approaches and find a lot of unknown unknowns up front.
I was building a mobile app and couldn’t figure out whether I wanted to do two native apps or one RN/Expo app. I had two different agents do each one fully vibe coded and then tell me all the issues they hit (specific to my app, not general differences). Helped a ton.
I 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.
