4 ms·

I feel like this has been posted before, not too long ago. And even though it's "impossible", I and hundreds of my peers at work do it every week with a workab

I feel like this has been posted before, not too long ago. And even though it's "impossible", I and hundreds of my peers at work do it every week with a workable degree of accuracy, relative to company-wide work in progress. In any case, the usual problems are: 1. We software developers think we're the first to face uncertainty, including massive uncertainty. We are not. We are in fact lightweights in this department. Ask a civil, structural or plant engineer for war stories. Or read Industrial Megaprojects to see how skipping a single water-temperature test cost billions of dollars. 2. We tend to embrace the nirvana fallacy. "Perfect or very accurate estimation is worthless; therefore, all estimation is worthless". 3. "Some projects are pure research". Yes. But very few. And even they contain bog-ordinary implementation details. Writing a fantastical new language? Well guess what: parsers have been written before, and someone with data or relevant experience could break down the task into subtasks and estimate them. I think the real reason that we so dread estimates is: 1. They aren't treated as estimates. People turn them into deadlines. Or try to negotiate with the estimate. Which means they aren't estimates any more. 2. We get them wildly wrong the first few times and throw our hands in the air. Improving estimates is hard. If it were easy, we wouldn't need to consciously do it.

UK-AL 10y ago
The hard part in estimating a language wouldn't be writing the parser. It would be experimenting with different ideas for the language, which would require trial and error and experimentation. That would be hard to estimate. As with most things that programmers do over and over again, creating parsers has been automated. That's the issue with estimation in programming, if you do the same things over and over they get automated. What's left is the unique issues which need to be estimated.
- jacques_chester 10y ago
  > What's left is the unique issues which need to be estimated. Is it your sincere, genuine contention that 100% of software development is pure research?
  - UK-AL 10y ago
    I would not class it as research, but unique problems. Say you are integrating some software into PayPal. Lots of people have integrated PayPal. However no one has integrated your software into PayPal before otherwise you wouldn't be doing it. Your software may have a weird workflow that makes PayPal difficult to integrate. So your going to have figure that out, and that's unique to your software Your software may not have an easy way integrate 3rd party payment providers. So your going to have figure out the best place for those extension points, in reusable way for multiple payment providers. Figuring out those extension points is unique to your software. There will be a lot of unique situations. If however I was using common e-commerce package as opposed to some unique software, I would just install the PayPal add on. no estimation required.
    - jacques_chester 10y ago
      You're right, but it's a categorical argument that doesn't allow for the fact that the world is made of blended probabilities. Strictly speaking, every keystroke is unique. And strictly speaking, I cannot probably show that I exist independently of someone else's perception, or that I'm not in a computer program and so on and so forth. Meanwhile, back in people-need-to-make-decisions land, as an engineer I don't get to just shrug when someone asks me for my professional opinion. I may ask for time to investigate. I may give a wide range due to uncertainty. I may recommend a different approach. I may suggest we bring risky unknowns forward. But ultimately I give my best estimate. If I get it wrong, that's not a sin. Because it's an estimate.
      - UK-AL 10y ago
        I don't mind giving estimates, if they used it as estimates, and people internalise that I may have gotten it badly wrong because something wildly unexpected has happened. In reality though, business try to use estimates to preasure software teams, and punish people who got the estimate wrong.
        jacques_chester 10y ago
lotyrin 10y ago
It's because most software is under the umbrella of office people playing grown-up and not something where reality matters or thinking happens. Engineering disciplines, when faced with uncertainty do some math and decide that if the deviation of possible quantities is too close to the tolerable limits of those quantities, you have to adjust one or the other. High school level math and problem solving plus having ever worked with software clearly state that if you have a software team, you could at the very least collect a single statistic of estimation error (actual effort over expected effort) and get a long-tail (it's going to be more more than it'll be less) distribution. Now you can spec out new projects, get values for expected effort and factor in the error distribution to get a distribution of possible actual effort for the project. If some high percentile of that distribution is more time/money than you can tolerate you have to reduce risks by cutting features or increase the budget (or have a significant fraction of projects fail). Of course, there's lots more sophistication that could (should) go into this but even this is beyond any part of software industry I've been allowed to participate in, because it gives answers that people with authority find inconvenient.
- UK-AL 10y ago
  Yes, that is part of the problem. People asking for estimates arn't looking for probability distribution of potential completion dates. They are looking for estimates to hold you to account, because that's how you run a good business right? If you gave your answer to someone in management. It would just look like your trying obfuscate the answer.
  - jacques_chester 10y ago
    > They are looking for estimates to hold you to account, because that's how you run a good business right? There's a difference between estimates and their misuse.
    - UK-AL 10y ago
      I don't think most business leaders are looking for estimates, where the developer admits it's probably way off, but it's his best guess. Or huge range of possible release dates(because there is huge variation between the estimate and actuals), as with other estimation methods.
bbcbasic 10y ago
> Or try to negotiate with the estimate. Which means they aren't estimates any more. Oh yes this annoys me. I've been asked to break it into sub tasks then justify those. So best case estimates based on some predicted sub tasks ... before any design has been done! Then the surprise when it takes longer
- jacques_chester 10y ago
  As a note, breaking into subtasks does improve estimate accuracy on just about anything, due to the "unpacking effect". Humans routinely underestimate the time and difficulty involved in just about everything. Breaking a task down into subtasks leads to higher estimates which will typically be more accurate. You are of course being asked to do something very difficult. In 3-point estimation schemes, you'd give back very wide bands for a few subtasks that you identified. Maybe point at the cone of uncertainty a few times. I know it often doesn't work. To me, most of the problems with estimating aren't with the estimating.
  - bbcbasic 10y ago
    That's true the problem here is the negotiation process. If you have a technical manager they can use the technical hat to argue the estimate down. And the manager hat is the motivation to do so. I kinda prefer the planning poker where all members are encouraged to have equal say and there is no power imbalance
bostik 10y ago
> They aren't treated as estimates. People turn them into deadlines. Or try to negotiate with the estimate. I wish I had more than a single upvote to give, because that is absolute gold. In my previous life I had the dubious pleasure of occasionally doing project estimates. I followed a fairly simple sequence which worked for that particular company and their projects. Please - do not try to blindly use this method, it will give you misleading estimates. First I checked how much proper knowledge of the problem domain we had in house. Then I estimated (in man-weeks) how long it would take for a single senior engineer to cover a given subtopic, if everything worked the first time. Then, I multiplied that estimate by 2.5 - this covered pretty well the time it _actually_ took them. Then I added a 15% "fuzz factor" to cover for still unexpected surprises. Multiply that by the number of engineers really needed for the project, and you get a reasonable ballpark estimate of how long in walltime the project would take, as well as how much effort it would require. And because every single client was always haggling with the estimates, trying to turn them into hard deadlines... I added another +30% on top. We all knew that was the haggling headroom, and expected the salespople and clients to eventually carve that one out. Our projects were mostly on time and within budget. Yup - mostly. TL;DR: please do not try the above at home or at work. Those figures worked for a very specific company, for their highly specific projects.

UK-AL 10y ago

The hard part in estimating a language wouldn't be writing the parser. It would be experimenting with different ideas for the language, which would require trial and error and experimentation. That would be hard to estimate. As with most things that programmers do over and over again, creating parsers has been automated. That's the issue with estimation in programming, if you do the same things over and over they get automated. What's left is the unique issues which need to be estimated.

jacques_chester 10y ago
> What's left is the unique issues which need to be estimated. Is it your sincere, genuine contention that 100% of software development is pure research?
- UK-AL 10y ago
  I would not class it as research, but unique problems. Say you are integrating some software into PayPal. Lots of people have integrated PayPal. However no one has integrated your software into PayPal before otherwise you wouldn't be doing it. Your software may have a weird workflow that makes PayPal difficult to integrate. So your going to have figure that out, and that's unique to your software Your software may not have an easy way integrate 3rd party payment providers. So your going to have figure out the best place for those extension points, in reusable way for multiple payment providers. Figuring out those extension points is unique to your software. There will be a lot of unique situations. If however I was using common e-commerce package as opposed to some unique software, I would just install the PayPal add on. no estimation required.
  - jacques_chester 10y ago
    You're right, but it's a categorical argument that doesn't allow for the fact that the world is made of blended probabilities. Strictly speaking, every keystroke is unique. And strictly speaking, I cannot probably show that I exist independently of someone else's perception, or that I'm not in a computer program and so on and so forth. Meanwhile, back in people-need-to-make-decisions land, as an engineer I don't get to just shrug when someone asks me for my professional opinion. I may ask for time to investigate. I may give a wide range due to uncertainty. I may recommend a different approach. I may suggest we bring risky unknowns forward. But ultimately I give my best estimate. If I get it wrong, that's not a sin. Because it's an estimate.
    - UK-AL 10y ago
      I don't mind giving estimates, if they used it as estimates, and people internalise that I may have gotten it badly wrong because something wildly unexpected has happened. In reality though, business try to use estimates to preasure software teams, and punish people who got the estimate wrong.
      - jacques_chester 10y ago

lotyrin 10y ago

It's because most software is under the umbrella of office people playing grown-up and not something where reality matters or thinking happens. Engineering disciplines, when faced with uncertainty do some math and decide that if the deviation of possible quantities is too close to the tolerable limits of those quantities, you have to adjust one or the other. High school level math and problem solving plus having ever worked with software clearly state that if you have a software team, you could at the very least collect a single statistic of estimation error (actual effort over expected effort) and get a long-tail (it's going to be more more than it'll be less) distribution. Now you can spec out new projects, get values for expected effort and factor in the error distribution to get a distribution of possible actual effort for the project. If some high percentile of that distribution is more time/money than you can tolerate you have to reduce risks by cutting features or increase the budget (or have a significant fraction of projects fail). Of course, there's lots more sophistication that could (should) go into this but even this is beyond any part of software industry I've been allowed to participate in, because it gives answers that people with authority find inconvenient.

UK-AL 10y ago
Yes, that is part of the problem. People asking for estimates arn't looking for probability distribution of potential completion dates. They are looking for estimates to hold you to account, because that's how you run a good business right? If you gave your answer to someone in management. It would just look like your trying obfuscate the answer.
- jacques_chester 10y ago
  > They are looking for estimates to hold you to account, because that's how you run a good business right? There's a difference between estimates and their misuse.
  - UK-AL 10y ago
    I don't think most business leaders are looking for estimates, where the developer admits it's probably way off, but it's his best guess. Or huge range of possible release dates(because there is huge variation between the estimate and actuals), as with other estimation methods.

bbcbasic 10y ago

> Or try to negotiate with the estimate. Which means they aren't estimates any more. Oh yes this annoys me. I've been asked to break it into sub tasks then justify those. So best case estimates based on some predicted sub tasks ... before any design has been done! Then the surprise when it takes longer

jacques_chester 10y ago
As a note, breaking into subtasks does improve estimate accuracy on just about anything, due to the "unpacking effect". Humans routinely underestimate the time and difficulty involved in just about everything. Breaking a task down into subtasks leads to higher estimates which will typically be more accurate. You are of course being asked to do something very difficult. In 3-point estimation schemes, you'd give back very wide bands for a few subtasks that you identified. Maybe point at the cone of uncertainty a few times. I know it often doesn't work. To me, most of the problems with estimating aren't with the estimating.
- bbcbasic 10y ago
  That's true the problem here is the negotiation process. If you have a technical manager they can use the technical hat to argue the estimate down. And the manager hat is the motivation to do so. I kinda prefer the planning poker where all members are encouraged to have equal say and there is no power imbalance

bostik 10y ago

> They aren't treated as estimates. People turn them into deadlines. Or try to negotiate with the estimate. I wish I had more than a single upvote to give, because that is absolute gold. In my previous life I had the dubious pleasure of occasionally doing project estimates. I followed a fairly simple sequence which worked for that particular company and their projects. Please - do not try to blindly use this method, it will give you misleading estimates. First I checked how much proper knowledge of the problem domain we had in house. Then I estimated (in man-weeks) how long it would take for a single senior engineer to cover a given subtopic, if everything worked the first time. Then, I multiplied that estimate by 2.5 - this covered pretty well the time it _actually_ took them. Then I added a 15% "fuzz factor" to cover for still unexpected surprises. Multiply that by the number of engineers really needed for the project, and you get a reasonable ballpark estimate of how long in walltime the project would take, as well as how much effort it would require. And because every single client was always haggling with the estimates, trying to turn them into hard deadlines... I added another +30% on top. We all knew that was the haggling headroom, and expected the salespople and clients to eventually carve that one out. Our projects were mostly on time and within budget. Yup - mostly. TL;DR: please do not try the above at home or at work. Those figures worked for a very specific company, for their highly specific projects.