5 ms·

No, estimating software work is impossible. I refuse to do it. If pressed insistently I will "estimate" four hours. I've encountered situations where I was tol

No, estimating software work is impossible. I refuse to do it. If pressed insistently I will "estimate" four hours. I've encountered situations where I was told, "That's unacceptable." My response was, "OK, two weeks." Need I say that that was also "unacceptable". My point is that any "estimate" is nothing more than a guess, and irrelevant in any case. A given feature/bugfix/whatever is gonna take as long as its gonna take. Estimation is a shibboleth.

gadders 8y ago
I hope you never get any work done on your house. "I've given you the architects plans for my kitchen. How long do you think it will take?" "It will take as long as it's gonna take. Please sign this blank cheque."
- mikro2nd 8y ago
  There's a world of difference... People have been working on houses for... a couple of thousand years?... there's not much that's unknown about house building. Software building? Not so much. It's almost always all unknowns. New libraries, new programming languages, new requirements never before dreamed of, new everything. Your parallel with housebuilding is a false one.
  - gadders 8y ago
    If you can't give at least give a order of magnitude estimate, or an estimate with documented assumptions, you don't know your job well enough.
- afarrell 8y ago
  Someone who is building a new kitchen has likely built many before and there are a bounded number of things that can go wrong in the schedule of that. Even so, the Scott brothers still sometimes have cost overruns. A better parallel would be building a tunnel or railway line -- something bespoke and which has to deal with lots of stakeholders and dependencies. A Londoner or a Bostonian can tell you that the schedules for those are not that reliable either. ------- But that is kinda beside the point. The ability of someone else in another profession to produce estimates doesn't actually provide any indication about the path a software engineer can walk to learn to produce estimates.
  - gadders 8y ago
    It's not whether the estimates are reliable or not, it's unwillingness to give any estimate at all. Nobody should be held to an estimate if unforeseen things happen - the equivalent of the builder finding an unexploded a WW2 bomb but the inability to give any figure at all is incompetence. Something like "if it all goes smoothly, two weeks, but library x is bleeding edge and could double that if it doesn't work as advertised." or "give me three days to build a prototype and try some edge cases and then I'll be able to give you a firmer figure." is acceptable and at least gives someone idea if a featurev is worth the cost of building it.
    - afarrell 8y ago
      > but the inability to give any figure at all is incompetence. Right, but it is incompetence that we don't know as an industry how to cure. Can you point me to a class on how to do software engineering estimates? Can you point me to someone who is able to do 1-on-1 tutoring on the subject? What is the path for a junior engineer out of uni to become competent at giving estimates? Claiming to be competent (by giving a number you just pulled out of your ass) is worse communication than owning up to your own incompetence.
      - gadders 8y ago
        It depends on the task and what you're doing, but you can normally give some idea, or break the task down into stages. I agree it would be great if there was some way of teaching estimation, but what it mostly comes down to is experience.
        afarrell 8y ago
        > you can normally give some idea, or break the task down into stages That requires the skill to actually do that. If you don't have the skill to do a thing, then claiming you've done it isn't professional. In thinking about this, it suddenly occurs to me that in other domains, the professional thing to do would be to call in someone who does. A medical doctor doesn't know how to properly operate imaging equipment and so she calls in a radiologist. A general contractor isn't really skilled at building a septic system and so sub-contracts to someone who does know how to do that. > mostly comes down to is experience. I think the answer to "What should I do when asked for an estimate when I don't know how to make one?" might actually be to call in the help of a more senior engineer to talk through the project with you and guide you to producing the estimate. This still requires you to have the backbone to say "I don't know." and "I need help." Then, you can gain the experience of producing a reliable estimate and seeing what questions need to be asked when doing so.
BjoernKW 8y ago
That's not a constructive attitude. While it's true that the way estimates often are treated is not particularly constructive either but rather more of a fool's errand blanket statements like "estimating software work is impossible" aren't conducive to improving anything. The only thing statements like that are likely to achieve is to alienate people. Software project estimates aren't an exact science but with experience it's quite possible to provide estimates within a margin of error. Whether those estimates are useful in turn entirely depends on what they're used for (e.g. informing a build-measure-learn cycle rather than for blame-shifting once something goes wrong).
- afarrell 8y ago
  The reason it is a nonconstructive attitude is that saying "4 hours" or "2 weeks" is not a direct and honest expression of what you'd mean by saying it. The honest and communicative thing to say is something like: """ I do not know how to develop a meaningfully accurate number of days or hours that this will take. The software industry as a whole has not developed reliable best practices for estimating software tasks or for teaching those practices to other software engineers. As such, it would be deceptive and unprofessional for me to give you a number. """ To really communicate this effectively, you have to say it with confidence: standing up straight, shoulders back, making eye contact. It is uncomfortable and the sort of thing that makes me feel a bit nauseous to say, but as a professional, it is important to be honest even in the face of discomfort. To this opener, I would personally add to this statement either "However, if you are looking to get a rough assessment of the size or complexity involved, this is the sort of task that I can take 2 hours and produce a breakdown of the components of this." or "I sense that what you'd really like is a judgement of how large or complex this task is. However, at this stage, the task is not well-scoped enough for me to do that. I would need to invest effort into fleshing that out. If you'd like I can timebox one (or two) days to investigate and report back with what I discover are the major components to this and whether there are likely to be more unknown components." or "In particular, this is the sort of task where the work to discover the problem and the correct approach to solve it is 90% of the battle. There unfortunately isn't a way to break that down ahead of time." Depending on whether it seemed like a task similar to one that I'd done before or not--or whether it was a bug-hunt.
swatcoder 8y ago
Estimation is often challenging and sometimes impossible, but there are in fact many opportunities to deliver reliable estimates. If you'd genuinely like to learn more about estimating software projects and when you can do so more or less reliably, Steve McConnell's Software Estimation: Demystifying the Black Art provides a great survey of techniques. https://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351 https://www.amazon.com/Software-Estimation-Demystifying-Deve...
- afarrell 8y ago
  I bought that book about 4 years ago in an attempt to try to learn how to produce estimates for the sorts of tasks I might do in a given day as a software developer. I read through the first third of it and then skimmed the rest. Unless my memory has wildly deceived me, that book doesn't contain advice on how to do so. Rather, it assumes you know how to estimate ticket-level work and talks about how to estimate on the scale of months or quarters.
afarrell 8y ago
Please do not downvote this comment. mikro2nd is expressing something that I've also felt and I have heard from multiple other engineers in the hallway track at conferences and in 1-on-1s. As such, even if you disagree with the opinion, it is still an important contribution to the discussion. If you believe that there is a reliable method for producing time-measured estimates which a software engineer can learn -- a method which is not magic but is merely work -- it would be highly valuable for you to lay that out here.
- HeyLaughingBoy 8y ago
  Sure! Truly accurate time tracking and recording. Then using those historical times to inform future estimates. Most development we do is not the great unknown. If it took you 10 hours to design, code and test the update to a Student record for a db application last year in Java, it will likely take you roughly 10 hours this year to do something similar in the same language. The problem is that most organizations are unwilling to develop the rigor of recording time on task accurately and saving them in such a way that the times can be retrieved later, and using those recorded times to estimate future work. All of that takes effort and it's effort that's not billable to a project, so no one wants to do it. But when you do it, it does work!
amirathi 8y ago
> A given feature/bugfix/whatever is gonna take as long as its gonna take. If this is every developers attitude how can the team make any plans about product roadmap? How would the team decide what to take on in a week/month/quarter? I'm a developer and I understand difficulties in estimating. I also know of poor leaders who use estimation trap to guilt developers into an impossible deadline. But this attitude is not helpful and will not fly in any good team. If you apply yourself to it consistently, estimation (with certain degree of error) is not impossible. I wrote practical tips somewhere else in this thread.

gadders 8y ago

I hope you never get any work done on your house. "I've given you the architects plans for my kitchen. How long do you think it will take?" "It will take as long as it's gonna take. Please sign this blank cheque."

mikro2nd 8y ago
There's a world of difference... People have been working on houses for... a couple of thousand years?... there's not much that's unknown about house building. Software building? Not so much. It's almost always all unknowns. New libraries, new programming languages, new requirements never before dreamed of, new everything. Your parallel with housebuilding is a false one.
- gadders 8y ago
  If you can't give at least give a order of magnitude estimate, or an estimate with documented assumptions, you don't know your job well enough.
afarrell 8y ago
Someone who is building a new kitchen has likely built many before and there are a bounded number of things that can go wrong in the schedule of that. Even so, the Scott brothers still sometimes have cost overruns. A better parallel would be building a tunnel or railway line -- something bespoke and which has to deal with lots of stakeholders and dependencies. A Londoner or a Bostonian can tell you that the schedules for those are not that reliable either. ------- But that is kinda beside the point. The ability of someone else in another profession to produce estimates doesn't actually provide any indication about the path a software engineer can walk to learn to produce estimates.
- gadders 8y ago
  It's not whether the estimates are reliable or not, it's unwillingness to give any estimate at all. Nobody should be held to an estimate if unforeseen things happen - the equivalent of the builder finding an unexploded a WW2 bomb but the inability to give any figure at all is incompetence. Something like "if it all goes smoothly, two weeks, but library x is bleeding edge and could double that if it doesn't work as advertised." or "give me three days to build a prototype and try some edge cases and then I'll be able to give you a firmer figure." is acceptable and at least gives someone idea if a featurev is worth the cost of building it.
  - afarrell 8y ago
    > but the inability to give any figure at all is incompetence. Right, but it is incompetence that we don't know as an industry how to cure. Can you point me to a class on how to do software engineering estimates? Can you point me to someone who is able to do 1-on-1 tutoring on the subject? What is the path for a junior engineer out of uni to become competent at giving estimates? Claiming to be competent (by giving a number you just pulled out of your ass) is worse communication than owning up to your own incompetence.
    - gadders 8y ago
      It depends on the task and what you're doing, but you can normally give some idea, or break the task down into stages. I agree it would be great if there was some way of teaching estimation, but what it mostly comes down to is experience.
      - afarrell 8y ago
        > you can normally give some idea, or break the task down into stages That requires the skill to actually do that. If you don't have the skill to do a thing, then claiming you've done it isn't professional. In thinking about this, it suddenly occurs to me that in other domains, the professional thing to do would be to call in someone who does. A medical doctor doesn't know how to properly operate imaging equipment and so she calls in a radiologist. A general contractor isn't really skilled at building a septic system and so sub-contracts to someone who does know how to do that. > mostly comes down to is experience. I think the answer to "What should I do when asked for an estimate when I don't know how to make one?" might actually be to call in the help of a more senior engineer to talk through the project with you and guide you to producing the estimate. This still requires you to have the backbone to say "I don't know." and "I need help." Then, you can gain the experience of producing a reliable estimate and seeing what questions need to be asked when doing so.

BjoernKW 8y ago

That's not a constructive attitude. While it's true that the way estimates often are treated is not particularly constructive either but rather more of a fool's errand blanket statements like "estimating software work is impossible" aren't conducive to improving anything. The only thing statements like that are likely to achieve is to alienate people. Software project estimates aren't an exact science but with experience it's quite possible to provide estimates within a margin of error. Whether those estimates are useful in turn entirely depends on what they're used for (e.g. informing a build-measure-learn cycle rather than for blame-shifting once something goes wrong).

afarrell 8y ago
The reason it is a nonconstructive attitude is that saying "4 hours" or "2 weeks" is not a direct and honest expression of what you'd mean by saying it. The honest and communicative thing to say is something like: """ I do not know how to develop a meaningfully accurate number of days or hours that this will take. The software industry as a whole has not developed reliable best practices for estimating software tasks or for teaching those practices to other software engineers. As such, it would be deceptive and unprofessional for me to give you a number. """ To really communicate this effectively, you have to say it with confidence: standing up straight, shoulders back, making eye contact. It is uncomfortable and the sort of thing that makes me feel a bit nauseous to say, but as a professional, it is important to be honest even in the face of discomfort. To this opener, I would personally add to this statement either "However, if you are looking to get a rough assessment of the size or complexity involved, this is the sort of task that I can take 2 hours and produce a breakdown of the components of this." or "I sense that what you'd really like is a judgement of how large or complex this task is. However, at this stage, the task is not well-scoped enough for me to do that. I would need to invest effort into fleshing that out. If you'd like I can timebox one (or two) days to investigate and report back with what I discover are the major components to this and whether there are likely to be more unknown components." or "In particular, this is the sort of task where the work to discover the problem and the correct approach to solve it is 90% of the battle. There unfortunately isn't a way to break that down ahead of time." Depending on whether it seemed like a task similar to one that I'd done before or not--or whether it was a bug-hunt.

swatcoder 8y ago

Estimation is often challenging and sometimes impossible, but there are in fact many opportunities to deliver reliable estimates. If you'd genuinely like to learn more about estimating software projects and when you can do so more or less reliably, Steve McConnell's Software Estimation: Demystifying the Black Art provides a great survey of techniques. https://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351 https://www.amazon.com/Software-Estimation-Demystifying-Deve...

afarrell 8y ago
I bought that book about 4 years ago in an attempt to try to learn how to produce estimates for the sorts of tasks I might do in a given day as a software developer. I read through the first third of it and then skimmed the rest. Unless my memory has wildly deceived me, that book doesn't contain advice on how to do so. Rather, it assumes you know how to estimate ticket-level work and talks about how to estimate on the scale of months or quarters.

afarrell 8y ago

Please do not downvote this comment. mikro2nd is expressing something that I've also felt and I have heard from multiple other engineers in the hallway track at conferences and in 1-on-1s. As such, even if you disagree with the opinion, it is still an important contribution to the discussion. If you believe that there is a reliable method for producing time-measured estimates which a software engineer can learn -- a method which is not magic but is merely work -- it would be highly valuable for you to lay that out here.

HeyLaughingBoy 8y ago
Sure! Truly accurate time tracking and recording. Then using those historical times to inform future estimates. Most development we do is not the great unknown. If it took you 10 hours to design, code and test the update to a Student record for a db application last year in Java, it will likely take you roughly 10 hours this year to do something similar in the same language. The problem is that most organizations are unwilling to develop the rigor of recording time on task accurately and saving them in such a way that the times can be retrieved later, and using those recorded times to estimate future work. All of that takes effort and it's effort that's not billable to a project, so no one wants to do it. But when you do it, it does work!

amirathi 8y ago

> A given feature/bugfix/whatever is gonna take as long as its gonna take. If this is every developers attitude how can the team make any plans about product roadmap? How would the team decide what to take on in a week/month/quarter? I'm a developer and I understand difficulties in estimating. I also know of poor leaders who use estimation trap to guilt developers into an impossible deadline. But this attitude is not helpful and will not fly in any good team. If you apply yourself to it consistently, estimation (with certain degree of error) is not impossible. I wrote practical tips somewhere else in this thread.