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

111–120 of 324 posts

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

#111

Post by afarrell »

mgkimsal wrote: post #100
afarrell wrote: post #61

Earlier quoted context omitted.

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…

Testing will happen. The choice you make is who does the testing and when it happens. Internal people testing earlier is generally preferable to external customers testing 'live', but either way, the testing will happen.

“We can’t make those UX improvements to our core open-source product because then we’s have to introduce untested code. The current code is tested because users have used it and reported the bugs and we’ve fixed them.” Is a real thing a project lead said to me at a previous employer.

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

#112

Post by arsenico »

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.

True, but you should always put up estimated effort and real spent time in the task, whichever bug tracker, or issue tracker you're using. I don't know of any other way to improve the estimation "skills".

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

#113

Post by arethuza »

mgkimsal wrote: post #102
arethuza wrote: post #94

Earlier quoted context omitted.

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?

He just edited it out from his version of reality! In fact, in all the time I was there (roughly a year including a major new product launch) I don't think anything was ever done in 2 days.

Another interesting characteristic he had was to get upset if he thought projects were running too smoothly...

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

#114

Post by basetop »

The mythical man month ( required reading for most CS programs ) goes into a historical and production aspect of why software projects take longer than what you think and what you expected.

Also, there is a law named after author called the Brooks's law : "adding human resources to a late software project makes it later"

https://en.wikipedia.org/wiki/Brooks's_law

In most industries, if you are running behind schedule, you throw more workers at the problem to catch up. For example, laying railroad tracks, digging ditches, deliverying packages, harvesting crops, etc. By adding more workers, you shorten the time it takes to complete the project. But which software engineering, the reverse tends to happen. If you are falling behind, just throwing more developers at the problem worsens the problem. Most likely because you need the new developers to get "caught up" with the code/project/tools but if you rush that process, then they won't have a full understanding of the project/code/tools and introduce bugs/problems themselves which exacerbates the problem.

It's a fun read if you have the time.

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

#115

Post by marcosdumay »

adrianmsmith wrote: post #110
cs02rm0 wrote: post #90

Earlier quoted context omitted.

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?

That's naive.

Nobody will revisit the GP's reputation, and after the novice devs fail to do the work people will just scatter into different projects. They may or may not take a reputation hit, while the PM that insists so much on doing the not viable work will take none of it.

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

#116

Post by temp269601 »

How about making the manager estimate the project, that way if the deadline is not met, the manager receives the blame? It's the manager's job to manage resources, and if the deadline is not hit, then they can hire/bring on more resources. If an engineer works as hard as they can for 40 hours a week, why is it the engineer's fault if the arbitrary deadline is not met? If the engineer estimate's time for a project, the engineer will always have to work more than 40 hours a week because some estimates will be too optimistic.

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

#117

Post by werbel »

adrianmsmith wrote: post #110
cs02rm0 wrote: post #90

Earlier quoted context omitted.

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?

My guess is no one will look back and say "Huh, he was right".

The only thing that probably is going to happen is "Huh, why isn't that delivered?" and then they will look everywhere but on the fact that it was, at least partially, just a stupid idea in the first place.

Of course I don't know the exact situation so it's more of a thought on what happens in general in the industry.

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

#118

Post by kirRoyale »

afarrell wrote: post #108
nahname wrote: post #104

Earlier quoted context omitted.

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

You are right, great posts. Thanks for sharing.

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

#120

Post by jcon321 »

temp269601 wrote: post #116

How about making the manager estimate the project, that way if the deadline is not met, the manager receives the blame? It's the manager's job to manage resources, and if the deadline is not hit, then they can hire/bring on more resources. If an engineer works as hard as they can for 40 hours a week, why is it the engineer's fault if the arbitrary deadline is not met? If the engineer estimate's time for a project, th…

Maybe if your PM has any technical experience
Post reply on HN