21–30 of 231 posts
To accurately estimate means developers and product management have collectively discussed the requirements to a level everyone understands clearly. Without this an estimate is as accurate as a weather report for 90 days out. A good estimate may also require "spiked" to test concepts to get to a reasonable estimate. I'm currently in a project that is terrible as the development team provides estimates without even re…
Don't do it if you can avoid, especially if company culture is to treat rough estimation as a promised deadline. If you can't avoid giving estimation, try to pad it as much as possible, add every single uncertainty to the task list, and estimate very conservative. Add enough time for testing, communication, work on change requests. And even after the original estimate is approved / published be sure to communicate up…
I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it.
The process will require dev resources, business resources and probably people from the support team and will take a lot of time.
I'm happy to do it. It's actually my favorite part of the job. But the business invariably doesn't want to spend the time and money to do that.
They'd generally much rather start with a fairly vague description of what they need and let the devs keep throwing stuff against the wall and see what sticks.
Good and accurate estimation is not just a dev function. It requires buy in and input from the entire business stack.
Software estimation is only hard when you don't understand what you have to do or how it will be done. Just keep breaking the problem down into sub units that you or your team understand and can fairly accurately understand the effort and risk of (because they've been done before)
And when there are chunks that you haven't done before? Or when breaking it down will require going to a level of detail that means basically fully designing/writing your system in order to estimate it?
Don't do it if you can avoid, especially if company culture is to treat rough estimation as a promised deadline. If you can't avoid giving estimation, try to pad it as much as possible, add every single uncertainty to the task list, and estimate very conservative. Add enough time for testing, communication, work on change requests. And even after the original estimate is approved / published be sure to communicate up…
Good estimates are critical to plan dependent activities and setting customer expectations. If we don’t estimate then we are saying that software engineering is not an engineering discipline. You can have that view, but in my experience it does not lead to good outcomes. If I can assume you’re an SDE for a moment, I actually agree with the part of you not providing estimates. Recently I’ve done the initial estimate f…
Not a mature engineering discipline.
If you can budget a planning phase in development that allows you to quickly explore the unknown unknowns and known unknowns to investigate critical bottlenecks and uncertainty before estimating and you're able to lock that down with a set of features, then I think you can create decent estimates.
That's rarely how any development environment in current existence operates though, at least from my anecdata. Most are 'agile' that can drastically shift directions, feature/scope creep is a continuous problem, there's a constant time pressure exerted by managenent on developmeny teams in hope to optimize a bit more productivity out of their high price tags which gives no slack space for them to dig into these issues (except maybe some personal time).
The entire modern development culture in most business environments is designed in a way that makes any sort of good quality estimation nearly impossible. In the best of conditions it can be hard but manageable, most environments are the worst of conditions.
Software estimation is only hard when you don't understand what you have to do or how it will be done. Just keep breaking the problem down into sub units that you or your team understand and can fairly accurately understand the effort and risk of (because they've been done before)
And when there are chunks that you haven't done before? Or when breaking it down will require going to a level of detail that means basically fully designing/writing your system in order to estimate it?
...
Except weather reports 3 months out are not reliable, unless they are so vague as to be meaningless. I have frequently encountered people who claim to be able to give accurate software estimates. Inevitably, this means that they simply know how to cut requirements as the promised ship date arrives. Which is a useful skill, but not the same as accurate estimates. I have stopped arguing the point, because it doesn't matter what the reality is, business concerns mean that an estimate is required sometimes. But it doesn't mean anything more than the weather estimate for 3 months from now. If you got it right, you were mostly lucky.
‘You can get good at estimation’ Only if you work in an extremely repeatable well trodden domain. If you are so skilled at estimation, I’m sure Tesla would love you to tell them how long FSD will take and would pay a premium!
You don't need to work in an extremely repeatable domain to get good at estimation. There is very little in my day to day job that is repeatable, but I can roughly look at the project I'm on and compare the scope of it to the projects I've done before. If you really do think that every project you're working on is completely incomparable to anything you've worked on before you're probably concentrating on too low lev…
Lots of estimation experts out in force today, obviously Hacker News is full of sooth sayers and savants or maybe they just over point everything like everyone else.
/s
The best estimation technique I've seen is ROPE: Realistic, Optimistic, Pessimistic, Equilibristic. It's fast to ballpark, effective solo or with teams, great for PMs and managers, and able to go directly into critical chain scheduling or monte carlo simulations. https://github.com/SixArm/sixarm_project_management_rope_est...