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

101–110 of 324 posts

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

#101

Post by bigiain »

moccachino wrote: post #73
chii wrote: post #48

Earlier quoted context omitted.

Imagine a tradie saying it'd take 1week to finish remodelling your kitchen, and then it turns out they couldn't. As a professional, it's your responsibility to educate the client on the issue - most technical problem could be explained to a layman if the context is set up properly. The problem occurs when the client doesn't want to hear it.

From around here that's everyone's experience of tradespeople in every non-emergency task. "Sure I can do this in 3 weeks." Then shows up once every two weeks and finishes around the four month mark.

I see exactly the same routine in our game.

"Yes we can do that in three weeks. We need the API documentation for _those_ two systems, network access to _those_ resources, and credentials to log in to _those_ services first."

2 months later we're still waiting on critical pieces of those prerequisites, while someone's screaming that the deadline they'd committed to with the customer was 5 weeks ago.

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

#102

Post by mgkimsal »

arethuza wrote: post #94
maxxxxx wrote: post #55

Earlier quoted context omitted.

I'm on a project right now and I am telling people "I don't know how long it will take because nobody here has ever done anything like this. The only thing I can tell you is that nobody is wasting time and we are solving problems as quickly as we can. Look at the JIRA board and see what we have done and what we are planning to do and make your own estimate". So far I haven't been fired. I also refuse to stop work and…

I once worked for CEO as a Director of Engineering who was convinced that any product feature could be implemented in 2 days - and this was a non-trivial engineering area. That was an entertaining job.

curious about this person's reaction to things not being implemented in 2 days. did he/she think that people were just dragging their feet? or not as smart? or sabotaging things to make him/her look bad?

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

#104

Post by nahname »

Aeolun wrote: post #79
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…

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

As long as software is a cost center to your company, it will be treated this way. Trying getting a job at a company where software is a core concern. Ideally with a CEO that is not from a marketing/business background.

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

#105

Post by bigiain »

XorNot wrote: post #13
hnzix wrote: post #5

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

Triple it. Then triple that if to do it you have to go across team boundaries.

One of my funny-not-funny jokes is "Double it then change up to the next unit of measure" So "I can do that in 3 minutes!" becomes 6 hours. 2 hours become 4 days. 3 days becomes 6 weeks. 2 weeks becomes 4 months...

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

#106

Post by circlefavshape »

cs02rm0 wrote: post #90
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 find you have to do this, but it can damage professional relationships. Recently I've flat out said no, as gently as I could, to doing some work - porting a software stack to run on Windows. A customer is asking for an estimate to do it, because a project manager who wouldn't be developing or supporting (or even using) the system likes Windows. The sales manager isn't thrilled with me over it. So he's asked the tea…

This drives me crazy!

Dev: "It's a really bad idea, will take an indeterminate amount of time, and be a maintenance nightmare" PM: "Can I just get an estimate?"

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

#107

Post by nocturnial »

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 communicates the level of certainty more clearly.

Or just use between, for example, 4-6 months if you don't want to use +- notation.

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

#108

Post by afarrell »

nahname wrote: post #104
Aeolun wrote: 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.

As long as software is a cost center to your company, it will be treated this way. Trying getting a job at a company where software is a core concern. Ideally with a CEO that is not from a marketing/business background.

For more on this sort if thing, Patrick McKenzie’s writing is good:

- https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

- https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea...

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

#110

Post by adrianmsmith »

cs02rm0 wrote: post #90
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 find you have to do this, but it can damage professional relationships. Recently I've flat out said no, as gently as I could, to doing some work - porting a software stack to run on Windows. A customer is asking for an estimate to do it, because a project manager who wouldn't be developing or supporting (or even using) the system likes Windows. The sales manager isn't thrilled with me over it. So he's asked the tea…

Ok cool but if they have to deliver it, they’ll look like fools in the long run when they can’t, and in the end they’ll see you’re right? So it’s a win for your reputation in the long term I think?
Post reply on HN