3 ms·

> The best you can do is estimate based on historical metrics which ... is not worth very much. I've had significant success in using historical metrics to acc

> The best you can do is estimate based on historical metrics which ... is not worth very much. I've had significant success in using historical metrics to accurately estimate software projects. It takes diligence and professional experience to learn to do this, but it is possible in my experience. Unfortunately I find this philistine sentiment quite frequently in the software world: "I've had difficulty doing X. I am smart. I am senior. I am a professional. Therefore X must be impossible." Isn't it possible you haven't been stubborn/hard-working enough in your own personal growth?

avasylev 10y ago
Could you share more details on how you used historic estimates? You basically described me. I've never found historic estimates useful in practice, of course I haven't tried to hard, but over the years can't think even single case I'd find useful to use some old estimate.
- wazoox 10y ago
  That's quite simple, really. If you've carefully tracked your past projects, by comparing tasks from the planned project to those you've done of similar complexity you can make more realistic estimations. It works best on a long-running project. When you plan a new feature, you can gauge really accurately at what speed your current team developed a feature of comparable complexity, so as you go forward you get better and better estimates. Joel Spolsky explained it there: http://www.joelonsoftware.com/items/2007/10/26.html http://www.joelonsoftware.com/items/2007/10/26.html
- HeyLaughingBoy 10y ago
  I know, for example, that under a certain annoying development process coughPSPcough, I will produce code at a rate of 30 LOC/hour when measured from initial requirements gathering through handing code off to testers. I know this because every line of code I've written (using that company's process) for years has been measured and timed. So now the estimation process becomes a matter of figuring out how many LOC (as a proxy for effort) a given feature/project will be and then dividing that number by 30. It is scarily accurate, but like I said, it's been aggregated over thousands of lines of code for years.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

avasylev 10y ago

Could you share more details on how you used historic estimates? You basically described me. I've never found historic estimates useful in practice, of course I haven't tried to hard, but over the years can't think even single case I'd find useful to use some old estimate.

wazoox 10y ago
That's quite simple, really. If you've carefully tracked your past projects, by comparing tasks from the planned project to those you've done of similar complexity you can make more realistic estimations. It works best on a long-running project. When you plan a new feature, you can gauge really accurately at what speed your current team developed a feature of comparable complexity, so as you go forward you get better and better estimates. Joel Spolsky explained it there: http://www.joelonsoftware.com/items/2007/10/26.html http://www.joelonsoftware.com/items/2007/10/26.html
HeyLaughingBoy 10y ago
I know, for example, that under a certain annoying development process coughPSPcough, I will produce code at a rate of 30 LOC/hour when measured from initial requirements gathering through handing code off to testers. I know this because every line of code I've written (using that company's process) for years has been measured and timed. So now the estimation process becomes a matter of figuring out how many LOC (as a proxy for effort) a given feature/project will be and then dividing that number by 30. It is scarily accurate, but like I said, it's been aggregated over thousands of lines of code for years.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]