4 ms·

I'm not a believer in what you're saying, but I dearly want to believe, in no small part because there are significant organizational rewards to be reaped for b

by maxaf 10y ago

I'm not a believer in what you're saying, but I dearly want to believe, in no small part because there are significant organizational rewards to be reaped for believing in estimates and acting the part. What are these rigorous techniques you speak of? I seriously, honestly want to know.

cpitman 10y ago
The book I linked up above is one of the best I've read on software estimation. It's short, it covers exactly the problems we run into everyday (managers take estimates to mean commitments, optimism on most estimates, constant pressure to reduce estimates because they cannot be defended, etc). And it covers several different estimation methods that you can choose from based on circumstances, the pros and cons of each, etc. It's "Software Estimation: Demystifying the Black Art" by Steve McConnell (https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDMPOVQ&preview=newtab&linkCode=kpe&ref_=cm_sw_r_kb_dp_kE5KxbAPDNJB5 https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDM...). Same author as "Code Complete" and "Rapid Development", which are also great books but much longer and showing their age a little more.
- maxaf 10y ago
  Thanks! I'm going to give it a read.
HeyLaughingBoy 10y ago
First, I second (heh!) his book recommendation. Second, in estimation, previous performance is often indicative of future performance. If something took you X days before, it will likely take you roughly X days next year. It's not likely to take 10X the time. The real problem is that very few teams actually track their time on task accurately so no one on the team knows what X was. Without that data, trying to get accurate estimates is a waste of time. A very large part of the problem is that most developers are educated in Computer Science or other areas and simply haven't been trained in estimation techniques. Software Engineering is about the process side of development, and one of the benefits of process is predictability.

by maxaf 10y ago

cpitman 10y ago

The book I linked up above is one of the best I've read on software estimation. It's short, it covers exactly the problems we run into everyday (managers take estimates to mean commitments, optimism on most estimates, constant pressure to reduce estimates because they cannot be defended, etc). And it covers several different estimation methods that you can choose from based on circumstances, the pros and cons of each, etc. It's "Software Estimation: Demystifying the Black Art" by Steve McConnell (https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDMPOVQ&preview=newtab&linkCode=kpe&ref_=cm_sw_r_kb_dp_kE5KxbAPDNJB5 https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDM...). Same author as "Code Complete" and "Rapid Development", which are also great books but much longer and showing their age a little more.

maxaf 10y ago
Thanks! I'm going to give it a read.

HeyLaughingBoy 10y ago

First, I second (heh!) his book recommendation. Second, in estimation, previous performance is often indicative of future performance. If something took you X days before, it will likely take you roughly X days next year. It's not likely to take 10X the time. The real problem is that very few teams actually track their time on task accurately so no one on the team knows what X was. Without that data, trying to get accurate estimates is a waste of time. A very large part of the problem is that most developers are educated in Computer Science or other areas and simply haven't been trained in estimation techniques. Software Engineering is about the process side of development, and one of the benefits of process is predictability.