this post was submitted on 24 Jan 2026
54 points (93.5% liked)

Programming

24651 readers
288 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] Aquila@sh.itjust.works 4 points 1 day ago* (last edited 1 day ago) (2 children)

How to estimate:

  1. Give a range and confidence rating
  2. Track all estimates and how long it actually took
  3. Refine future estimates to more closely match past features with similar complexity/effort required
[–] Test_Tickles@lemmy.world 8 points 1 day ago (1 children)

This is entirely true for certain types of development. There are plenty of coding jobs where you are constantly writing and rewriting the same type of thing over and over again. UI development, web page development, ect. Any place we you have multiple "customers" wanting a similar thing done, but with a different look or aesthetic. Or maybe you work for a company that makes stuff that needs to be refreshed every so often to avoid looking antiquated.

But then there's also lots of people who are constantly doing things that they have never done before. I am not even talking about the poor suckers out there right now have having to "add AI" to random shit right now without even having a clue wtf that even means. You have plenty of people doing what is essentially "we want you to do this thing we have never done before". How do you estimate time on a ticket that essentially says, take this 30 year old pile of code that has been hacked and rehacked by dozens of people (all who have either retired or left the company to escape this dumpster fire you are being handed) and "fix this bug" that has been around for a decade. It's been there for a fucking decade. When the first version of this ticket was originally generated it was done in a ticketing system that has been replaced by 2 generations of ticketing systems since then. Whatever the issue is, it's a big enough issue that it can't be answered with "can't do/won't do", but at the same time everyone who has been assigned it in the last decade has at best created half ass work arounds. Good luck with pulling a number for how long it is going to take you to figure out what the bug even is, much less how to fix it.

[–] Aquila@sh.itjust.works 5 points 1 day ago

Yea estimating sucks ass. But in that situation id give a large range with low confidence

[–] Kissaki@programming.dev 3 points 1 day ago (1 children)

Depending on how stable your work, environment, and risks are, the range size and confidence rating may change a lot or reach refinement limits quite fast.

[–] Aquila@sh.itjust.works 2 points 1 day ago

Totally but thats why they're called estimates. We cant tell the future