http://qr.ae/ROlwZp - I've found this answer on quora to be one of the best explanations as to why software estimates are so off.
What do you mean ‘we need more time’? Project schedule estimation in software
31–40 of 152 posts
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#32Almost 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 bus…
> 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...
You're assuming the estimate is worth much. Which is what much of the industry is doubtful about. To underscore the point, most estimates are single values (eight months), not confidence intervals.
A better answer would be, "There is a 50% chance that we get it done between six and seven months from now, assuming requirements don't change."
...but even that assumes that all along the way, the project stakeholders are keeping in mind how many (how do you quantify?) requirements were added and discovered.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#33Analogies 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 questions nobody can know and the conclusion will end somewhere like it is not possible to give a upfront estimation and stop the project. Or the effort to give the estimation approaches the effort to develop.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#34Almost 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...
> ...customers that require pretty accurate (cost) estimates prior to even getting the contract.
If you require that accurate of an estimate, your business model cannot handle the risk of software development. Really, really wanting an accurate estimate does not make risk go away.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#35The 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,…
> don't let you even look at the problem space first this is the core of the issue. when one has the time to break down all unknowns and discover them, estimate are quite spot on. but who want to pay for the estimate? so we are left trying to guess what time a particular unknown is going to take to solve. the good metaphor here is asking how much time it will take to solve a puzzle magazine, from cover to cover by lo…
The point you're making is exemplified in this article which makes an analogy to a hike from San Francisco to Los Angeles:
http://www.michaelrwolfe.com/2013/10/19/50/
from
https://www.quora.com/Why-are-software-development-task-esti...
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#36I 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.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#37In tech, we spend little time talking about the softer skills like communication, project management, and prioritization.
Well, that's not a good start. Maybe my career has been abnormal, but I've spent a lot of time thinking and talking about project management skills, particularly estimation. It's something my employer expects all non-junior employees to do - more than half my team are certified in scrum or have taken courses in other PM methodologies.
For most of what we do, the hard part is project management. Sure, the techie code stuff is usually more fun, but that's not even half of my daily workload (and hasn't been since well before my title changed from "product architect" to "project manager").
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#38Earlier 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...
> ...customers that require pretty accurate (cost) estimates prior to even getting the contract. If you require that accurate of an estimate, your business model cannot handle the risk of software development. Really, really wanting an accurate estimate does not make risk go away.
That's not exactly true, but it means holding the customer to exactly what they asked for, and having a formal "change request" process for any deviations. The track record of that model of development is not one of successful on-time delivery, but it does seem to make some types of customers more comfortable, even if it shouldn't.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#39Almost 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, but it's not like predicting the future with a crystal ball. Good developers in general get better as they gain experience in the domain, and in estimating itself.
Good project managers in general get better at spotting murky requirements that might be causing problems down the line, and try to clarify them early with the customer.
It's not a perfect science either, but it's a necessity in many real-world scenarios.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#40Earlier 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...
> ...customers that require pretty accurate (cost) estimates prior to even getting the contract. If you require that accurate of an estimate, your business model cannot handle the risk of software development. Really, really wanting an accurate estimate does not make risk go away.
Estimates can be fairly accurate if they're made for software that's a composition of previously iterated work.
If someone asks for a login system with X,Y,Z and you've done that 1000 times, you can be fairly accurate in stating what it will take to do it 1001 times.
The issue is when a piece of software is custom, and there's no domain expertise available for the custom bit then you cannot accurate estimate how long it will take because the developers will be learning while doing.