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

191–200 of 324 posts

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

#191

Post by VBprogrammer »

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.

Ha. That sounds like my last job except s/2 days/3 hours/.

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

#192

Post by stronglikedan »

hnzix wrote: post #5

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

If that 20% isn't for project management, then add another 10-20% for that, based on experience from previous projects for the same stakeholders. My similar rule of thumb is to multiply my estimate by 2.5, before adding the project management percentage. Of course, if it's something we've done before, it's more along the lines of 1.5 to 2.

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

#193

Post by jerf »

commandlinefan wrote: post #158
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…

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

You sound like you're complaining, but your complaint may be incomplete. If those bullet points were honored, that is indeed how pretty much every organization doing development will operate, whether it likes it or not. That is not intrinsically a problem.

I take it these requirements documents were not honored by your non-developers? A document labeling scope as "moderately inflexible" does little if it's treated as written in stone.

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

#194

Post by maltalex »

SilasX wrote: post #186
maltalex wrote: post #182

Earlier quoted context omitted.

I disagree. Estimations tend to be just as wrong even when the tools are well known. There's always that one edge case you haven't considered, that one algorithm that doesn't work as well as you expected, that small change to the requirements the requires a completely different approach.

"Just as" wrong? I don't know what to point to to resolve disagreement here since it's just anecdotal, but if you're just using the same feature you've used hundreds of times before, there is nowhere near the potential for yak-shaving snags.

Okay, sure. Not "just as" wrong since a certain class of pitfalls are eliminated by deep knowledge of your tools.

But I'd argue that that's not where the bulk of the uncertainty comes from. I think that in the software industry as a whole, most of the problems are solved by people with at least a decent understanding of their tools, and estimates still suck.

The problems is that the tasks we deal with are always new, unsolved problems. That's the nature of software. Unsolved problems come with uncertainty. That's the nature of unsolved problems.

Carpenters on the other hand deal mostly with solved problems. They just need to execute.

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

#195

Post by duxup »

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…

Also clear communication (although you are pretty much describing that too).

I had a friend who had an unusually high frequency of conflicts with various management, project managers (I expect there are always some, but this guy had a lot of bad experiences).

He showed me an instant message conversation:

PM: "Is X done?"

Dude: "Yes, but a, b, c is not done"

A, b, and c were parts of X's requirements.

Now the project manager or such should have been able to read between the lines, but man don't lead with "Yes" and actually describe a situation that is "No".

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

#197

Post by maerF0x0 »

commandlinefan wrote: post #153
koonsolo wrote: post #59

Earlier quoted context omitted.

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

to avoid downvotes add sources.

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

#198

Post by dboreham »

jermaustin1 wrote: post #179

In my experience software takes longer to build than original estimates because no one will get out of the way of the development team and let them work. This is an extreme example, but one I now live in daily. My current full-time-ish gig is working on a pretty enterprisy system for law enforcement. To this date there hasn't been a single feature request, or bug fix that took more than 16 hours of development time.…

I find it useful to point out in situations like this that we have already spent more time discussing the issue, or often "how not do to the thing" than it would take to simply do it.

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

#199

Post by dboreham »

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…

It's important to realize that the workplace often involves being subjected to what is really a kind of psychological abuse. It is not, I think, a coincidence that we are learning that many "stellar managers" turn out to be abusers, e.g. guilty of sexual harassment. What you're describing is in psychological terms thought of as "maintaining boundaries" against a person who is intent on transgressing those boundaries for their own gain or amusement.

If you validate the invalid assertions of these abusers (e.g. that some unclear task can be estimated with certainty) then you're enabling the abuse.

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

#200

Post by panarky »

artworx wrote: post #150
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 highly recommend the book "Software Estimation: Demystifying the Black Art". I work for an outsourcing company and part of my job is to come up with estimates and it helped me deal with clients and managers. The book contains a quiz that we used as part of a training exercise with management and the results were hilarious. Here is an online copy: https://scrumandkanban.co.uk/how-accurate-are-your-estimates... pleas…

That quiz has an unintentionally apt question.

> Total length of the coastline of the Pacific Ocean

Coastlines are fractal. If your measuring stick is 1 km long, you'll get one number. If it's 1 m long, you'll get a much larger result. And if it's 1 cm long, you'll get an even larger result.

https://en.wikipedia.org/wiki/Coastline_paradox

The actual length of a coastline is infinite when measured with an infinitesimally small measuring stick.

Software development effort also increases, unbounded, as discovery proceeds and the precision of requirements increases.

Post reply on HN