6 ms·

You Can't Do Software Estimates at All

34 points by SarasaNews 10y ago

Retra 10y ago
Well, maybe not if you're jumping to a new platform, API, framework, language, or library each time you start a project.
- HeyLaughingBoy 10y ago
  How long did it take to jump to the last new platform? How long for the last new API, last new language, framework, library? If you had historical data on how things went the last time you did these things, you'd be better positioned to estimate how long it will take this time.
  - Retra 10y ago
    Maybe if you're not making anything with any kind of novelty.
    - HeyLaughingBoy 10y ago
      At some point, everything is similar to something you've done before. The difficulty is relating what you're doing now to what you did before. If you go into it assuming that your work is some special snowflake that is completely novel in all respects, you'll get nothing out of it. Find parallels with what you've done before and you can actually make an estimate that's an improvement over a SWAG.
tyingq 10y ago
Guessing this won't be a popular response, but all the hand-wringing about how management is unreasonable to ask for estimates (cost or time) just isn't helpful. Anything a business is going to invest in needs some kind of justification, and a metric to prioritize against other things the funds could be spent on. I think it's fair to push back with suggestions that might make a realistic estimate possible (reduce scope, proof of concept, etc). However, just suggesting you can't provide any kind of reasonable time and cost estimate doesn't help anyone.
- lochlan 10y ago
  Reduction in scope and prototyping can help reduce risk in how wrong your estimate is, but I think it is misleading to suggest that these techniques inherently "might make a realistic estimate possible." I don't think I'm alone in that I've had tasks that were supposed to take less than a day take weeks. I'm not saying this is common, but there is no silver bullet, and assuming from the beginning that estimating is basically impossible can help bring everyone into reality.
  - tyingq 10y ago
    I'm not suggesting scope reduction or prototyping are magic solutions. I offered them as 2 examples of constructive pushback. The essence of my point was that flat out not estimating isn't an option.
    - jbergens 10y ago
      It is for some companies. Or just do very crude estimates like "this might take 3-5 weeks" even for things that might take 1 week but could take 6 weeks. Sometimes it is better to start developing and then tell stakeholders that it will take a really long time when you run into problems. A lot of stakeholders have problems with estimates of the form "it could take 2 days or 3 weeks". It would be nice if the industri starts giving probability about estimates especially when you know that there are two clear possibillties where one is much, much larger. They might want to invest 2 days into trying to solve the problem with the understanding that it might take much more time and if that happens they can change their mind and skip the feature instead, "only" wasting two days of investigation.
    - ArkyBeagle 10y ago
      But it can be. See "Wake me when it's over".
      - tyingq 10y ago
        You can commit to an investment with no idea, at all, whether it will cost more than the benefit it delivers. I suppose "not an option" isn't quite the right wording. It's an option.
bonniemuffin 10y ago
Still, some projects will take longer than others, and it's possible to distinguish a 2-week project from a 2-quarter project, even if they actually end up taking 3 weeks and 3 quarters. I feel like comparative sizing is the most important part of software estimates, so that you can make reasonable tradeoffs, e.g. "if we take on this project, we can't do these other 2 smaller projects". This is still a valuable exercise, even if all of the estimates are each individually quite inaccurate.
- HeyLaughingBoy 10y ago
  I agree completely. It's the only way I've found that works. Start the estimate by saying "these rolled-up, roughly estimated tasks come to about a year in total." Now we know it's closer to a year than to two months. Once we start, we can continuously refine the estimate. "Sorry, there's a bunch of stuff we didn't see. We can give you X functionality in a year, or all of it if you can wait 18 months" Lather, rinse, repeat. With experience and good time tracking of tasks, you learn how long things take: "every database we set up in the last year took about 10 days to get right." Now you know your estimate to configure a database and get it online is 10 days, not the optimistic "I can do it in an afternoon" that everyone claims. The key to good estimating is good historical data. Problem is devs hate tracking their time and reporting accurately.
Dr_tldr 10y ago
Trying to prove the impossibility of something that is never going to go away as a requirement isn't very useful. An alternative would be to describe potential break-points and conditionals in the planning process. For instance, if a third party library can help you with some core functionality, it takes a few hours to investigate and an hour to implement. But if it's not going to work for whatever reason, then you know you have to make your own, and the initial implementation could range from 4-6 weeks. If you say "this will take either 4 hours or 4-6 weeks", that's far more useful and acceptable to management than saying "this will take somewhere between 4 hours and 6 weeks. No one sane is asking for exact estimates, and no one smart is promising a hard deadline based on the assumption that nothing goes wrong. A good engineer will pad their estimate slightly for the same reason that airplanes carry more fuel than the exact amount they need to reach their destination. It's not a deceptive or inefficient practice, it's managing uncertainty.
- thwarted 10y ago
  No one sane is asking for exact estimates … It's not a deceptive or inefficient practice, it's managing uncertainty. Part of the issue is that the asking for estimates ends up getting turned into exacting time requirements as an attempt to control and manage uncertainty. And often, many of the people who turn estimates into requirements are, arguably, insane, because they are trying to manage the uncertainty in the wrong way.
  - Gibbon1 10y ago
    I've taken to just telling my boss whether I think something is 'just work', 'tricky' or 'hard'. And about howm much of that he's asking for, Just Work: Means are the pieces are there to do whats wanted. Tricky: Means I need to create something from scratch or modify two or more modules. Hard: Anything to do with timing, interrupts, or that involves re-organizing swaths of unrelated code. Hard2: I have to learn a new language, frame-work, microprocessor, etc.
dpweb 10y ago
Companies have budgets so estimates are necessary. Volunteer or work in open source if you don't like it. Those asking - business types usually - know (and often care) little about the craft, so they can't be expected to be much help. The best you can do is be experienced enough to be able to get it somewhat close. Nothing wrong with padding. How much.. is an art form. But remember technical people nine times out of ten, will under-estimate.
andyidsinga 10y ago
some thoughts: 1) it seems that the accuracy of an estimate is inversely proportional the length of time for which it applies. In my experience engineers aren't too bad at estimating if a task can plausibly fit into a two week sprint 2) I think the boss should be taking an active part in the estimation process, not just asking "how many hours/days". When I estimate with my teams I try to say "given x,y,z and the current state and that A,B,C blocks are not quite understood can this item reasonably be completed within our sprint" ..then we play poker / vote / comment etc. If the item isn't plausible for a sprint I'm (likeaboss) going back to the drawing board on that item to define it better and get it into more manageable pieces (consulting the team as needed) We're striving to make sure work items are defined well enough to be fairly confident they can be done in a short amount of time.
douche 10y ago
The one I love is being asked for an estimate cold on some feature/requirment I've never heard mentioned before. "How long will it take to add a feature to frobulate the fribbers?" "What's a fribber, and what, exactly, does it mean to frobulate them?" Handwave "How long? We need to schedule this." "Can I do some research about frobulating fribbers and how one goes about doing that?" "No, we need an estimate" "Ok, five minutes? Six weeks? Six years? Who the hell knows? What do you want me to say?"

34 points by SarasaNews 10y ago

Retra 10y ago

Well, maybe not if you're jumping to a new platform, API, framework, language, or library each time you start a project.

HeyLaughingBoy 10y ago
How long did it take to jump to the last new platform? How long for the last new API, last new language, framework, library? If you had historical data on how things went the last time you did these things, you'd be better positioned to estimate how long it will take this time.
- Retra 10y ago
  Maybe if you're not making anything with any kind of novelty.
  - HeyLaughingBoy 10y ago
    At some point, everything is similar to something you've done before. The difficulty is relating what you're doing now to what you did before. If you go into it assuming that your work is some special snowflake that is completely novel in all respects, you'll get nothing out of it. Find parallels with what you've done before and you can actually make an estimate that's an improvement over a SWAG.

tyingq 10y ago

Guessing this won't be a popular response, but all the hand-wringing about how management is unreasonable to ask for estimates (cost or time) just isn't helpful. Anything a business is going to invest in needs some kind of justification, and a metric to prioritize against other things the funds could be spent on. I think it's fair to push back with suggestions that might make a realistic estimate possible (reduce scope, proof of concept, etc). However, just suggesting you can't provide any kind of reasonable time and cost estimate doesn't help anyone.

lochlan 10y ago
Reduction in scope and prototyping can help reduce risk in how wrong your estimate is, but I think it is misleading to suggest that these techniques inherently "might make a realistic estimate possible." I don't think I'm alone in that I've had tasks that were supposed to take less than a day take weeks. I'm not saying this is common, but there is no silver bullet, and assuming from the beginning that estimating is basically impossible can help bring everyone into reality.
- tyingq 10y ago
  I'm not suggesting scope reduction or prototyping are magic solutions. I offered them as 2 examples of constructive pushback. The essence of my point was that flat out not estimating isn't an option.
  - jbergens 10y ago
    It is for some companies. Or just do very crude estimates like "this might take 3-5 weeks" even for things that might take 1 week but could take 6 weeks. Sometimes it is better to start developing and then tell stakeholders that it will take a really long time when you run into problems. A lot of stakeholders have problems with estimates of the form "it could take 2 days or 3 weeks". It would be nice if the industri starts giving probability about estimates especially when you know that there are two clear possibillties where one is much, much larger. They might want to invest 2 days into trying to solve the problem with the understanding that it might take much more time and if that happens they can change their mind and skip the feature instead, "only" wasting two days of investigation.
  - ArkyBeagle 10y ago
    But it can be. See "Wake me when it's over".
    - tyingq 10y ago
      You can commit to an investment with no idea, at all, whether it will cost more than the benefit it delivers. I suppose "not an option" isn't quite the right wording. It's an option.

bonniemuffin 10y ago

Still, some projects will take longer than others, and it's possible to distinguish a 2-week project from a 2-quarter project, even if they actually end up taking 3 weeks and 3 quarters. I feel like comparative sizing is the most important part of software estimates, so that you can make reasonable tradeoffs, e.g. "if we take on this project, we can't do these other 2 smaller projects". This is still a valuable exercise, even if all of the estimates are each individually quite inaccurate.

HeyLaughingBoy 10y ago
I agree completely. It's the only way I've found that works. Start the estimate by saying "these rolled-up, roughly estimated tasks come to about a year in total." Now we know it's closer to a year than to two months. Once we start, we can continuously refine the estimate. "Sorry, there's a bunch of stuff we didn't see. We can give you X functionality in a year, or all of it if you can wait 18 months" Lather, rinse, repeat. With experience and good time tracking of tasks, you learn how long things take: "every database we set up in the last year took about 10 days to get right." Now you know your estimate to configure a database and get it online is 10 days, not the optimistic "I can do it in an afternoon" that everyone claims. The key to good estimating is good historical data. Problem is devs hate tracking their time and reporting accurately.

Dr_tldr 10y ago

Trying to prove the impossibility of something that is never going to go away as a requirement isn't very useful. An alternative would be to describe potential break-points and conditionals in the planning process. For instance, if a third party library can help you with some core functionality, it takes a few hours to investigate and an hour to implement. But if it's not going to work for whatever reason, then you know you have to make your own, and the initial implementation could range from 4-6 weeks. If you say "this will take either 4 hours or 4-6 weeks", that's far more useful and acceptable to management than saying "this will take somewhere between 4 hours and 6 weeks. No one sane is asking for exact estimates, and no one smart is promising a hard deadline based on the assumption that nothing goes wrong. A good engineer will pad their estimate slightly for the same reason that airplanes carry more fuel than the exact amount they need to reach their destination. It's not a deceptive or inefficient practice, it's managing uncertainty.

thwarted 10y ago
No one sane is asking for exact estimates … It's not a deceptive or inefficient practice, it's managing uncertainty. Part of the issue is that the asking for estimates ends up getting turned into exacting time requirements as an attempt to control and manage uncertainty. And often, many of the people who turn estimates into requirements are, arguably, insane, because they are trying to manage the uncertainty in the wrong way.
- Gibbon1 10y ago
  I've taken to just telling my boss whether I think something is 'just work', 'tricky' or 'hard'. And about howm much of that he's asking for, Just Work: Means are the pieces are there to do whats wanted. Tricky: Means I need to create something from scratch or modify two or more modules. Hard: Anything to do with timing, interrupts, or that involves re-organizing swaths of unrelated code. Hard2: I have to learn a new language, frame-work, microprocessor, etc.

dpweb 10y ago

Companies have budgets so estimates are necessary. Volunteer or work in open source if you don't like it. Those asking - business types usually - know (and often care) little about the craft, so they can't be expected to be much help. The best you can do is be experienced enough to be able to get it somewhat close. Nothing wrong with padding. How much.. is an art form. But remember technical people nine times out of ten, will under-estimate.

andyidsinga 10y ago

some thoughts: 1) it seems that the accuracy of an estimate is inversely proportional the length of time for which it applies. In my experience engineers aren't too bad at estimating if a task can plausibly fit into a two week sprint 2) I think the boss should be taking an active part in the estimation process, not just asking "how many hours/days". When I estimate with my teams I try to say "given x,y,z and the current state and that A,B,C blocks are not quite understood can this item reasonably be completed within our sprint" ..then we play poker / vote / comment etc. If the item isn't plausible for a sprint I'm (likeaboss) going back to the drawing board on that item to define it better and get it into more manageable pieces (consulting the team as needed) We're striving to make sure work items are defined well enough to be fairly confident they can be done in a short amount of time.

douche 10y ago

The one I love is being asked for an estimate cold on some feature/requirment I've never heard mentioned before. "How long will it take to add a feature to frobulate the fribbers?" "What's a fribber, and what, exactly, does it mean to frobulate them?" Handwave "How long? We need to schedule this." "Can I do some research about frobulating fribbers and how one goes about doing that?" "No, we need an estimate" "Ok, five minutes? Six weeks? Six years? Who the hell knows? What do you want me to say?"