Our industry is filled with really smart people.
So how can we understand complex functional/OO programming, devops and all the rest of it. But not understand how to estimate something on a scale of difficulty and instead prefer to give a fixed estimate and be held to it

I agree
How the hell would I know how long something is going to take in exact hours ?

I could discover other shit along the way I didn’t foresee

A dozen other pieces of code could depend on something I’m doing not breaking it

Other whole processes could be affected etc etc

Or something could just be more involved than expected

That's because there are business interests involved.

We know how to do it. Explaining the system to others is hard.

What I'm saying is, we work with idiots.

What stunned me is that the devs have the choice and they chose to hold a gun to their own heads.

@Inxentas business aren’t pushing it. They will go with working the way the dev team wants to.

I always overrstimate and tell others to do that too. It's better to deliver earlier than expected than later...

It's just a dumb guess based on previous experiences, and I try to push for an extra day or two if possible. It's dumb to set strict timelines.

I love when:

“I have no specs, I cannot estimate how many hours it will take” or “how can I estimate if or how long it will take me to find a fitting library”

Is answered by:

“Just make a guess!”

I think the only possible answer is:
“Ten years. Maybe less, maybe more.”

@piratefox I think the only valid answer for that question is "I'll have a better idea by day x, let's review then", and that's how a lot of planning *should* be done, based on incremental milestones, but someone somewhere still wants an answer to the question "when can we sell xyz", so there's always a push for long term answers.

The goal by Eliyahu M. Goldratt is really interesting for this kinda thinking.

@Hazarth y@atheist yeah, I’ve heard about some of his ToC stuff. Not read it though.

@atheist ideally yes, but without precise specs it’s basically asking: “how long does it take to cook a meal?”

Which meal? A salami sandwich? Pulled pork? Huge time difference

@Hazarth our rule was add 4 hours to anything that didn’t take a few minutes and found that up to a half hour

If it takes a week, say it takes 2 weeks. Then when your manager decides to shave off a week, then you can get it done. Some managers are assholes this way.

@piratefox precisely
If I was doing estimation of a job in say printing or manufacturing I’d have go research the components first and then provide an estimate on cost and time

Some shit is easy some shot is hard

@piratefox this is kinda my point, you can give a reasonable estimate of when you can have concrete specs by (that might need amending), then you can give a reasonable estimate to the next point. That's what the whole "agile" thing is meant to be.

@atheist I feel it strongly depends on the manager/C levels, unfortunately.

There are many managers which will actively oppose and punish the idea of incremental approach (after all, we’re implementing “our version” of agile), that’s why I said on a theoretical standpoint I agree… but irl I met more assholes than decent managers (not all of them, a couple of them were so nice and smart I miss them all the time).

Changing 2px in the padding is a critical bug level of stupidity clashes with the idea of incremental deploys… also all the inspired-by-Steve-Jobs/applefags managers tend to want everything perfect.

@piratefox you’re right that the bad ones out number the good by quite a distance.

@piratefox agree. The "our version of agile" is just "waterfall but we sound hip". So annoying. I've seen it at everything from a 15 person startup to faang.

I think people tend to look at software engineering as "manufacturing product", when a better parallel is "designing a product to be manufactured".

Incremental deploys, I'm a bit split on, in some situations it's necessary to do large, low frequency deployments, eg when you're in an industry that requires a lot of validation + change acceptance. But any conversation about something being pixel perfect is stupid, unless it's visibly wrong. No one person knows what a good UI should be. They're bike sheding. Get them to do a course in HCI.

@atheist yeah I’ve heard the “agile isn’t prescriptive, you do the parts you need” argument way too many times. There comes a point where you’ve thrown out so much of it that claiming you’re still agile is complete bullshit

@atheist agreeeeed!

@Hazarth
I tried to overestimate - but it never worked.
So i now just always say that i don't know and when pressured just give some random estimate and use a lower limit of one day (even for the smallest shit).
My random estimates are way better than my actual estimates where before...

Guess, some people just can't do estimates.

It's interesting thinking about it really. Stuff that tends to get used from agile tends to be the transparency stuff, kanban boards and standup. The "we want to keep track of you" stuff. Am I wrong?

@atheist nope, you are right in all the line… just like a lot of “full remote work from anywhere” companies being basically just office work companies without an office:
It’s not the same, stop asking me to join your fucking standup at 4am cause your attention span is too little to write mails, dear managing person and most importantly stop asking me to show my face: I have chosen a remote work so I do not have to care about how I look while I waste my time programming your shitty Ecommerce, not because I wanted to have video meetings.

Sorry, projecting a bit. 😅

@piratefox no worries. Current work don't care about video cameras, does feel a little bit alienating. Literally for my first month had about 5 minutes of standup a week and maybe 20 minutes chatting with my slightly useless manager. Me suggesting a buddying system for new joiners was conveniently "forgotten" until they were unhappy I hadn't integrated well with the team, wasn't helping/answering questions (literally offered repeatedly but people didn't know who I was and kept asking the same bloody person). What was I talking about?

Ah yeah, no worries I understand your frustration.

@atheist I guess it really depends on the person!

Luckily at my current job we use Kanban, so no needles estimates. Work is done when it’s done, not when it should be done according to the burndown chart.

At my previous work in practice we pretty much just estimated everything the same because everyone was tired of estimation meetings. Even worse, we often had to estimate work that we had no expertise in. As a data guy how would I know how much an embedded port of an ML model takes to develop?

I get that consultant projects sometimes need to use estimates to guess cost or because clients demand it.

But in product development without external clients it's avoidable.

Scrum with story points has worked pretty well for me so far. It helps to plan things out properly too.
But it takes only 1 asshole manager to fuck it up so I can see it not working for everyone.

The whole point of story pointing is exactly that - to estimate considering a relative scale of complexity rather than a fixed scale of time. If you're doing it properly at least. Wouldn't be the first time I've seen people think story points translate to hours of work...

@AlmondSauce yeah, and the scale goes up the way it does to represent uncertainty.

Instead we make up a number of hours/days and openly admit we don’t know if it’s right (yet argue over it).
Then we make up another number for contingency and add that, because we know the first number is wrong.

Madness.