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

301–310 of 324 posts

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

#301

Post by gizmo686 »

polygotdomain wrote: post #214
panarky wrote: post #200

Earlier quoted context omitted.

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

>The actual length of a coastline is infinite when measured with an infinitesimally small measuring stick. >In actuality, the concept of an infinite fractal is not applicable to a coastline; as progressively more accurate measurement devices are used The notion of the length of the coastline, and why I think the question is apt as well, is that regardless of the fractal paradox, the practical answer is that there is…

The practical answer is that the question is ill posed, and you need to clarify what is actually being asked. A reasonable way to answer the question as asked would be to model the coastline as a fractal, which would give you an estimated length of infinity. What is needed is not a better way of estimating the answer to the question as asked, because the answer to that question is not useful. Instead, what is needed is a better question (which would require knowledge of why the question is being asked).

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

#302

Post by js8 »

jfoutz wrote: post #71
js8 wrote: post #54

Earlier quoted context omitted.

You could have also used approximately logarithmic scale that everybody is familiar with, namely, cash! You know, 1,2,5,10,20,50,100,200,500.. But no, here we are doing science, that's why we use Fibonacci, hey even plants and rabbits are using it.

I kinda want to grab you by the lapels and re-enact that part from Clear and Present Danger. It doesn't matter what's true, it matters what i can prove! Unfortunately, the phrasing would be more like, It doesn't matter what's true, it matters what i can sell to management. In the absence of evidence to the contrary, i think i'm ready to take a side close to yours. It's useful to expand error bars exponentially as you…

> Unfortunately, the phrasing would be more like, It doesn't matter what's true, it matters what i can sell to management.

Yes, that's my main beef with it. SCRUM could be based on science, but sadly, it isn't. Here's an interesting book: https://www.amazon.com/Making-Software-Really-Works-Believe/...

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

#303

Post by afarrell »

afarrell wrote: post #277
SkyBelow wrote: post #254

Earlier quoted context omitted.

>Asking questions is OK. Is it? Questions have built in assumptions and implications. Most questions don't have enough to be of concern, but some questions definitely imply things beyond the question itself. When asked 'Does it all take that long?', many hear an implied 'Make it not take so long.' command. It is not implied all the time, but it is implied often enough. This does not mean someone has low self-confiden…

If you hear a 'Make it not take so long.' command, thats not an unreasonable interpretation. However, it is also one that should be questioned because it clashes with how software projects work. If you go from "my boss gave me a command" to "I must execute the command and not question it" without exercising independent judgement, then I would assert that you do have low self-confidence. Whether someone needs therapy…

> reluctance to trust my own judgement

I should make explicit: Part of trusting ones own judgement is also being willing to say, “I don’t have enough knowledge/experience to make a trustworthy judgement here.”

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

#304

Post by koonsolo »

squarecog wrote: post #280
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:…

Can you explain which part, in your opinion, is facepalm worthy? In your example conversation, the developer starts off by demonstrating that they are not good at thinking through how long things take them, by giving an impossibly optimistic estimate. Even the PM, whose job is not to figure out how to build stuff or how long building stuff takes, knows the estimate is wrong, and pushes back on it, pointing out depend…

I'm facepalming at both of them:

1. The PM just wanted it done by Friday, because the customer wanted it by Monday. This was clear at the end of the conversation, not at the beginning. So it just could have been a "Can you get this done by Friday? Because the customer wants to use it on Monday"

2. The developer clearly had no backbone, and was just throwing numbers to see what the project manager would like. 1 day? Too short! 5 days? Too long! 3? Perfect! Estimates might be a guessing game, but not a guessing game on how long the PM thinks it should take.

So yeah, facepalm to both of them, and the whole situation. But I must say that they were definitely not incompetent people. The PM was one of the best I worked with, and the dev was a smart passionate coder. It was just that situation that was a bit absurd.

Proper way on how to do this:

PM: Can you give me a deadline (not estimate!) on when you can finish X? The customer needs this ASAP, so it has priority over your other tasks.

DEV: Let me look into it and I'll let you know in half an hour. (Works out estimate, possibly asking input, adds a buffer because deadline != estimate, looks into his own schedule of meetings etc).

DEV: I can get it ready by Tuesday.

PM: I'll notify the customer.

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

#305

Post by kthejoker2 »

maerF0x0 wrote: post #197
commandlinefan wrote: post #153

Earlier quoted context omitted.

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.

#1 source of employee stress is deadlines.

https://www.shrm.org/resourcesandtools/hr-topics/employee-re...

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

#306

Post by kthejoker2 »

jolmg wrote: post #268
SketchySeaBeast wrote: post #238

Earlier quoted context omitted.

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

> I got very little idea, but you really want a number, so here's a number Where does the "Scientific" come in? Because I really thought it implied having a good idea, which made SWAG seem like an oxymoron.

If your guess is a mathematical formula with assumptions for the inputs, those assumptions can be tested and the formula refined ... It's a SWAG.

You use things like Average/95/99, t shirt sizing, how much work can be done in parallel, 3rd party/client dependencies, ramp up time for a new library ... it's still a wild assed guess but at least there's some basis in reality and you can defend your estimate - show me what I'm wrong about or missing and I'll revise my formula.

Negotiating over the assumptions and inputs is 90% of the battle anyway. Without a model you're standing on sand.

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

#307

Post by kthejoker2 »

danmaz74 wrote: post #123
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…

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.

Jerry Weinberg had the Orange Juice test which always struck me as a practical approach to all requests.

https://medium.com/intercom-inside/the-orange-juice-test-c90...

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

#308

Post by kthejoker2 »

circlefavshape wrote: post #106
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…

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?"

I'm a big believer in pushing back on small words doing heavy lifting. "Just" is a big red flag in software delivery.

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

#309

Post by kthejoker2 »

thatoneuser wrote: post #287
hannasanarion wrote: post #138

Earlier quoted context omitted.

Wouldn't it be 240%?

No he said double or (200) then add 20 (220). Unless there's ambiguity I'm not seeing.

Add 20% of the doubled estimate (eg .2 * 200%=40%) surely?

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

#310

Post by Chris2048 »

Gibbon1 wrote: post #232
Chris2048 wrote: post #217

Earlier quoted context omitted.

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

If you are "negotiating a business relationship" you aren't necessarily haggling on price, but service. This is why I mentioned "the same product"
Post reply on HN