Why software projects take longer than you think – a statistical model • Hacker News Board

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

#231

Post by piccolbo » Tue, Apr 16, 2019, 6:11 PM UTC

mikekchar wrote: post #42

The interesting thing is that by the central limit theorem, the mean of a mean is normally distributed. This is extremely helpful. Here's what I suggest you do: Same size your stories to small values. Do 30 stories in a sprint and take the mean. Do 30 sprints and take the mean of the sprint. What you get is the mean amount of time to do a sprint of 30 stories. What's amazing is that this estimate will be normally dis…

The central limit theorem is in the limit for the number of variables in the sum approaching infinity. In the finite world, the article explains how it's done. The article is saying, the sum of lognormals is not normal. You are saying: take enough of them and it is normal. The article is still more accurate than your reasoning for 30 stories. From the wikipedia entry for Central limit theorem " As an approximation for a finite number of observations, it provides a reasonable approximation only when close to the peak of the normal distribution; it requires a very large number of observations to stretch into the tails". To prduce a 95% confidence intervals, you have to upper-bound the tails. All methodologies that are based on sum of subtasks estimates are not evidence based. But we knew already sw methodologies are not evidence-based, did we?

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

#232

Post by Gibbon1 » Tue, Apr 16, 2019, 6:20 PM UTC

Chris2048 wrote: post #217

parasubvert wrote: post #207

Earlier quoted context omitted.

Price negotiation is not zero sum. Zero sum means one party’s gain is exactly equal to the other party’s loss. Most deals are positive sum - both parties get benefits. Price negotiation is about the seller getting some the upside of the buyer’s benefits but not so much that it sucks for the buyer and not so low a price that the seller will walk. Some deals are inherently negative sum - if you bought a lemon.

If I pay a dollar more for the same thing, I, the buyer, lose a dollar, and the seller gains a dollar. Can you explain how that's not zero-sum?

If one thing if you are haggling over a used toaster at a yard sale. It's another when you are negotiating a business relationship where the success of both parties is important. A contract with a supplier doesn't do you any good if the terms are so bad it cripples their ability to execute.

That highlights a beef I have with economics. Failure to understand that business relationships are exactly that. You can't model them using the sorts of time invariant non-network models they use.

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

#233

Post by Bartweiss » Tue, Apr 16, 2019, 6:20 PM UTC

jerf wrote: post #193

commandlinefan wrote: post #158

Earlier quoted context omitted.

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

One basis for complaint that stands out to me is framing "flexible resources" as a full degree of freedom.

The first question is of course whether that's true, since resources don't tend to flex up unless someone outside the project dictates it. But even if it's accurate, it tends to produce the situation The Mythical Man-Month was written to condemn. If the ship date can't move and the scope won't bend on core features, there's a very real risk of finding that extra resources can't fix the timeline problems.

You're right that most organizations have to operate this way, and it's not inherently bad; I've just found that "flexible resources" is often used as a way to avoid admitting that the real third category is "risk of failure".

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

#234

Post by cs02rm0 » Tue, Apr 16, 2019, 6:22 PM UTC

ddalex wrote: post #147

danmaz74 wrote: post #123

Earlier quoted context omitted.

An alternative to flat out saying no is to point out how expensive and risky what you've been asked would be, in terms of development time, maintenance, and other metrics that the business cares about. Even very rough estimates with a list of risks will usually do. If somebody else comes out with a much lower estimate, ask them what they think about risk A, B, C... if you've got a point, this will usually work.

That's a bingo! It's never No! It's "Sure, this is what it entails and this is how much it costs". Especially if you're a contractor. If their willing to pay the price, why not take the money and do the work?

Mostly, I'd agree.

I have literally no idea how long it would take though, I couldn't in good faith put a number to it.

I also don't want the work - Windows isn't an environment I have experience in because it's an environment I don't want experience in. They wouldn't allow a rate change to do the work.

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

#235

Post by Bartweiss » Tue, Apr 16, 2019, 6:24 PM UTC

philk10 wrote: post #163

afarrell wrote: post #111

Earlier quoted context omitted.

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

"Or customers are better at finding the bugs than we are so just give it a quick look over and ship it" - genuine quote from CEO at a company I soon left

Honestly, I'm surprised more companies don't formalize this. There are places that offer customers discounts or feature-request priority in return for being beta testers, which seems like a major improvement in both integrity and efficient feedback.

I suppose it's both slower and more expensive than "just ship bad code at full price and wait", but I'd still expect more companies to choose it as the intermediate option between that and comprehensive in-house testing.

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

#236

Post by SamuelAdams » Tue, Apr 16, 2019, 6:27 PM UTC

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

Thanks for the links! I really wish I read these when I was in my undergrad, they are really good!

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

#237

Post by _ea1k » Tue, Apr 16, 2019, 6:28 PM UTC

jshowa3 wrote: post #132

golergka wrote: post #86

Earlier quoted context omitted.

> Does it all take that long? That's just a question. Asking questions is OK. If you have such a high need to please other people and such a low self-confidence that you will change your answer simply if someone asks you twice, that's the problem with you, not them. I say it as someone who have been like that and have changed it through therapy. I was a nervous mess and always thought that people around me don't like…

It actually is a problem with them because when someone asks "Does it really take that long?", they're implying that it shouldn't. Of course, in reality, they have no idea either and if they're asking you how long it should take, they should accept your answer, not try to weasel out less time. But are they ever going to admit that they have no idea and accept your estimate on face without playing BS mind games? Proba…

> I've never seen someone try and do this with a home contractor.

I'm surprised that you haven't. I've certainly seen the same kind of thing happen, though admittedly it is usually based on cost rather than time. Ultimately, though, the discussion was the client disbelieving a high effort estimate.

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

#238

Post by SketchySeaBeast » Tue, Apr 16, 2019, 6:29 PM UTC

jolmg wrote: post #228

SketchySeaBeast wrote: post #223

Earlier quoted context omitted.

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.

"SWAG" sets the expectations much better than "educated guess"- you're saying "I got very little idea, but you really want a number, so here's a number". "Educated guess" sounds much more like you've got a good idea, which using the term "SWAG" is trying to avoid.

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

#239

Post by kansface » Tue, Apr 16, 2019, 6:29 PM UTC

wellpast wrote: post #190

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

> This whole you-can't-estimate-software accuracy position is entirely a position of inexperience.

There are other sources of uncertainty. NASA is probably the only organization that fully specifies product requirements before building stuff - often, even the customer doesn't know. Some problem domains preclude you from knowing in advance! When building the thing, complete understanding of the existing code, frameworks, libraries, and infrastructure is not possible. All of these abstractions eventually leak and break down at scale. Every one of these parts is also continually changing! Even if you could solve all of those problems, you'd still have to deal with people problems - incentives never align, budgets change, and alliances shift.

I don't have a formal proof, but I'm strongly suspicious that the only actual way to know how long something takes to build is to actually build it, which of course, may be impossible.

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

#240

Post by DesiLurker » Tue, Apr 16, 2019, 6:31 PM UTC

taherchhabra wrote: post #168

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…

once my CEO asked: "can we add more developers and finish the project faster". I used this famous quote "9 mothers cannot deliver a baby in one month" and we had a big laugh

My somewhat more nunanced retort to such kind is that it depends how much of this work is linear and how much non-linear and how are they naturally occurring. non-linear work may mean things like understanding a complex codebase or developing an algorithm. these dont speedup by adding more people ( what I dont say is these may speedup by adding more quality/unfragmented hours to the individuals doing it). However stuff like refactoring codebase or minor bugfixes may benefit by adding more engineers.

Unfortunately, the problem then becomes defending whatever timeline you have in mind for non-linear work. also doing too much of this can give bully managers an opportunity to nitpick and micromanage the whole thing.