It's quite ridiculous for a number of reasons, well documented by research and experience: software engineers can't estimate how long something will take with any kind of accuracy.
Of course, the business still needs time estimates, so someone will somehow attempt to turn them into time estimates. But that can't be helped.
Yeah, when put as an estimate of effort or complexity, we can be good at estimating that. But that isn't how it was put.
> so someone will somehow attempt to turn them into time estimates.
It works until it doesn't. I would estimate manually entering data as "pretty easy" but it won't be done in a day no matter how much you pay me. I can only type so fast. There are many tasks that are easy but take a really long time, and many complex tasks that take a very short amount of time.
You never get handed a task which is "write as much of a prototype of a system which would do this, so we can estimate how much more work we think is involved".
And then when you do have enough knowledge to reasonably estimate, people just declare with no evidence that it should be quicker anyway and then are surprised when it is not.
Using time tracking, I was able to discover I only spend 2-3 hours per workday actually programming, the rest was all interruptions and such. Thus I can estimate that one day really equals 3-4 workdays. Then my project manager throws in another 3-4x on top of that to deal with scope creep, rework, bug fixes, etc... and we're usually on-target ~50% of the time.
An SDE1 was expect to spend 4hr coding a day; an SDE3 about 2.5hr coding a day.
That’s normal for a job, eg, apartment maintenance (my college job) would have us actually wokring about 4 hours a day, between setup, cleanup, breaks, travel, miscellaneous tasks, etc.
Convincing other SDEs to assign points to stories based on that (4hrs of coding per point) was surprisingly hard.
The non engineer types won't hand you that, but I've had some success with proposing that when there's a lot of uncertainty.
The most common problem with estimates is hidden or forgotten complexity, which makes both time and "effort", whatever that means, go up.
Software engineers, when pressured by managers to provide low estimates and/or to provide estimates quickly, will estimate inaccurately. (It can also be deliberately high as well as low, based on previous experience of having their estimates chopped in half.)
Whether you use SP or T-shirt sizes or whatever, somebody is translating that into days because days (and thus dollars) are what matter to the business. If someone asks me for an estimate, I'll give them a range in days/weeks, and they can turn it into whatever nonsense unit they like.
Sure we can, it's always one of:
- A couple of minutes
- Today
- A week or two
- Probably around a month
- I have no idea, could be any of the above or more
There are simply too many unknowns in other libraries and systems to be accurate.
It's just that estimating well needs people with training on how to do that, and then it takes substantial time to make good estimates. And there will still be significant error bars (if the estimate isn't a range, it doesn't count as an estimate). But it's certainly doable.
To narrow down the estimate to what they want would take just as long as just doing the work.
It’s this sort of disinformation that perpetuates the contingent of software developers that cry bloody murder whenever they’re asked to say if something will take a day or a year.
> software engineers can't estimate how long something will take with any kind of accuracy.
This is both irrelevant and wrong.
It’s irrelevant because t-shirt sizes, story points, and other abstract measures, are - intentionally - not measures of time. It’s a measure of effort, benchmarked against other units of work. Yes, this can, sometimes, give a vague indication of time. It’s also useful for other reasons, too, like weeding out whether or not everyone is on the same page with regard to what needs to be done in the first place. All of this is explained in literally any primer on the subject.
You’re wrong in saying that software engineers aren’t capable of estimating effort (or even time) with any degree of accuracy. They can. I can tell you that my Python hello world script will take less time and effort than rewriting the Linux kernel. None of the “research” and “experience” that you so confidently refer to says what you think it does. It says that there are big limitations to the degree to which timelines can be estimated. This is entirely true. But there’s nuance to it. You’re so desperate to find a shortcut to being smart on the internet that you’re spreading blatant disinformation in the process.
Software engineers can't estimate how long things will take: https://www.sciencedirect.com/science/article/abs/pii/S02637...
They're wrong, 60% of the time by overestimation and when underestimated, so vastly wrong it's terrifying. I remember this one time I merely had to update a component in prod. Everything went fine in staging, then when I pressed the "button" in prod ... all hell broke loose. We spent the next 4 days fixing it.
I never wrote that software engineers can't estimate effort, I said they can't estimate time, but you're accusing me of the former.
If you're working with a system where your staging environment is not sufficiently close to your prod environment to be entirely predictive of behaviour, that's a "known unknown" and should be in the estimate.
The time/work to investigate and fix it probably wasn't considered (or shouldn't have been, at least) part of the work on the component you were changing - that was just delayed, same as it would be in scenarios like "Dave got hit by a bus and he's the only one with the prod password" and "Our CI service suddenly went out of business and we need to migrate everything".
I've written TV apps and in that world I've often given estimates that are 5 days of actual work but, because Samsung's QA process can take 6 weeks and spurious rejections are common, "deployment" will often take literally months.
Time to release and time for development can be totally different things and it's arguable whether "waiting" time should be included in any individual estimate at all. (You're adding 4 separate features and doing 2 bugfixes in one release, which one gets +2 months? In reality "submit/release" becomes a different ticket/task.)
How would we measure that?
I'm sure some people are significantly better than me at estimates, but I haven't met them. Estimating the unknown without serious research that borders on just doing the job is nigh impossible. And we're just an in-house dev team, so we never, ever do the same thing twice.
Estimating how long to put up another wordpress site is a lot easier than estimating a new project with new requirements and new tools. I typically find that people who think estimating is easy are just doing the same things over and over for new clients, rather than doing new things all the time for the same client/employer.