I never understood this point of view. It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification.
I have personally only ever had success with estimates that were "is this a project, or is this a task that belongs to a project". Perhaps stretching to t-shirt sizing of S, M and L. Anything beyond that, say, comparing two projects to be able to prioritize and see the opportunity cost etc etc is a fool's errand.
From The Black Swan by Nassim Taleb:
[Critics say that] the maps we had were better than having no maps. [...] This is the strangest of errors.
I know few people who would board a plane heading for La Guardia airport in New York City with a pilot who was using a map of Atlanta’s airport “because there is nothing else.”
S/M/L is about as good as it gets. I’ve tried using story points but I think the point isn’t to have exact estimates but to figure out if 1) it’s too big for the spring and if so break it down into smaller; 2) is this someone a single person can do or it takes multiple; 3) can I do a couple of these in a single sprint (M) or it’s the only thing (L) or it’s just “5 minutes” (S and usually a day or two because nothing is 5 minutes).
I’m a fan of Taleb, but also a fan of using good maps. Note that Taleb isn’t advocating no maps at all, just that it’s stupid to use the wrong map just because it exists.
I agree that I’d rather have no estimate than a bad estimate, but it’s not like those are the only two options. I want a good estimate or at least a useful estimate over nothing or bad.
> It's impossible to predict the future, and it's impossible to predict the complexity of something you've never done before. Given that, estimates can not be useful, other than as a tool for political post hoc justification.
It is, however, possible to provide more information than "whatever" about how long it will take to achieve a goal. I have had goals I've worked on that were summarized with things like
- Could take anywhere between 2 days and 2 weeks, depending on factors
- Has an external dependency on X, and we don't have any insight into when X will be available
- May have other external dependencies, but we won't know until we're a few days into the work
- Not sure yet what the complexity of using <this API we need> is, so we'll need to check back in with more information once we have some time to experiment with it
- Expectation is about 5 days, on this, but it could be as short as 1.5, and could be as long as 3 weeks, depending on some factors
All of those things are more information than you had before, and allow the people that make decisions (which may be you and your team, or may be someone higher up the chain) to make _better_ decisions (or at least, better informed decisions)
And if you're working on something that you literally have no information on what's required for it, what the complexities might be, what the unknowns might be, etc... then perhaps the task you should be working on is "Identifying the work required to achieve <goal>", not "<goal>".
There is very little chance that what you are working on has never been done before. Most likely, you are writing simple code to do simple things. These things can be broken down into simple tasks, and these simple tasks can be estimated.
Unless you are working on ChatGPT-6, i assure you, you can definitely estimate how long things will take. your estimates will not be perfect, but they will be good approximations for guiding development.
Even OpenAI by now probably is pretty good at estimating how long the next ChatGPT version will take to develop, since they've done it 4-5 times already.
Alway always distrust someone who says "we are doing things that have never been done before". At the very bleeding edge (OpenAI, SpaceX), you are iterating on something that has been done many times before, but with a small innovation.
Code is infinitely copyable. If it has been done before it can just be copied, hence the time it takes is 0. If it takes more than 0 then what you are doing is actually something else entirely, like gluing said code to something else for the first time.
If it is not the first time, then you already have the code and hence the time it takes is 0.
There are cases where code is similar to code you've written before or you cannot just copy the old one due to licensing constraints. In this case estimation is easy, somewhere between an hour to a day or two.
Anything larger can be broken down to hour to day or two chunks since it has been done before.
All great, except this last case simply doesn't exist for the type of work that I do. And that is true for many people, software is extremely unpredictable because the stuff you need to build on top of might as well be quicksand.
I don't think the folks that say this usually mean "never done before" in the way that you are saying.
"never done before" in my experience usually translates to "this combination of things doesn't have precedence internally [to the team or company], so I have to figure out how to glue all of these parts I don't understand together".
I have personally only ever had success with estimates that were "is this a project, or is this a task that belongs to a project". Perhaps stretching to t-shirt sizing of S, M and L. Anything beyond that, say, comparing two projects to be able to prioritize and see the opportunity cost etc etc is a fool's errand.
From The Black Swan by Nassim Taleb:
[Critics say that] the maps we had were better than having no maps. [...] This is the strangest of errors.
I know few people who would board a plane heading for La Guardia airport in New York City with a pilot who was using a map of Atlanta’s airport “because there is nothing else.”