As long as sales, or its local equivalent, commits to as yet non-existing products and features, it will ever be thus.
What do you mean ‘we need more time’? Project schedule estimation in software
51–60 of 152 posts
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#52Earlier quoted context omitted.
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…
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."
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#53I 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 will be pushed as well. If you do not get to experience this, it means someone in your chain of command is very good at pushing others, and that some other part of the overall system is shouldering most of that pressure all by themselves.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#54The 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…
If that's the case, you assume priming will be needed in your original estimation, then go do the test anyways, and at the end of day one you will look like a hero when you say "hey guys, I think we can get away with cutting priming from the plan, we just saved $abc from the budget and xyz days".
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#55Earlier quoted context omitted.
> 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…
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."
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#56As a new grad who has worked a couple different jobs now, some things I don't get about this: - What do you do when you don't have a spec and when you ask the senior engineer you are working with questions, they don't respond or push back against having a spec or a plan longer than the very next feature? - The author says that estimation is easier to do if you are doing something you have done before. What do you do…
It comes down to experience really. The more you are exposed to, if you are paying attention, the easier it becomes to relate to previous events, which can help inform estimates.
If you don't have a spec, get a spec. A Senior engineer may be more reluctant to help you with implementation direction without knowing the requirements.
Sometimes you need to do research to give an estimate. If someone asks you in person, or over e-mail, and you honestly don't know ask them if you can get back to them. Do not give them a number. Do the research, then reply.
If you're relying on external APIs or Frameworks etc. You need to factor in Risk Assessments that include what happens if the fit is wrong, or the interface changes mid project, etc.
When it comes to debugging a lot comes into play, system design, documentation, experience with the code. "I don't know" is an acceptable answer until you understand what is going on. Once you understand what is going on, you then estimate the fix based on the code. Giving a number before you understand what you are fixing in detail is a bad plan.
I am exceptionally experienced with a certain code base and system. You may be experienced with a different code base. You're more qualified to handle estimation on what you know. That said, if you honestly don't know, say that. Don't low ball the amount of work if you actually have no idea how long it will take.
There are a few good books on estimation and debugging, look around maybe they'll give you a few ideas.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#57Earlier 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 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.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#58[deleted]
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#59Earlier quoted context omitted.
> ...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…
And some developers bring this on themselves. They could use the boring conservative technology that they know inside and out from the last project, or they could use something that's new and hot this month, which they have never done or have much less experience with (but is exciting).
Double whammy if it's an unfamiliar domain and a cutting-edge tech stack.
Re: What do you mean ‘we need more time’? Project schedule estimation in software
#60Almost 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'd love to know more.