[seviu]

I am in a project where we have to give estimates in hours and days.

Needless to say we always underestimate. Or overestimate. Best case we use the underestimated task as buffer for the more complex ones.

And it has been years.

Giving estimations based on complexity would at least give a clear picture.

I honestly don’t know what the PO and TL gains with this absurd obscenity.

[SoftTalker]

The last director I had would ask "is it a day, a week, a month, or a year" he understood that's about as granular as it's possible to be.

And he really only used them in comparison to estimates for other tasks, not to set hard deadlines for anything.

[XorNot]

Knowing nothing else about him, I like him based on this alone.

I've been in planning sessions where someone would confidently declare something would take half a day, was surprised when I suggested that it would take longer then that since they were basically saying "this'll be finished mid-afternoon today"...and was still working on it like 3 weeks later.

[dgunay]

Besides the usual unknown unknowns, I've also seen this happen with tasks that involve a lot of coordination in the SDLC. Oh the PR went up at at 2pm PST? Coworkers in EST won't review it until tomorrow. Maybe some back and forth = another day until it clears review. Then QA happens. QA is heavily manual and takes a few hours, maybe with some false starts and handholding from engineering. Another day passes. Before you know it the ticket that took an hour of programming has taken a week to reach production.

[jrs235]

As mentioned in a sibling comment reply:

Time estimations, or conversations to days or other units, typically fail because if a developer says 1 day they might mean 8 focused uninterrupted development hours while someone else hears 1 calendar day so it can be done by tomorrow, regardless of if a developer spends 8 or 16 hours on it.

[jrs235]

Are we estimating developer cost (investment cost, writing code only tome), development costs (investment costs including QA time), or time to delivery and first use? People want and use estimates for different purposes. You point out great reasons why knowing what the estimates are for is important.

[skeeter2020]

This is essentially t-shirt sizing without all the baggage that comes from time. Your boss is trying to use the relative magnitude but it's inevitable that people will (at least internally) do math like "7 day tasks is the same as one week task", or worse over-rotate on the precision you get from day/week/month, or even worse immediately map to the calendar. Suggestion: don't use time.

[cnity]

If you pretend not to use time, everyone will do an implicit time mapping in their head anyway. I've never seen it go any other way.

[seviu]

Surprisingly prob yes

But still we are much better at estimating complexity

Time estimations usually tends to be overly optimistic. I don’t know why. Maybe the desire to please the PO. Or the fact that we never seem to take into account factors such as having a bad day, interruptions, context switch.

T-shirt sizes or even story points are way more effective.

The PO can later translate it to time after the team reaches certain velocity.

I have been developing software for over twenty years, I still suck at giving time estimates.

[jrs235]

Time estimations, or conversations to days or other units, typically fail because if a developer says 1 day they might mean 8 focused uninterrupted development hours while someone else hears 1 calendar day so it can be done by tomorrow, regardless of if a developer spends 8 or 16 hours on it.

[shiroiuma]

Yes, I've seen this too in sprint planning. However, the layer of indirection I think is helpful. If you use actual time, then when something isn't done after 1 week when that was the estimate, then bosses are asking why. If your estimate was simply "8 story points", then the bosses can't point to a calendar and complain. They can try to argue that an 8-point task should be done in a week, but then you and the scrummaster remind him that points don't map directly to time, just effort.

[lmm]

It's probably not possible to fully prevent people from thinking about time at all, but the more friction you can add, the better.

[SoftTalker]

That's true. Anyplace I've worked where we did planning poker, "points" were always just a proxy for time.

[fallinditch]

Here's my observation: ballparking an estimate for a whole project, in my experience, tends to be more accurate than estimating each task and adding them together.

I like to think of this as 'pragmatic agile': for sure break it down into tasks in a backlog, but don't get hung up on planning it out to the Nth degree because then that becomes more waterfall and you start to lose agility.

[121789]

Hours is insane. But ultimately time is money and opportunity cost. Software engineering can’t be the only engineering where you ask the engineers how much something will cost or how much time it will take and the answer is “it’s impossible to know”. Even very inaccurate estimates can be helpful for decision making if they are on the right order of magnitude

[zdragnar]

There's two things here that get overlooked.

First, people asking for estimates know they aren't going to get everything they want, and they are trying to prioritize which features to put on a roadmap based on the effort-to-business-value ratio. High impact with low effort wins over high impact high effort almost every time.

Second, there's a long tail of things that have to be coordinated in meat space as soon as possible after the software launches, but can take weeks or months to coordinate. Therefore, they need a reasonable date to pick- think ad spend, customer training, internal training, compliance paperwork etc.

"It is impossible to know" is only ever acceptable in pure science, and that is only for the outcome of the hypothesis, not the procedure of conducting the experiment.

[collingreen]

> "as soon as possible after the software launches"

This isn't true, just desired, and is one of the main roots of the conflict here. OF COURSE you would like to start selling in advance and then have billing start with customers the instant the "last" pr is merged. That isn't a realistic view of the software world though and pretending it is while everyone knows otherwise starts to feel like bad faith. Making software that works, then having time to deploy it, make changes from early feedback, and fix bugs is important. THEN all the other business functions should start the cant-take-back parts of their work that need to coordinate with the rest of the world. Trying to squeeze some extra days from the schedule is a business bet you can make but it would be nice if the people taking this risk were the ones who had to crunch or stay up all night or answer the page.

Trying to force complicated and creative work into a fake box just so you can make a gantt chart slightly narrower only works on people a couple times before they start to resent it. 10x that if management punishes someone when that fantasy gantt chart isn't accurate and 100x that if the one punished is the person who said "it's impossible to know" and then was forced into pretending to know instead of the person doing the forcing.

[skeeter2020]

My take: if they have not done the work to get to at least some degree of a spec, and they won't give you time to review and investigate, they get nothing more than a vague, relative t-shirt size.

[yetihehe]

I think software is one of those VERY rare things, where inaccurate estimates can actually be inaccurate by "orders of magnitude". After 20 years in the field, I still managed to use 2 months of time on a task that I estimated as 10 days.

[camel_gopher]

A rule that has suited me well is to take an estimate, double it, and increase by an order of magnitude for inexperienced developers. So a task the say would take two weeks ends up being 4 months. For experienced developers, halve the estimate and increase by an order of magnitude. So your 10 days estimate would be 5 weeks.

[QuercusMax]

The biggest estimation effort I ever took part in was a whole-system rewrite[1] where we had a very detailed functional test plan describing everything the system should do. The other lead and I went down the list, estimated how long everything would take to re-implement, and came up with an estimate of 2 people, 9 months.

We knew that couldn't possibly be right, so we doubled the estimate and tripled the team, and ended up with 6 people for 18 months - which ended up being almost exactly right.

[1]: We were moving from a dead/dying framework and language onto a modern language and well-supported platform; I think we started out with about 1MLOC on the old system and ended up with about 700K on the rewrite.

[yetihehe]

10 days was already after I used this algorithm. Previous several tasks on that codebase were estimated pretty good. Problem with this is that some tasks can indeed take SEVERAL orders of magnitude more time that you thought.

One of the hardest problems with estimating for me is that I mostly do really new tasks that either no one wants to do because they are arduous, or no one knows how to do yet. Then I go and do them anyway. Sometimes on time, mostly not. But everybody working with me already knows, that it may be long, but I will achieve the result. And in rare instances other developers ask me how did I managed to find the bug so fast. This time I was doing something I have never before done in my life and I missed some code dependencies that needed changing when I was revieving how to do that task.

[bdangubic]

I’ll send my friend that has a construction company to build your next 3500 sq ft house for $13.6 million dollars :)

[bumby]

Something often overlooked in cost/schedule estimates is the nature of joint probability of actions slipping. Action A slips and causes action B to slip. I think software is tougher to estimate because the number of interfaces is often much higher, and sometimes more hidden, than in hardware.

[bdangubic]

as opposed to say building a house where framing can totally slip while we run electricity and build a roof floating in mid-air

software is only tougher to estimate if incompetent people (vast majority of the industry, like 4+ million) is doing the estimating :)

[yetihehe]

My home construction slipped 6 months on 2 year build time. It happens in construction very often.

> software is only tougher to estimate if incompetent people (vast majority of the industry, like 4+ million) is doing the estimating :)

No, it is tough to estimate, but not only for incompetent people. And "incompetent" can be stretched to "don't know what he's doing", which is how I operate most of the time. I don't know what really needs to be done until it's done. Main part of my work is research on what actually needs to be done, then "just" implementing it. If I waited with estimating until I know what needs to be done, I would spend 3/4 time estimating and then 1/4 with clear understanding and good schedules (example description: I will be clicking keys for 5 hours).

[rkomorn]

> My home construction slipped 6 months on 2 year build time. It happens in construction very often.

Tangent, but I have at least 3 friends that would've (in retrospect) been nothing short of ecstatic if their home construction had "only" slipped 6 months on a 2 year timeline.

[bumby]

That’s a bit of a strawman considering I was deliberate in saying hardware interfaces are limited and not saying they are zero. The number of interfaces in software is often going to be orders of magnitude greater. The network effects and failure modes will often increase geometrically with the number of interfaces. In fact, big construction design firms have tools to easily identify and mitigate the “clashes” you bring up and those tools tend to work well because there is a finite number and the designs are well-documented (as opposed to software where changes are relatively cheap and easy so they often occur without documentation)

Saying incompetence is the reason is a trivial rebuttal that ignores the central claim about complexity. It’s like saying “the reason why we don’t have a theory of everything is because we don’t have competent physicists”

[Scarblac]

That's a factor four or five ir so, so still less than an order of magnitude.

[njovin]

The next natural progression of this line of discussion between "the business" and engineering is for them to agree on a time range as an estimate. Engineering doesn't want to say it'll be done in 6 weeks, but they feel okay saying it will take between 4 and 20 weeks so this estimate is accepted.

You can guess what happens next, which is that around week 8 the business is getting pretty angry that their 4-week project is taking twice as much time as they thought, while the engineering team has encountered some really nasty surprises and is worried they'll have to push to 24 weeks.

[shiroiuma]

You're forgetting the part where the business expects the engineers to pull all-nighters so they can meet the deadline.

[skeeter2020]

it is still better to give a range though because 1. it explicitly states the degree of unknown and 2. no boss is going to accept 4-20 weeks, which means you start talking about how you can estimate with better accuracy and the work required to do so, which is a major goal of planning & estimation.

[lmm]

> Software engineering can’t be the only engineering where you ask the engineers how much something will cost or how much time it will take and the answer is “it’s impossible to know”.

Because it's not engineering at all. But even if it was, plenty of engineering projects are impossible to estimate - the ones that are doing something novel - and disliking that fact doesn't make it go away.

> Even very inaccurate estimates can be helpful for decision making if they are on the right order of magnitude

If what the business wants is an order-of-magnitude, they should ask for that; often (not always!) that's a lot easier.

[Scarblac]

> I honestly don’t know what the PO and TL gains with this absurd obscenity

There are marketing campaigns that need to be set up, users informed, manuals written. Sales people want to sell the new feature. People thinking about road maps need to know how many new features to can fit in a quarter.

Development isn't the only thing that exists.