Live data from Hacker News

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

erikbern.com

221–230 of 324 posts

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

#221

> Instead, figure out which tasks have the highest uncertainty – those tasks are basically going to dominate the mean time to completion. From the technical side of things, uncertainty can mean a few things here: (A) I've never done this kind of task (or I don't remember or didn't write down how long this task took in the past) (B) I don't know how to leverage my historic experience (e.g., implementing an XYZWidget i…

> is entirely a position of inexperience

There are a lot of inexperienced software engineers and very little good guidance written for them. What is a new CS grad to do when asked for an estimate? How can a new grad learn to produce accurate estimates within 3 months?

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

#222
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 ho…

That was a really concise but faithful summary. Welcome to HN.

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

#223
post #185

Earlier quoted context omitted.

> You need to be willing to endure the discomfort of looking someone in the face, saying “I don’t know”, and then standing your ground when they pruessure you to lie to them. This. I have PMs who will ask me over and over until I give a number and I've learned to stand my ground. Because if I don't, I end up being responsible for the estimate I've given (as I should). Now I make it clear that I will not give a number…

To anyone else that doesn't know what WAG is, it's apparently "Wild Ass Guess".

I find that SWAG sounds better, and let's you add "Scientific" to the front of it.

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

#224
post #79

Earlier quoted context omitted.

> But when you advocate clearly for your needs as a professional, people are generally reasonable. This has not been my experience. People want ‘estimates’ at all costs, tell you to not worry about any accuracy, and then a week later tell your manager you committed to x date.

The biggest problem is that engineers tend to think in man-hours and managers think in calendar time. If I say a project will take 2 days, it'll probably take 2 days, but it might span 4 calendar days because other things are going on. The biggest thing that has helped me here is to keep a running list of my tasks, an informal Gantt chart, and show it to the manager whenever they ask me about an estimate. This helps…

There's a lot of bad to be said about how companies use story points and velocity and all the rest, but I do greatly appreciate the way they delink "amount of work" from "delivery date". It's a nice built-in way of expressing time requirements separately from schedule, which is a lot smoother than constantly reminding people that the difference exists.

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

#225

I've been one place that I thought was really good at software estimation. Their system was: Everything gets a T-shirt size. Roughly, "small" is no more than a couple person-days, "medium" is no more than a couple person-weeks, "large" is no more than a couple person-months. Anything beyond that, assume the schedule could be unbounded. Figure out how to carve those into a series of no-larger-than-large projects that…

> Everything gets a T-shirt size. Roughly, "small" is no more than a couple person-days, "medium" is no more than a couple person-weeks, "large" is no more than a couple person-months.

That's pretty much exactly what I've ended up using on past projects - a little more fine grained (start at a half day, went up to months), but that was my approach as well, and if I didn't know everything it went up a size.

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

#226

Wouldn't it be more sensible to give a range instead of a fixed date? I know it's not going to happen, but I think it would be more informative and honest. That way you could communicate better of how certain you are. There's a difference between telling something will be completed in, for example, 6 month +- 2 weeks. Or something will be finished in 6 months +- 1.5 months. The estimated time is the same but communic…

Never works. Management will just use your lowest estimate.

So you pad that and realize its the same as your high estimate, so you just give them that instead ... then they complain its too high ... rinse repeat. Unless you stand you ground.

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

#227

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…

> You need to be willing to endure the discomfort of looking someone in the face, saying “I don’t know”, and then standing your ground when they pruessure you to lie to them. This. I have PMs who will ask me over and over until I give a number and I've learned to stand my ground. Because if I don't, I end up being responsible for the estimate I've given (as I should). Now I make it clear that I will not give a number…

> until I give a number

One big insight for me, which you obviously put to use in your story, was learning to give a different number.

"I don't know" is understandably frustrating to people who are trying to plan work and answer requests. They often respond to that by pushing for a delivery date even when it won't be accurate, but a lot of the time what they fundamentally want is a numerical answer. "I'll have it scoped out by Tuesday", "I need at most 3 days to learn enough to estimate", and so on all aid that planning without committing to a project timeline. That rarely ends the conversation, just as it didn't in your example, but it does a lot to show good faith and justify not answering the initial question.

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

#228
post #185

Earlier quoted context omitted.

To anyone else that doesn't know what WAG is, it's apparently "Wild Ass Guess".

I find that SWAG sounds better, and let's you add "Scientific" to the front of it.

"Scientific Wild Ass Guess" sounds better? I think I'd just stick with "educated guess". I wouldn't even make an acronym out of it.

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

#229

Earlier quoted context omitted.

to avoid downvotes add sources.

Can you add sources to justify this statement?

I was trying to say, In my experience controversial comments are better received w/ sources to back the items.

At the time I made my comment the Parent comment had a negative score and I was trying to be helpful to commandlinefan .

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

#230
They don't take longer than I think. The problem is nobody listens! True story - They handed me an RFP, asked for an estimate. I gave it and they cut it in half and got the job. I didn't take any pleasure in being right, but I was right. It was an expensive mistake.
Post reply on HN