Ask HN: on Earth do you estimate software projects | Hacker News Reader

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?

View on HN

Asking for estimates on Software Projects is like asking if a program will terminate... ;-)

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.

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

> 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...

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".

The problem is, the more experience you have, the more challenging tasks you get given. This makes complete sense. But it also means that very often you are doing a thing you haven't done before. I guess at some level of experience it levels out...

Experience. And double whatever number feels right, and possibly again.

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.

Break it down into smaller chunks and estimate those. Pad for unknowns.

Reply on news.ycombinator.com