4 ms·

> For many of us a dearly loved date has already been selected, which makes our estimation efforts really interesting as we endeavor to shove more and more "stu

> For many of us a dearly loved date has already been selected, which makes our estimation efforts really interesting as we endeavor to shove more and more "stuff" into that bag. The problem is not to ask for estimates, companies need to budget, plan hiring, and inform clients. The problem is that many companies do NOT ask for estimates but create delivery dates out of thin air. So, I agree that estimates are a waste of time if they are not used. But they should be used as are part of any reasonable-managed engineering project.

ed_elliott_asc 5y ago
Estimates are only useful if accurate but to create accurate estimates is hard - my standard line is “if you want me to get a better estimate i need to spend about 1/4 of the time estimating to work - so if I think it will take a day, I should have spent a couple of hours on it, if I think it will take ten days then I need two and a half days to estimate it - do you want me to do that?”. Every.single.time - the answer comes back as “no, don’t worry, just a best guess” aka made up useless estimates which are invariably wrong.
- bradleyjg 5y ago
  I don’t disagree but that probably means we as an industry need to figure out how to get better at this. It’s not unreasonable for stakeholders to want to have a rough idea of how long a project is going to last. Maybe this is something software engineering professors can research.
  - senko 5y ago
    > Maybe this is something software engineering professors can research. Good idea. We should also ask them how long that research will take so we can have a rough idea of how long we'll have to wait.
    - bradleyjg 5y ago
      AFAICT academics never have deadlines to produce anything specific. Sometimes they’ll have requirements to publish X papers in Y years, but never solve this problem by date certain. Which makes sense for open ended research projects, I don’t have any sympathy for a CEO complaining that no one can tell him how long to fully autonomous cars. It’s less fine for build me a website type projects.
    - foxfluff 5y ago
      And they should just give us that estimate quickly before they even figure out how they're going to carry out the research.
  - gonzus 5y ago
    The point is, it is hard to get to a rough idea, when you don't do the work needed to get to that rough idea. Even worse, many times the stakeholders don't really know what they want, and you are faced with unstable requirements; this means more uncertainty, worse estimations, etc.
    - magicalhippo 5y ago
      Whenever my boss asks for estimates (which thankfully is very seldom), I always give ranges, and I always make sure to highlight the ones I feel confident in and especially the ones I feel less sure about in. Last time I broke it down into about four pieces, two of which I had a firm grasp on and could give a fairly solid estimate, "about half a day", and one part which I said "this might take a day, it may take a week, I'll know once I've worked on it for a bit". I'll state what my assumptions are for the estimate so he can red flag things if the customer changes their mind, and I might offer some alternative estimates for different scenarios if I sense the goal is not entirely set in stone. This gives my boss what he needs, which is a rough idea on the scope of the project and whether it's a slam dunk or "here be dragons".
  - tsimionescu 5y ago
    I think the methods are well known, they just take time. Rough estimates do have their value (is this a 1 day feature, 1 month feature, 1 year feature?), problem is when someone starts adding rough estimates to project a date. To get a real date, you run a feasibility study - you do PoCs, you deep dive on features etc. Then, you freeze the requirements and implement based on the study. This will probably take around a quarter of the total time of the project. Alternatively, you stick to rough estimates, and you will get roughly the features you asked for in roughly the timeframe estimated.
    - Lutger 5y ago
      You could do both. Begin with a rough estimate, preferably a range (order of magnitude). If this gets greenlit, do all the things you mentioned but also just start on the project. Iterate on the estimate like you iterate on the deliverables, the estimation will get increasingly accurate as you develop. There's a bit more upfront work here that goes into the estimation, but it won't be like 25% of it is pure waste. Maybe 5 to 10%, depends on what the quality of the estimate must be. Somehow this never works in practice though, I suspect the initial guesstimate will prime the expectations of everyone involved and will be seen as a target. Clients will be disappointed if the project takes longer and frame it as such (it's late, takes longer, over budget, etc.). I suspect that in order for this to work, the initial range must be large and the adjusted estimates in the project as well as the delivery date must fall within this range. I think this is a basic function of trust: will these people do as they say or not?
  - Aeolun 5y ago
    > It’s not unreasonable for stakeholders to want to have a rough idea of how long a project is going to last. That is not unreasonable. What is unreasonable is falling into the same trap every single time, and then doing it one more time expecting a different result.
  - deleted 5y ago
    [deleted]
- tonyedgecombe 5y ago
  Some managers will still use that best guess as a stick to beat you with. The reality is most developers are powerless to fix these issues. It is a management problem.
alistairSH 5y ago
I see it as estimating a project vs estimating individual tasks. The former is a business need. The latter is not. After some high level analysis and decomposition, I can say a project will take 3 months. But there’s no need to spell out every minor widget or method with hours. And this is separate from any t-shirt sizing a team does internally to plan their own time. This should be strictly internal and used as much to generate design discussion as anything else.
lightbendover 5y ago
I very recently joined a new large multi-disciplinary engineering team after running my own product-engineering org as a single-threaded leader for a few years in a related field. I'm absolutely shocked by the product-engineering dynamic here; PMs pull a date from thin air as you say, plop it in a document, and then bypass TPMs and engineering managers and take it straight to their favorite engineer to have the work started mid-Sprint. I can't wait to fix this mess. PMs should never put down any date themselves unless the task has 0 engineering dependencies.

ed_elliott_asc 5y ago

Estimates are only useful if accurate but to create accurate estimates is hard - my standard line is “if you want me to get a better estimate i need to spend about 1/4 of the time estimating to work - so if I think it will take a day, I should have spent a couple of hours on it, if I think it will take ten days then I need two and a half days to estimate it - do you want me to do that?”. Every.single.time - the answer comes back as “no, don’t worry, just a best guess” aka made up useless estimates which are invariably wrong.

bradleyjg 5y ago
I don’t disagree but that probably means we as an industry need to figure out how to get better at this. It’s not unreasonable for stakeholders to want to have a rough idea of how long a project is going to last. Maybe this is something software engineering professors can research.
- senko 5y ago
  > Maybe this is something software engineering professors can research. Good idea. We should also ask them how long that research will take so we can have a rough idea of how long we'll have to wait.
  - bradleyjg 5y ago
    AFAICT academics never have deadlines to produce anything specific. Sometimes they’ll have requirements to publish X papers in Y years, but never solve this problem by date certain. Which makes sense for open ended research projects, I don’t have any sympathy for a CEO complaining that no one can tell him how long to fully autonomous cars. It’s less fine for build me a website type projects.
  - foxfluff 5y ago
    And they should just give us that estimate quickly before they even figure out how they're going to carry out the research.
- gonzus 5y ago
  The point is, it is hard to get to a rough idea, when you don't do the work needed to get to that rough idea. Even worse, many times the stakeholders don't really know what they want, and you are faced with unstable requirements; this means more uncertainty, worse estimations, etc.
  - magicalhippo 5y ago
    Whenever my boss asks for estimates (which thankfully is very seldom), I always give ranges, and I always make sure to highlight the ones I feel confident in and especially the ones I feel less sure about in. Last time I broke it down into about four pieces, two of which I had a firm grasp on and could give a fairly solid estimate, "about half a day", and one part which I said "this might take a day, it may take a week, I'll know once I've worked on it for a bit". I'll state what my assumptions are for the estimate so he can red flag things if the customer changes their mind, and I might offer some alternative estimates for different scenarios if I sense the goal is not entirely set in stone. This gives my boss what he needs, which is a rough idea on the scope of the project and whether it's a slam dunk or "here be dragons".
- tsimionescu 5y ago
  I think the methods are well known, they just take time. Rough estimates do have their value (is this a 1 day feature, 1 month feature, 1 year feature?), problem is when someone starts adding rough estimates to project a date. To get a real date, you run a feasibility study - you do PoCs, you deep dive on features etc. Then, you freeze the requirements and implement based on the study. This will probably take around a quarter of the total time of the project. Alternatively, you stick to rough estimates, and you will get roughly the features you asked for in roughly the timeframe estimated.
  - Lutger 5y ago
    You could do both. Begin with a rough estimate, preferably a range (order of magnitude). If this gets greenlit, do all the things you mentioned but also just start on the project. Iterate on the estimate like you iterate on the deliverables, the estimation will get increasingly accurate as you develop. There's a bit more upfront work here that goes into the estimation, but it won't be like 25% of it is pure waste. Maybe 5 to 10%, depends on what the quality of the estimate must be. Somehow this never works in practice though, I suspect the initial guesstimate will prime the expectations of everyone involved and will be seen as a target. Clients will be disappointed if the project takes longer and frame it as such (it's late, takes longer, over budget, etc.). I suspect that in order for this to work, the initial range must be large and the adjusted estimates in the project as well as the delivery date must fall within this range. I think this is a basic function of trust: will these people do as they say or not?
- Aeolun 5y ago
  > It’s not unreasonable for stakeholders to want to have a rough idea of how long a project is going to last. That is not unreasonable. What is unreasonable is falling into the same trap every single time, and then doing it one more time expecting a different result.
- deleted 5y ago
  [deleted]
tonyedgecombe 5y ago
Some managers will still use that best guess as a stick to beat you with. The reality is most developers are powerless to fix these issues. It is a management problem.

alistairSH 5y ago

I see it as estimating a project vs estimating individual tasks. The former is a business need. The latter is not. After some high level analysis and decomposition, I can say a project will take 3 months. But there’s no need to spell out every minor widget or method with hours. And this is separate from any t-shirt sizing a team does internally to plan their own time. This should be strictly internal and used as much to generate design discussion as anything else.

lightbendover 5y ago

I very recently joined a new large multi-disciplinary engineering team after running my own product-engineering org as a single-threaded leader for a few years in a related field. I'm absolutely shocked by the product-engineering dynamic here; PMs pull a date from thin air as you say, plop it in a document, and then bypass TPMs and engineering managers and take it straight to their favorite engineer to have the work started mid-Sprint. I can't wait to fix this mess. PMs should never put down any date themselves unless the task has 0 engineering dependencies.