Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why software projects take longer than you think – a statistical model

erikbern.com

Post reply on HN
Print view View original

151–160 of 324 posts

Re: Why software projects take longer than you think – a statistical model

#151

Post by JustSomeNobody »

undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

> “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.”

This is my default. Even when I am fairly confident I know what the code does, I want to double check. And it isn't just so I don't short change myself on time. If I tell them X days and deliver on 0.X days several times, they'll start thinking I overestimate everything and cut me off at the knees. It pays to get as accurate as possible.

Re: Why software projects take longer than you think – a statistical model

#152

Post by madhadron »

tonyedgecombe wrote: post #74
teddyh wrote: post #60

According to Joel Spolsky¹, programmers are generally bad at estimating, but they are consistently bad, with the exact factor depending on the individual. So by measuring each person’s estimate and comparing it to the actual time takes after the fact, you can determine each person’s estimation factor, and then when they estimate again, you can get a pretty reliable figure. 1. https://www.joelonsoftware.com/2007/10/26…

You know that article was written to sell a feature in their bug tracker. I like Joel's writing but I'd take that piece with a pinch of salt.

I tracked this myself for a few months and found that I was fairly consistently estimating around twice the actual required time. That was for fully scoped out and planned work, mind you (and that I was the one who scoped and planned).

Re: Why software projects take longer than you think – a statistical model

#153

Post by commandlinefan »

koonsolo wrote: post #59
undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

> They probably don’t want you to lie, but there is a small chance that they pruessure you to. In my experience, most of the time there was pressure. I remember a funny conversation between my project manager and a colleague: PM: "We need to have X as soon as possible, how long will it take you?" Dev: "Oh that's, easy, I can finish it tomorrow." PM: "Tomorrow??? That's impossible, because it needs a and b, no?" Dev:…

Remember - the pressure is to get you to work unpaid overtime under the (mistaken) belief that more hours = more software.

Re: Why software projects take longer than you think – a statistical model

#154

Post by JustSomeNobody »

hnzix wrote: post #5

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

I close to double mine, but it also depends on the tasks. Some tasks I just know I'll complete in 1X my estimate. I do have a rule that nothing is ever estimated at less than 2 hours; no matter how small the task. Invariably, any time I have broken that rule, someone has checked in code that won't build (or something similar) and I have to spend time dealing with that.

I notice some devs like to underestimate to make them look more productive. Most of those tend to spend a lot of time fixing bugs that QA pushes back to them. They sometimes spend ever more time arguing that it's not their bug.

Re: Why software projects take longer than you think – a statistical model

#155

Post by markwkw »

usgroup wrote: post #34

TLDR anyone?

Thesis: Developers are good at estimating median time to finish tasks. But the tasks that take longer, in fact take much, much longer than estimated.

E.g. Dev estimates that time to complete each of A, B, C tasks will be 2 days. In reality, A will take 1 day, B will take 2 days, but C will take 8 days.

Dev was right about the median time to complete each task (2 days) but average was much higher. Article goes into how to statistically model the distribution of actual time to complete tasks.

Re: Why software projects take longer than you think – a statistical model

#157

Post by commandlinefan »

koonsolo wrote: post #53
undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

I once had a manager/CEO who thought you can negotiate the planning, the same as like a price. "The customer always wants to get it earlier, the engineer later". Me saying that only the developer is able to give a realistic planning, was probably received as "developer wants to push the deadline back in his negotiation". In the end, his company went bust because he was selling stuff to customers that could never be d…

In his mind there is one negotiable variable, though - how many hours you work. You want to work 40 hours/week, he figures if he can push you to work 80 hours instead, it'll get done twice as fast. The typical CEO's background as a schoolyard bully gives them plenty of experience in this area.

Re: Why software projects take longer than you think – a statistical model

#158

Post by commandlinefan »

afarrell wrote: post #61
koonsolo wrote: post #53

Earlier quoted context omitted.

I once had a manager/CEO who thought you can negotiate the planning, the same as like a price. "The customer always wants to get it earlier, the engineer later". Me saying that only the developer is able to give a realistic planning, was probably received as "developer wants to push the deadline back in his negotiation". In the end, his company went bust because he was selling stuff to customers that could never be d…

There is a type of negotiation that can be done: Negotiation about scope. Work doesn’t get compressed. But stakeholders can identify non-essential business-facing features and cut scope. Note well: Automated testing is almost certainly essential. If someone says you are “building an MVP”, then make sure it is an actual MVP. Make sure you have a clear market hypothesis to test and check that it couldn’t be built out o…

> Negotiation about scope.

I used to work for an online travel site - before every project kicked off, the business analysts would produce requirements documents that always started with a "flexibility matrix". The flexibility matrix had three rows labeled "schedule", "scope", and "resources" and three columns: "flexible", "moderately flexible" and "inflexible" and they were supposed to check one option for each row. So every single requirements document listed "resources" and "flexible", "scope" as "moderately flexible" and schedule, OF COURSE, "inflexible".

Post reply on HN