Bravo! Not a single mention of LLMs changing the calculus.
How I estimate work
11–20 of 326 posts
Re: How I estimate work
#12One 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.
Re: How I estimate work
#13One 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 engin…
Anyone from a sales roll care to speak to this?
Re: How I estimate work
#14I think the main problem in estimating projects is unknown unknowns. I find that the best approach to solving that is taking a “tracer-bullet” approach. You make an initial end-to-end PoC that explores all the tricky bits of your project. Making estimates then becomes quite a bit more tractable (though still has its limits and uncertainty, of course). Conversations about where to cut scope will also be easier.
But how long it'll take you to make that PoC? Any idea? :P
Re: How I estimate work
#15The old guys in the 80's and 90's would say kiddingly multiply your original estimate time pi (3.14).
Several times, to be sure
Re: How I estimate work
#16When 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.
I used to (half) jokingly tell people to go to the next human unit.
A few days? At least a week.
A week? A month.
A month? A year.
A year? Uh... decade or never...
It's wildly pessimistic but not as inaccurate as I'd like.
Re: How I estimate work
#17[dead]
Re: How I estimate work
#18One 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 engin…
I'm a dev, not a salesperson, but let's be realistic. A company tells you "yeah we're interested in signing at $1M/yr, but we really need this feature, when will you have it by?", to which saying "eh we don't know - it'll be done when it's done" will lead to the company saying "ok well reach out when you have it, we can talk again then" (or just "eh ok then not a good fit sorry bye"), and in the meantime they'll go shopping around and may end up signing with someone else.
Having a promised date lets you keep the opportunity going and in some cases can even let you sign them there and then - you sign them under the condition that feature X will be in the app by date Y. That's waaaay better for business, even if it's tougher for engineers.
Re: How I estimate work
#19I 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.
Re: How I estimate work
#20Here'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.