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

11–20 of 152 posts

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

#11

Post by anon4 »

> The fact that I technically only asked how long the fix would take is something only an engineer would bother pointing out. -_-

Well excuse me for not fitting your prejudiced profile for a neurotypical extroverted 20-something white male. Yes, I might have needed the clarification between "how long will it take you to paint the room" vs "how long until the room is back the way it was with the walls in a different colour", but you help noone when you talk down to the painter like that. You asked a question and I misunderstood, because we use slightly different language and I have a ton of other things to think about all the time.

Can we stop this "oh let's treat engineers like they're children with mental development issues" already? I'm not some god in an ivory tower, I don't want you to kneel before me, I just want the usual everyday respect you afford to your peers and to engage with me as one professional with another.

This kind of treatment is not ok.

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

#12

Post by Ensorceled »

pjc50 wrote: post #3
bluesign wrote: post #2

I think also one of the biggest mistakes is making over estimates, or playing too safe. Especially when working with big teams and multiple projects (with a lot of dependencies).

Why - has that led to a spate of projects completed early?

It leads to what I call "do it right syndrome".

Since I have time, I'll do it right, with a factory class, and extendible configuration package (that I'll write myself so it will be just perfect) and, for optimal speed, I'll use Red-Black trees that I'll have to write my own implementation of since there isn't a standard library ...

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

#13

Post by 13hours »

Ensorceled wrote: post #10
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…

It's better than this actually. If they want a release by Christmas I can with, high certainty, tell them: Features will be in: A, B, C Features likely to make it in: D, E Features unlikely to make it in: F, G Nope: H, I, J Hell No: K, L, ..., ZZZ The problem I've always found is that, no matter what, you are going to be arguing with sales and management about E, F and L instead of them just working with A, B, and C.

Ask them to give you a guaranteed schedule of sales that you will hold them to. They'll say it's absurd, you can't predict that. Turns out it's the same with software dev.

If you find yourself arguing about this with management or sales, they're not trusting you to be the expert at what you do. Tell them that.

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

#14

Post by eterm »

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…

But there's a difference between "production ready" and "customer ready" which Agile practitioners sometimes seem to forget.

In many businesses, software is not the core business, you're not building software for yourself, you're building it for other stakeholders. It's not acceptable to say "Well it only does 20% of what you wanted".

What happens when things start to slip, so in fact you won't have something the business thinks it can present at christmas? "Don't worry, we'll just keep working on it until it's ready" after having spent 6 months on it isn't good enough.

It's not a bad thing to do a lot of estimating up front so the business can make an informed decision about whether it really wants to commit to the effort, rather than finding out during all the sprints about the growing effort required to get it to where the customer or internal stakeholder is happy.

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

#15

Post by 13hours »

soft_dev_person wrote: post #9
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…

Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...

I used to as well, until I started to refuse to do it. It truly is in the best interest of the customer to work this way, and I explain it to them. The ones that understand it and buy into this way of working are the ones I work with.

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

#16

Post by Ensorceled »

anon4 wrote: post #11

> The fact that I technically only asked how long the fix would take is something only an engineer would bother pointing out. -_- Well excuse me for not fitting your prejudiced profile for a neurotypical extroverted 20-something white male. Yes, I might have needed the clarification between "how long will it take you to paint the room" vs "how long until the room is back the way it was with the walls in a different c…

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.

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

#17

Post by eterm »

soft_dev_person wrote: post #9
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…

Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...

Absolutely this, clients need to know their costs upfront.

Meanwhile, I've been on the other side, working with a shop that insisted they were agile, and so refused to give an upfront cost.

That project ended up delivering a substandard project where key parts did not work well. Their answer was to tell us they would of course be happy to be paid for another 2 week sprint to fix those bugs...

As a customer it wasn't very satisfying.

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

#18

Post by soft_dev_person »

13hours wrote: post #15
soft_dev_person wrote: post #9

Earlier quoted context omitted.

Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...

I used to as well, until I started to refuse to do it. It truly is in the best interest of the customer to work this way, and I explain it to them. The ones that understand it and buy into this way of working are the ones I work with.

Sounds awesome. Unfortunately I don't work in my own company. Fortunately, I don't work with sales (much).

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

#19

Post by Ensorceled »

Theodores wrote: post #8

The thing that annoys me most about project estimation is when the micro-managing types don't let you even look at the problem space first, an instant answer is expected. Of course the figure plucked out the air could be 'x days' with 'x' being greater than the time one expects internally so backside is covered, yet that is not really a true answer. At the moment I am putting together a 'simple' feature on a website,…

Actually, the metaphor is pretty good, except they missed a key change: in real life if the "test painting" shows you need to "prime first" you now have no idea how long it will take without starting the estimation process all over again.

So, in real life, paint the room is "2 days or, if the test painting goes badly on day one, I'm not sure and won't know until the end of day 1". And people don't like those kinds of estimates.

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

#20

Post by 13hours »

eterm wrote: post #17
soft_dev_person wrote: post #9

Earlier quoted context omitted.

Except some of us make a living selling development of projects and solutions to customers that require pretty accurate (cost) estimates prior to even getting the contract. Crazy world, I know...

Absolutely this, clients need to know their costs upfront. Meanwhile, I've been on the other side, working with a shop that insisted they were agile, and so refused to give an upfront cost. That project ended up delivering a substandard project where key parts did not work well. Their answer was to tell us they would of course be happy to be paid for another 2 week sprint to fix those bugs... As a customer it wasn't…

I don't think working fixed price quote would have given you a different outcome though? The team produced bad quality product, fixed cost or agile won't change that.

Selecting the team to build the product on price is often a bad idea, and that's all fixed cost gives you above agile (the ability to select on price).

Post reply on HN