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

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.

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.

The more I work in engineering, the more I agree with pieces like this which suggest that a large part of the job is managing politics in your workspace.

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

Estimation is an art, not a science. It's always going to be a judgement call by the engineers tasked with giving them to management. Taking all of the factors from this article and beyond can and should go into making that judgement call.

I always tell my teams just skip the middlemen and think of estimates as time from the jump. It's just easier that way. As soon as an estimate leaves an engineer's mouth, it is eagerly translated into time by everyone else at the business. That is all anyone else cares about. Better said - that is all anyone else can understand. We humans all have a shared and unambiguous frame of reference for what 1 hour is, or what 1 day is. That isn't true of any other unit of software estimation. It doesn't matter that what one engineer can accomplish in 1 hour or 1 day is different from the next. The same is true no matter what you're measuring in. You can still use buffers with time. If you insist on not thinking of your labor in terms of hours spent, you can map time ranges to eg. points along the Fibonacci sequence. That is still a useful way to estimate because it is certainly true as software complexity goes up, the time spent on it will be growing non-linearly.

I think the main problem in estimating projects is unknown unknowns.

I find that the best approach to solving that is taking a “tracer-bullet” approach. You make an initial end-to-end PoC that explores all the tricky bits of your project.

Making estimates then becomes quite a bit more tractable (though still has its limits and uncertainty, of course). Conversations about where to cut scope will also be easier.

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

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well.

They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engineering team for not delivering to their estimate.

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

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.

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

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.

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.

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.

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

The article resonates with me, but I think it misses some nuance when estimating in aggregate. My career has been primarily product engineering, let’s call it the top 2/3rds of the stack. I’ve been lead on multiple projects with the rough shape “we have this [conference/marketing event/partnership] on [date] and we want to ship [new feature].”

My job is to present an opinionated menu of functionality I believe we can have in place by that time. It should also include the potential scope cuts if things go wrong.

I agree that unknowns dominate the individual tasks, but when you bundle enough together the positive/negative surprises tend to balance out.

Without an idea of at least relative Eng costs of different features, it is impossible for leadership to correctly prioritize what we build and what we cut.

I cannot tell you with certainty that a given task will take N days, but I should be reasonably confident communicating what my team can accomplish in a quarter.

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

Timelines can be estimated approximately.

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.