How I Estimate Work as a Staff Software Engineer

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.

Here's my (somewhat tongue-in-cheek) rubric:

- If it's an internal project (like migrating from one vendor to another, with no user impact) then it takes as long as I can convince my boss it is reasonable to take.

- If it's a project with user impact (like adding a new feature) then it takes as long as the estimated ROI remains positive.

- If it's a project that requires coordination with external parties (like a client or a partner), then the sales team gets to pick the delivery date, and the engineering team gets to lie about what constitutes an MVP to fit that date.

> 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.

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.

> 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.)

Compare this with how customer requests end up in products in startups:

Step 1: Customer <-> Sales/Product (i.e., CEO). Step 2: Product <-> Direct to Engineering (i.e., CTO)

The latency between Step1 and Step2 is 10 minutes. CEO leaves the meeting takes a piss and calls the CTO.

- Simple features take a day: CTO to actual implementation latency depends on how hands on the CTO is. In good startups CTO is the coder. Most features will make its way into the product in days.

- Complex Features take a few days: This is a tug of war between CTO - CEO and indirectly the customer. CTO will push back and try to hit a balance with CEO while the CEO works with the customer to find out what is acceptable. Again latency is measured by days.

Big companies cannot do this and will stifle your growth as an engineer. Get out there and challenge yourselves.

This is 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?

The most important part of the article is ”I gather as much political context as possible before I even look at the code.”

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.

Is it going to take more than two hours?

Is it going to take more than two days?

Is it going to take more than two weeks?

Is it going to take more than two months?

Is it going to take more than two years?

If you can answer these questions, you can estimate using a confidence interval.

If the estimate is too wide, break it down into smaller chunks, and re-estimate.

If you can't break it down further, decide whether it's worth spending time to gather information needed to narrow the estimate or break it down. If not, scrap the project.

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.

The old guys in the 80's and 90's would say kiddingly multiply your original estimate time pi (3.14).

Article resonates with me. This time around, we asked cursor to estimate giving PRD & codebase. It gave very detailed estimate. Currently in the process of getting it down to what leadership wants (as in the article). AI estimates much better & faster than us. We are bringing it down much faster than AI. Sometimes changing the PRD or prioritizing the flows & cutting down scope of MVP. Honestly AI is a great tool for estimation.

I 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.

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.

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.

IMHO time estimation for software development is a legacy way of thinking. A result of industrial processes.

At my team we think in terms of deliverables and commitments: "I can commit til deliver this by that date under these circumstances".

This mitigated the diverse nature Og thinking.

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.

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.

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.

Software time estimations are always going to be bad, you might as well ask an LLM.

Slightly OT, but anyway.

The only reasonable way to estimate something is in work hours. Everything else is severely misguided.

Also, if you don't follow up any estimate is meaningless.

> I ask myself "which approaches could be done in one week?".

This is exactly how all good art is done. There's an old French saying, une toile exige un mur.

Features : Quality : Timeline

Choose 2. For example a large feature set can be made quickly, but it will be of poor quality.

Note that cost is somewhat orthogonal, throwing money at a problem does not necessarily improve the tradeoff, indeed sometimes it can make things worse.

Bravo! Not a single mention of LLMs changing the calculus.

You wouldn’t put up with this drama from any other professional, I don’t know why I’d take it from a SWE.

Timelines can be estimated approximately.

I’ve never had a construction project finish exactly on time, but that doesn’t mean estimates are unwise.

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.

[dead]

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.