> If you go to the other end of the spectrum and talk to engineers who work in industries where target dates are critical you’ll discover a lot of people who are very good at breaking down projects and accurately estimating dates without relying on crunch time to get things done.
I am yet to see this done well, though hearing that it's apparently possibly has me cautiously optimistic.
In my experience so far, however, I've mostly seen incomplete requirements (one could argue that a perfectly accurate spec would be no different from executable code, the end product itself), changing requirements, difficulties in estimating the impact of needing to migrate old data or accommodate/refactor old logic, little proper estimation of testing overhead, the impossibility to predict how long working with external services and integrating with them would take, especially when cross coordination with another team is necessary, the impossibility to predict what might break in regression testing or additional edge cases that might be discovered, as well as the greater impact of needing to utilize particular tech stacks (e.g. Kubernetes with a particular service mesh) due to external requirements.
It's gotten to the point where I feel like adding a new form to any given application might take anywhere from 2 hours to 2 weeks, depending on what's going on in it (e.g. a well architected and simple monolith with onboarding guides and commented code vs microservices with little to no documentation, to serve as examples of different orders of magnitude of complexity).
Estimations feel like just making stuff up on the go at best and like something actively harmful (being urged to make promises that are going to be false a lot of the time) at worst.
The only way to do them would be not to do them - instead have some software look at the issue request and say: "Okay, you have X requirements of the following type: ..., after analyzing this project's issue history and time tracking across 5432 issues, it would appear that this issue would take between 4.2 and 7.3 days to resolve."
To me it seems that if you need to be able to give accurate estimations, you'd also need a very predictable and boring tech stack across many if not all of your projects, which doesn't seem feasible in web dev, given how fast everything seems to progress and given how much CV padding one must do to remain hireable (instead of, say, using jQuery in 2022).
I am yet to see this done well, though hearing that it's apparently possibly has me cautiously optimistic.
In my experience so far, however, I've mostly seen incomplete requirements (one could argue that a perfectly accurate spec would be no different from executable code, the end product itself), changing requirements, difficulties in estimating the impact of needing to migrate old data or accommodate/refactor old logic, little proper estimation of testing overhead, the impossibility to predict how long working with external services and integrating with them would take, especially when cross coordination with another team is necessary, the impossibility to predict what might break in regression testing or additional edge cases that might be discovered, as well as the greater impact of needing to utilize particular tech stacks (e.g. Kubernetes with a particular service mesh) due to external requirements.
It's gotten to the point where I feel like adding a new form to any given application might take anywhere from 2 hours to 2 weeks, depending on what's going on in it (e.g. a well architected and simple monolith with onboarding guides and commented code vs microservices with little to no documentation, to serve as examples of different orders of magnitude of complexity).
Estimations feel like just making stuff up on the go at best and like something actively harmful (being urged to make promises that are going to be false a lot of the time) at worst.
The only way to do them would be not to do them - instead have some software look at the issue request and say: "Okay, you have X requirements of the following type: ..., after analyzing this project's issue history and time tracking across 5432 issues, it would appear that this issue would take between 4.2 and 7.3 days to resolve."
To me it seems that if you need to be able to give accurate estimations, you'd also need a very predictable and boring tech stack across many if not all of your projects, which doesn't seem feasible in web dev, given how fast everything seems to progress and given how much CV padding one must do to remain hireable (instead of, say, using jQuery in 2022).