5 ms·

Nothing interesting in the article at all, I have no idea why it is on the front page of HN. As usual with software estimation, unless you've read this paper:

Nothing interesting in the article at all, I have no idea why it is on the front page of HN. As usual with software estimation, unless you've read this paper: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.344 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.3... and have a thoughtful response to it (of which I've read some solid ones), I've very little interest in hearing what you have to say about software estimation.

diiq 5y ago
1) The big if is written out in the abstract -- "if it is accepted that algorithmic complexity is an appropriate definition of the complexity of a programming project." Relating algorithmic complexity to "how long software takes to write" seems, to me, to ignore that the vast majority of my time as a developer is spent discovering and communicating requirements, handling human questions, not writing novel code. The conclusion touches on this, but ignores it. 2) Even if you accept that "if", this is like a halting-problem proof. Fine; it is impossible to estimate the complexity of ALL software. That does not mean that it's useless to quantify the complexity of software in limited but well-behaved problem spaces. How much of any commercial project is actually spent working on the cutting edge of computer science, facing complete unknowns? An estimate being wrong occasionally is worth most estimates being mostly right. 3) Why do you consider a 20 year old paper that's only been cited 16 times to be critical reading about estimation, when a vast body of research in forecasting exists, written by people who have measurements of the accuracy of estimates to base their theoretical models on?
- gilbetron 5y ago
  > 3) Why do you consider a 20 year old paper that's only been cited 16 times to be critical reading about estimation, when a vast body of research in forecasting exists, written by people who have measurements of the accuracy of estimates to base their theoretical models on? Have some links to this vast body? I've encountered very few over the years that actually qualify as "science" as much of it is fake or close to fake. http://shape-of-code.coding-guidelines.com/2021/01/17/software-effort-estimation-is-mostly-fake-research/ http://shape-of-code.coding-guidelines.com/2021/01/17/softwa...
  - diiq 5y ago
    Forty volumes of the "Journal of Forecasting" would be a place to start for peer-reviewed articles, I guess https://onlinelibrary.wiley.com/toc/1099131x/current https://onlinelibrary.wiley.com/toc/1099131x/current
    - diiq 5y ago
      I suppose if you consider software to be somehow magically different than all the other human activities which go over-time or over-budget, maybe you could claim that research doesn't apply. But I guess I'd still expect you to know about the fundamentals of the multiple researched approaches to getting experts to predict accurate numbers in the face of uncertainty and social pressure, before deciding to discount it entirely for our specific field. But it's certainly made a big difference for me in practice, and given the gushing about Steve McConnell in another comment thread, I'm not alone.
codemac 5y ago
That paper makes such a huge, and largely incorrect assumption in the abstract. I've never seen anyone make this argument. The old parable about bugs, that it's 10x harder to fix a bug than it is to write the bug, shows us that the time to implement something complex is not related to it's complexity. For example, if I wanted to build something that randomly selects a function from github, and then runs that code on your laptop - I bet I could estimate and implement that code.. but good luck every defining it's features, complexity, etc in any mathematical way. But you don't need to define things that way to have reasonable estimates, for the same reason that when you build a shed in your yard, you don't need to understand all the physics of how it's held up.

diiq 5y ago

1) The big if is written out in the abstract -- "if it is accepted that algorithmic complexity is an appropriate definition of the complexity of a programming project." Relating algorithmic complexity to "how long software takes to write" seems, to me, to ignore that the vast majority of my time as a developer is spent discovering and communicating requirements, handling human questions, not writing novel code. The conclusion touches on this, but ignores it. 2) Even if you accept that "if", this is like a halting-problem proof. Fine; it is impossible to estimate the complexity of ALL software. That does not mean that it's useless to quantify the complexity of software in limited but well-behaved problem spaces. How much of any commercial project is actually spent working on the cutting edge of computer science, facing complete unknowns? An estimate being wrong occasionally is worth most estimates being mostly right. 3) Why do you consider a 20 year old paper that's only been cited 16 times to be critical reading about estimation, when a vast body of research in forecasting exists, written by people who have measurements of the accuracy of estimates to base their theoretical models on?

gilbetron 5y ago
> 3) Why do you consider a 20 year old paper that's only been cited 16 times to be critical reading about estimation, when a vast body of research in forecasting exists, written by people who have measurements of the accuracy of estimates to base their theoretical models on? Have some links to this vast body? I've encountered very few over the years that actually qualify as "science" as much of it is fake or close to fake. http://shape-of-code.coding-guidelines.com/2021/01/17/software-effort-estimation-is-mostly-fake-research/ http://shape-of-code.coding-guidelines.com/2021/01/17/softwa...
- diiq 5y ago
  Forty volumes of the "Journal of Forecasting" would be a place to start for peer-reviewed articles, I guess https://onlinelibrary.wiley.com/toc/1099131x/current https://onlinelibrary.wiley.com/toc/1099131x/current
  - diiq 5y ago
    I suppose if you consider software to be somehow magically different than all the other human activities which go over-time or over-budget, maybe you could claim that research doesn't apply. But I guess I'd still expect you to know about the fundamentals of the multiple researched approaches to getting experts to predict accurate numbers in the face of uncertainty and social pressure, before deciding to discount it entirely for our specific field. But it's certainly made a big difference for me in practice, and given the gushing about Steve McConnell in another comment thread, I'm not alone.

codemac 5y ago

That paper makes such a huge, and largely incorrect assumption in the abstract. I've never seen anyone make this argument. The old parable about bugs, that it's 10x harder to fix a bug than it is to write the bug, shows us that the time to implement something complex is not related to it's complexity. For example, if I wanted to build something that randomly selects a function from github, and then runs that code on your laptop - I bet I could estimate and implement that code.. but good luck every defining it's features, complexity, etc in any mathematical way. But you don't need to define things that way to have reasonable estimates, for the same reason that when you build a shed in your yard, you don't need to understand all the physics of how it's held up.