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:<p>(a) I'm just picking a number so big that I hope I'll be able to avoid flack for being late<p>(b) Actually estimating with any degree of accuracy feels like a lot of extra work that slows me down doing the actual coding.<p>Does anyone else out there have a good grip on this stuff? Or is everyone just throwing around numbers and hoping?
Asking for estimates on Software Projects is like asking if a program will terminate... ;-)<p>Some 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.<p>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...<p>"Evidence Based Scheduling" - <a href="https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/" rel="nofollow noreferrer">https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...</a><p>“I love deadlines. I love the whooshing noise they make as they go by.”
― Douglas Adams, The Salmon of Doubt
Experience. And double whatever number feels right, and possibly again.<p>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.