[mason55]

> Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack.

And in my experience, when people don't want to buy in to doing the whole process up front but they still demand some kind of commitment, the easy way to handle it is:

"We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it takes. But we won't commit to a date and a scope unless we spend the up front time to first figure out every detail of what we need to build."

Stating it like that usually makes people realize how ridiculous it is to commit to something, but you don't know what, but you'll still do it by a certain date. And it makes them feel like you're being willing to work with them/gives them some decision making power.

[lowercased]

> commit to something, but you don't know what...

The problem comes in when people think they do know 'what' it is, and they're just... adamant that you 'computer people' don't 'get it'.

I can't speak to all my clients - some are great - but have had some in the past that just insisted I was being obstinate or obtuse or difficult by asking clarifying questions. Then they'll take hours/days obsessing over shades of blue for a screen, then... the morning of 'feature launch' they'll question why there are no notification emails for feature X, when... that morning is the first time those words have ever been spoken.

But... fortunately, I've not had project work like that in a while :)

[Jenk]

We don't even need to pretend it is an outside-of-technical-people problem. Developers (and just people in general) are just as guilty at mis-estimating their own capacity for work.

By this I mean we forget we have other things - we don't accurately account for meetings and side-tasks. We underestimate the complexity of even simple tasks. We don't account for the flames we fight habitually without much consideration. We don't even recognise the amount of time we spend just relaying and receiving information. Those intriguing and important (and still work related just not explicitly about the task we have estimated) slack messages and water cooler moments aren't accounted for in our estimates.

Most estimates are inherently given on a "if I am in a perfect working environment with no interruptions" basis and we don't even acknowledge _that_.

This is all before we even begin to appreciate that even perfect world estimates are hard because, as Ron Jeffries said:

    Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. If we had done it before, we’d just give it to you.

[Pokepokalypse]

>Most estimates are inherently given on a "if I am in a perfect working environment with no interruptions" basis and we don't even acknowledge _that_.

I had the experience of working at a company that had the practice of rigorously tracking engineer-hours. Through a time-card system. (this was for billing our clients). This way we always had a paper trail of how long we spent on a given task or project, and it was generally "against the rules" to bill hours you weren't directly working on that project.

This led to having an awareness of that imperfect working environment, and was a powerful enabler of making good estimates.

On the other hand: that documentation effort wasn't free either.

[scrose]

Then you have the companies that take every estimate and cut it down to 1 month without changing scope. Doesn’t matter if the estimates are 3 months worth of work or 6. And now as an eng you have to either lowball your own estimates and burn yourself out to seem like a ‘team player’, or push back and burn yourself out from a losing battle.

[mcavoybn]

I don't think the point of lowercased's comment was that devs don't underestimate tasks to the same degree that "outside-of-technical-people" might. They are saying that "outside-of-technical-people" don't have the experience to understand how difficult it is to give an accurate estimate or how much pressure is put on devs to agree to a deadline and take responsibility for making something happen by that date. This is compounded by the fact that stakeholders are unwilling to define or commit to a detailed set of features or acceptance criteria. The bigger the project, the more painful and difficult this becomes. Stakeholders say "Make it faster!!!" then engineers say "We agree!!! any ideas on how?".

[Jenk]

That's fair - my intention was to say that non-engineers aren't any worse than engineers. I've seen the same puzzled look and demands from development teams that are requesting changes from other development teams.

Open source projects are rife with developers demanding the near-impossible from contributors/maintainers, etc. (but plenty of examples people not being dicks as well)

Additionally, they can often be worse (toxic) about it precisely because they are developers themselves, and so think they have that understanding and start acting the alpha.

[mason55]

Yeah, it's definitely different if you're working on a contract basis. At least with internal stakeholders, whether you're building product, doing enterprise integrations, or building internal tooling, you just need to make sure that you have exec backup (or you are the exec). If you have buy-in then you can basically just set your team's policy and be done with it.

For contract work you have to do the process over and over. Frankly, if I was doing contract dev, I'd state it as an upfront policy and move to quickly fire any customers that didn't buy in.

[whimsicalism]

This is why I prefer to work for people who are smarter than I am, rather than the reverse

[amatecha]

Yeah, it's frustrating to get that push-back when it's like, those clarifying questions are just the tip of the iceberg and are required simply to get started -- basically the whole rest of the project is going to be resolving "nitpicky" details like that until it's done.

[sharken]

It sounds very much like the constraints of the Project management triangle:

https://en.m.wikipedia.org/wiki/Project_management_triangle

It's probably the first time i have seen estimation described so clearly as a choice between scope or date.

Am still trying to figure out how something like SAFe works with the above, the gut feeling is "not great".

[cjk]

> "We can commit to a date and we'll finish whatever we finish by then, or we can commit to a scope and it will take as long as it takes. But we won't commit to a date and a scope unless we spend the up front time to first figure out every detail of what we need to build."

This.

I often find myself saying “you can be feature-driven, or you can be date-driven, but not both.”

[musicale]

> But we won't commit to a date and a scope unless we spend the up front time to first figure out every detail of what we need to build

Great, we'll be expecting you to complete that by the end of next week.