4 ms·

It's not as simple as you make it to be. How long do you think it would take to walk from San Francisco to Los Angeles? I guarantee you that your max will not b

It's not as simple as you make it to be. How long do you think it would take to walk from San Francisco to Los Angeles? I guarantee you that your max will not be high enough. Try it and then read the following article and let's see how close you came http://www.michaelrwolfe.com/2013/10/19/50/ http://www.michaelrwolfe.com/2013/10/19/50/ Just because you can't always have an accurate estimate doesn't mean it's now worth it. Also remember that estimates are based on resources. We were able to go to the moon in a decade but a lot of work was done before and the budget to get there was much higher than what most software development efforts ever get relatively speaking. It might not be going to the moon but that doesn't mean some projects aren't very complex either.

FollowSteph3 10y ago
Actually another great example is a new pharmaceutical drug. Homw can you accurately predict that effort. If something is complex and or newer sometimes it's very hard if not impossible to predict.
cpitman 10y ago
That article is more like asking someone who has never programmed before how long it will take to do a project. If you are estimating something that you have truly never done and have no experience in, then it's going to be more difficult. But if you at least acknowledge that, you can take steps against it like lowering your own confidence level in your estimates (this feature will take 4-8 weeks, and I'm only 25% confident the actual timeline is between those). The issue is more when you are over confident, which it sounds like no one here is! I'm not an avid hiker, but I've done enough weekend hikes to know that 10 miles per day can be pushing it for me on some terrain. I wouldn't ask someone who has never hiked ever before to estimate how long a hike would take. I wouldn't ask a programmer to estimate how long it takes to construct a bridge.
- FollowSteph3 10y ago
  Have you ever tried to sell something to management with a 25% confidence level with an estimate that is at least 2x (4-8 weeks). You've just basically said your estimate is anywhere from a week to half a year, which basically means you have no estimate ;) In terms of never having done it before, this is true of most software projects. If you're building the same house from the same plans then this is the same as say installing a Wordpress blog, easy to estimate. But if you were to ask how long it would take to build Wordpress from scratch, even having a Wordpress sample app, it would be very hard. Not only that but there are a lot of assumptions. Is it for a handful of visitors or are we talking a million visitor blog? Ignoring that, let's go back to the pharma example. How long do you estimate developing a new drug will take? It's not the first drug your company has developed. Anything beyond a week is hard to estimate. Back to your estimate of 25% within 4-8 weeks, this would never be accepted because it could mean anything. The worse part, I an tell you right now, even if new functionality or changes are added, you will be elf to 4-8 weeks, the 25% will be ignored. And in most cases management will hold you to 4 weeks because this is what was sold to their bosses.
  - cpitman 10y ago
    Actually, it means a lot. It tells us how much we understand the project's timeline. Many projects get estimated way to early in the process, and the true level of uncertainty at that point is massive. If the low confidence level means the estimate has an upper end that isn't feasible, there are things we can do to increase confidence. Proof of Concepts/Spikes are explicitly for the purpose of taken an unknown feature and getting a better understanding of their complexity, scope, and timeline. (http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/ http://www.construx.com/Thought_Leadership/Books/The_Cone_of...) So then the hard part is communicating to the business the current estimates and confidence level and that we can do some up front work to tighten down our estimate and the schedule. This is actually part of ACM's "Software Engineer Code of Ethics": "3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates." As for pharmaceuticals, I have no experience there. I doubt that they really just let scientists go off and do whatever they want with unlimited budgets, and just live with the results.
    - FollowSteph3 10y ago
      So let me ask you a simple question, how much time do I have to give the initial estimate and how long do I get to increase confidence? Is it in the order or days, weeks, or months? I ask because a 25% confidence level on 4-8 weeks would most likely require some time to increase the confidence, more than you would be permitted. I agree with what you're saying and that's all great and awesome but in the real world it unfortunately doesn't work that way. In most cases you have a day to a week to come up with an estimate for a year long project. If you by great luck get a cognate to do a spike, you get maybe an extra day. Ok most cases actually you would've maybe gotten an hour to a day at best and there would be no spike, and if you did get a spike it would be maybe an hour. Again I agree with what you're saying but it just doesn't work this way for the vast majority of companies. Also is this real time or actual time? In other words does it include time for meetings, holidays, sick days, change in staff, etc.
      - 10y ago

FollowSteph3 10y ago

Actually another great example is a new pharmaceutical drug. Homw can you accurately predict that effort. If something is complex and or newer sometimes it's very hard if not impossible to predict.

cpitman 10y ago

That article is more like asking someone who has never programmed before how long it will take to do a project. If you are estimating something that you have truly never done and have no experience in, then it's going to be more difficult. But if you at least acknowledge that, you can take steps against it like lowering your own confidence level in your estimates (this feature will take 4-8 weeks, and I'm only 25% confident the actual timeline is between those). The issue is more when you are over confident, which it sounds like no one here is! I'm not an avid hiker, but I've done enough weekend hikes to know that 10 miles per day can be pushing it for me on some terrain. I wouldn't ask someone who has never hiked ever before to estimate how long a hike would take. I wouldn't ask a programmer to estimate how long it takes to construct a bridge.

FollowSteph3 10y ago
Have you ever tried to sell something to management with a 25% confidence level with an estimate that is at least 2x (4-8 weeks). You've just basically said your estimate is anywhere from a week to half a year, which basically means you have no estimate ;) In terms of never having done it before, this is true of most software projects. If you're building the same house from the same plans then this is the same as say installing a Wordpress blog, easy to estimate. But if you were to ask how long it would take to build Wordpress from scratch, even having a Wordpress sample app, it would be very hard. Not only that but there are a lot of assumptions. Is it for a handful of visitors or are we talking a million visitor blog? Ignoring that, let's go back to the pharma example. How long do you estimate developing a new drug will take? It's not the first drug your company has developed. Anything beyond a week is hard to estimate. Back to your estimate of 25% within 4-8 weeks, this would never be accepted because it could mean anything. The worse part, I an tell you right now, even if new functionality or changes are added, you will be elf to 4-8 weeks, the 25% will be ignored. And in most cases management will hold you to 4 weeks because this is what was sold to their bosses.
- cpitman 10y ago
  Actually, it means a lot. It tells us how much we understand the project's timeline. Many projects get estimated way to early in the process, and the true level of uncertainty at that point is massive. If the low confidence level means the estimate has an upper end that isn't feasible, there are things we can do to increase confidence. Proof of Concepts/Spikes are explicitly for the purpose of taken an unknown feature and getting a better understanding of their complexity, scope, and timeline. (http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertainty/ http://www.construx.com/Thought_Leadership/Books/The_Cone_of...) So then the hard part is communicating to the business the current estimates and confidence level and that we can do some up front work to tighten down our estimate and the schedule. This is actually part of ACM's "Software Engineer Code of Ethics": "3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates." As for pharmaceuticals, I have no experience there. I doubt that they really just let scientists go off and do whatever they want with unlimited budgets, and just live with the results.
  - FollowSteph3 10y ago
    So let me ask you a simple question, how much time do I have to give the initial estimate and how long do I get to increase confidence? Is it in the order or days, weeks, or months? I ask because a 25% confidence level on 4-8 weeks would most likely require some time to increase the confidence, more than you would be permitted. I agree with what you're saying and that's all great and awesome but in the real world it unfortunately doesn't work that way. In most cases you have a day to a week to come up with an estimate for a year long project. If you by great luck get a cognate to do a spike, you get maybe an extra day. Ok most cases actually you would've maybe gotten an hour to a day at best and there would be no spike, and if you did get a spike it would be maybe an hour. Again I agree with what you're saying but it just doesn't work this way for the vast majority of companies. Also is this real time or actual time? In other words does it include time for meetings, holidays, sick days, change in staff, etc.
    - 10y ago