Ask HN: on Earth do you estimate software projects
I almost never know how long a software task is going to take before I do it. More and more I'm being asked for timings, but I feel like:
(a) I'm just picking a number so big that I hope I'll be able to avoid flack for being late
(b) Actually estimating with any degree of accuracy feels like a lot of extra work that slows me down doing the actual coding.
Does anyone else out there have a good grip on this stuff? Or is everyone just throwing around numbers and hoping?
5 comments
[ 4.0 ms ] story [ 22.3 ms ] threadSome will drink the cool aid of Scrum and Agile, while forgetting Developers will quickly adapt their estimates, so as to make sure they can match the next Sprint. With experience, and as long as the requirements and domain are similar, Senior Developers can become quite good at it, as long as the domain and complexity stays the same.
The same way an experienced bricklayer, or house painter, can give you a pretty good estimate. Ask them to also install a kitchen or repair a roof and if it's one of their first jobs...You can throw away the estimates...
"Evidence Based Scheduling" - https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
“I love deadlines. I love the whooshing noise they make as they go by.” ― Douglas Adams, The Salmon of Doubt
There are way more moving parts and variables in the software world.
The same change that took 5 minutes last time could now take 5 days because someone changed the schema or anything else. Where's the integration test? That part of it got excluded some weeks ago. Why didn't anyone notice? It's not impacting customers...
Software is complex yet a lot of modern organizations turn a blind eye to lots of it if it doesn't "impact the business".
I try to break down such a task, often a large one, into parts no bigger than about half a day, working out the overall structure and some of the detail of each part. Then tot up the time for those parts and double it (or more) as above.