Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What do you mean ‘we need more time’? Project schedule estimation in software

blogs.dropbox.com

Post reply on HN
Print view View original

61–70 of 152 posts

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#61

Post by jahaja »

crpatino wrote: post #53
jahaja wrote: post #36

I may be cynical at this point but overeager project scheduling/estimation processes and top-down software processes in general are really where software development as a creative and experimental occupation dies.

If you can do "creative software development" and get paid for it, count your blessings. And better yet, give a very big "Thank you!" to your manager. The reality of this trade, regardless of you doing in-house work or a product for the market, is that everything is required for yesterday. There is an "economy of pressure" where every stakeholder pushes everyone else as much as they can in the expectation that they w…

So if I understand you correctly you're saying that "creative software development" is inherently incompatible with the hierarchical realities of the corporation?

If so, I think you're probably right.

"The reality of this trade [..] is that everything is required for yesterday"

But it just isn't. This is an artificially created pressure for selfish reasons, and should not just be accepted in passing.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#62

Post by [deleted] »

DougWebb wrote: post #55
a3n wrote: post #52

Earlier quoted context omitted.

How it's said: "There is a 50% chance that we get it done between six and seven months from now." How it's heard: "Wa wa wah, wa wa, we get it done between six and seven months from now."

You forgot the "assuming requirements don't change" part. What's actually heard would be "Wa wa wah (up to) six months from now (guaranteed) wa wa."

[deleted]

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#63

Post by sixothree »

dreamfactory2 wrote: post #29
melted wrote: post #4

Earlier quoted context omitted.

Underpromise and overdeliver — that's the secret to professional success.

and a rookie mistake in sales

Sales pressure is sometimes the primary reason when our estimates are under.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#64

Post by jameshart »

DougWebb wrote: post #57
jameshart wrote: post #48

Earlier quoted context omitted.

Customers don't need to know the cost, they need to know the price. The most important factor in determining that should be the value of the software to the customer, not the time it will take to produce it.

True, but difficult to sell, especially to repeat customers who can calculate the price/hr on previous work.

Let's say they figure out you only spent 100 hours to deliver them $50,000 of value. It's your job to persuade them that that guy on the internet who says they would sell them 100 hours of dev time for just $5,000 will only give them $5,000 of value (if that). If I have a choice between getting someone who delivers value at a rate of $500/hour versus someone who delivers value at $50/hour, and I need $50,000-worth of software, I should choose the more efficient developer, not the cheapest one.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#65

Post by mannykannot »

13hours wrote: post #7

Almost at the end : "Yes, all this sounds like a lot of work". Exactly. And it will most probably still turn out to be wrong, because you will forget to ask some questions, and there will be things that you simply cannot foresee that will influence the time. Turns out it's pointless to even try to do this. So why waste valuable time to do all this, if you know it's not the truth anyway? The answer is to accept that y…

I am not so sure there is a fundamental difference between what the article proposes and what you describe.

You start by saying this will not work, then in your description of what you do, there are many places where you estimate - or should I say guess? - what is feasible, and when.

The methods described in the article are analysis and extrapolation from experience, with an emphasis on identifying those areas that are most problematic due to some combination of uncertainty, importance and dependency, and giving them priority. You don't seem to be doing anything very different. Nowhere does the article say you have to schedule weeks or months on this.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#66

Post by lmm »

erikb wrote: post #45
cateye wrote: post #33

Analogies like "painting a room" are pretty useless because they are very misleading. Especially when it is an innovative product, a better analogy would be: "painting a room on Mars". With software development, there are a lot more "unknown attributes" that determine the main part of the effort estimation unless it is a repetitive task. So, a critical/skeptical engineer would always drive the customer nuts by asking…

Before NASA sent their first drone to Mars they made a lot of predictions, a lot of tests, guessed a lot of things that may get wrong, etc. Do some of their missions still fail? Sure. But the amount of success is much much larger because they didn't just sent a drone there and watched what happened. So even if all you say is correct it's still worth improving one's estimation skills.

> Before NASA sent their first drone to Mars they made a lot of predictions, a lot of tests, guessed a lot of things that may get wrong, etc. Do some of their missions still fail? Sure. But the amount of success is much much larger because they didn't just sent a drone there and watched what happened.

How much effort went into estimating Opportunity's lifetime at 90 days? How useful has that estimate proven to be?

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#67

Post by crpatino »

ams6110 wrote: post #43
Ensorceled wrote: post #16

Earlier quoted context omitted.

Agreed. As an engineer, I can also claim that if I say "we can deliver that March 15th", then I get a argument about why can't it go out with the Feb 28th release and why is it going to take 30 days to do something simple and why ... all because marketing people can't understand delivery cycles. So, let's just not have that type of conversation at all.

Ever talk to a contractor about a home renovation, or even a painter as in this story? If you start questioning why something will take so long, in my experience the usual answer is something like "if you think you know better than me, do it yourself." Especially if they are good at what they do. Most good tradespeople have more work than they can do, and will just walk if they think a customer is going to be a pain…

Well tradespeople usually work for multiple clients on smallish projects. For good tradespeople, a significant number of those projects come from repeat customers, which means their optimal strategy is not to serve all customers equally, but to prioritize those that are more likely to bring repeat business down the road. A difficult customer is usually not someone you want to do repeat business with, so they get "managed out" pretty reliably.

Most software engineers, on the other hand, work for one big customer at a time (your employer). And though I agree that a bad employer at the end of day is detrimental to your career, you cannot afford to switch jobs on trivial matters, on risk of getting labeled as a grasshopper. That's why you do not see developers "walking".

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#68

Post by jsprogrammer »

Kurtz79 wrote: post #39
13hours wrote: post #7

Almost at the end : "Yes, all this sounds like a lot of work". Exactly. And it will most probably still turn out to be wrong, because you will forget to ask some questions, and there will be things that you simply cannot foresee that will influence the time. Turns out it's pointless to even try to do this. So why waste valuable time to do all this, if you know it's not the truth anyway? The answer is to accept that y…

"So why waste valuable time to do all this, if you know it's not the truth anyway ? The answer is to accept that you will learn things as you go along, and that things take as long as they take, and to rather deal with that." This maybe is applicable for a company developing new products internally, but for projects delivered to third parties, delivery dates are part of contractual obligations. Estimates are hard, bu…

Don't put hard commitments into the contracts then. Why slave yourself to something that you aren't sure you can deliver?

Good developers should ideally only ever do the same thing once, which means that there is very limited utility in trying to improve estimates for a task that you should never perform again.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#69

Post by beat »

The tendency to estimate poorly - particularly to underestimate - is one of the key reasons to use a very tight, short-iteration agile process.

If I estimate something will take two days, and I'm off by 50%, it'll take three days. If I estimate it'll take two years, and I'm off by 50%, it'll take three years. And because I can get a lot more practice at two day schedules than two year schedules, I'll improve my accuracy over time, through steady practice.

This takes us back to the triangle of constraints that Kent Beck talked about in the first Extreme Programming book. There are three constraints on projects - schedule, scope, and resources. You can control two of them. Generally, resources are inflexible. So in practice, projects are either schedule-bound (we must hit this date) or scope-bound (we must have these features). A project that tries to do both, without a significant resource surplus, is probably doomed.

Since estimation improves over time with short iterations, it seems better to me to be scope-constrained than schedule-constrained. With steady progress, you can achieve the goals eventually. Good agile processes are much better at saying where you are and where you're going than when you'll get there.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#70

Post by TheLogothete »

lmm wrote: post #66
erikb wrote: post #45

Earlier quoted context omitted.

Before NASA sent their first drone to Mars they made a lot of predictions, a lot of tests, guessed a lot of things that may get wrong, etc. Do some of their missions still fail? Sure. But the amount of success is much much larger because they didn't just sent a drone there and watched what happened. So even if all you say is correct it's still worth improving one's estimation skills.

> Before NASA sent their first drone to Mars they made a lot of predictions, a lot of tests, guessed a lot of things that may get wrong, etc. Do some of their missions still fail? Sure. But the amount of success is much much larger because they didn't just sent a drone there and watched what happened. How much effort went into estimating Opportunity's lifetime at 90 days? How useful has that estimate proven to be?

That is cherry picking. Did you try to comprehend the post you are replying to? Take into account all of the estimations, not just one failed estimation.
Post reply on HN