<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_02_09_1654200</id>
	<title>How Do You Accurately Estimate Programming Time?</title>
	<author>Soulskill</author>
	<datestamp>1265739060000</datestamp>
	<htmltext>itwbennett writes <i>"It can take a fairly stable team of programmers as long as six months to get to a point where they're <a href="http://www.itworld.com/it-managementstrategy/95770/estimating-programming-time">estimating programming time fairly close to actuals</a>, says Suvro Upadhyaya, a Senior Software Engineer at Oracle. Accurately estimating programming time is a process of defining limitations, he says. The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization. Upadhyaya uses <a href="http://en.wikipedia.org/wiki/Scrum\_(development)">Scrum</a> to estimate programming time. How do you do it?"</i></htmltext>
<tokenext>itwbennett writes " It can take a fairly stable team of programmers as long as six months to get to a point where they 're estimating programming time fairly close to actuals , says Suvro Upadhyaya , a Senior Software Engineer at Oracle .
Accurately estimating programming time is a process of defining limitations , he says .
The programmers ' experience , domain knowledge , and speed vs. quality all come into play , and it is highly dependent upon the culture of the team/organization .
Upadhyaya uses Scrum to estimate programming time .
How do you do it ?
"</tokentext>
<sentencetext>itwbennett writes "It can take a fairly stable team of programmers as long as six months to get to a point where they're estimating programming time fairly close to actuals, says Suvro Upadhyaya, a Senior Software Engineer at Oracle.
Accurately estimating programming time is a process of defining limitations, he says.
The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization.
Upadhyaya uses Scrum to estimate programming time.
How do you do it?
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31085276</id>
	<title>Using Data From Previous Similar Projects</title>
	<author>Cardhu</author>
	<datestamp>1265038020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The typical practice I've seen and used is cost modeling based on similar projects in the past.</p><p>One company I worked for used parametric modeling with SEER-SEM.  That was the most reliable, accurate, and precise method I've ever seen.</p></htmltext>
<tokenext>The typical practice I 've seen and used is cost modeling based on similar projects in the past.One company I worked for used parametric modeling with SEER-SEM .
That was the most reliable , accurate , and precise method I 've ever seen .</tokentext>
<sentencetext>The typical practice I've seen and used is cost modeling based on similar projects in the past.One company I worked for used parametric modeling with SEER-SEM.
That was the most reliable, accurate, and precise method I've ever seen.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076204</id>
	<title>This has already been worked out in</title>
	<author>Dunbal</author>
	<datestamp>1265746380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The same as the construction industry. It will be done in "two weeks".</p></htmltext>
<tokenext>The same as the construction industry .
It will be done in " two weeks " .</tokentext>
<sentencetext>The same as the construction industry.
It will be done in "two weeks".</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078504</id>
	<title>Depends on who is doing the estimating.</title>
	<author>Hylandr</author>
	<datestamp>1265712240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Company president or management:: 15 minutes.<br> <br>

Engineering or Marketing: 2 Weeks. <br> <br>

Programmer or SysAdmin: When it's done. <br> <br>

Customer or end user: When it works.<br> <br>

Here's the advert to give to your HR department to hire the person for your 'estimating':<br> <br>

Looking for a BS or AS in the latest trendy programming languages developed by college students in their second year. Must have experience in legacy hardware as the most recent vapor-ware that everyone is buzz-wording about. Non-Discriminatory Affirmative action candidates preferred with background clearances and able to board an airline with a weapon. - Equal Opportunity Employer<br> <br>

- Dan.</htmltext>
<tokenext>Company president or management : : 15 minutes .
Engineering or Marketing : 2 Weeks .
Programmer or SysAdmin : When it 's done .
Customer or end user : When it works .
Here 's the advert to give to your HR department to hire the person for your 'estimating ' : Looking for a BS or AS in the latest trendy programming languages developed by college students in their second year .
Must have experience in legacy hardware as the most recent vapor-ware that everyone is buzz-wording about .
Non-Discriminatory Affirmative action candidates preferred with background clearances and able to board an airline with a weapon .
- Equal Opportunity Employer - Dan .</tokentext>
<sentencetext>Company president or management:: 15 minutes.
Engineering or Marketing: 2 Weeks.
Programmer or SysAdmin: When it's done.
Customer or end user: When it works.
Here's the advert to give to your HR department to hire the person for your 'estimating': 

Looking for a BS or AS in the latest trendy programming languages developed by college students in their second year.
Must have experience in legacy hardware as the most recent vapor-ware that everyone is buzz-wording about.
Non-Discriminatory Affirmative action candidates preferred with background clearances and able to board an airline with a weapon.
- Equal Opportunity Employer 

- Dan.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076782</id>
	<title>Re:This is what I usually do.</title>
	<author>shock1970</author>
	<datestamp>1265748720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've used that exact same methodology, but I've taken it to the next level...</p><p>I throw out the number completely, then pass the script into an application development program, and voila, finished project in exactly the amount of time it took me to write the script</p></htmltext>
<tokenext>I 've used that exact same methodology , but I 've taken it to the next level...I throw out the number completely , then pass the script into an application development program , and voila , finished project in exactly the amount of time it took me to write the script</tokentext>
<sentencetext>I've used that exact same methodology, but I've taken it to the next level...I throw out the number completely, then pass the script into an application development program, and voila, finished project in exactly the amount of time it took me to write the script</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079696</id>
	<title>My Way</title>
	<author>Island Admin</author>
	<datestamp>1265717580000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>my $quality = 100; <br>
my $initial\_project\_time = length($piece\_of\_string) / ($count\_programmers);<br>
my $real\_project\_time = ($initial\_project\_time + ($scope\_creep\_time * $count\_non\_it\_business\_staff)) * $3.14;<br> <br>

if ($slave\_driving\_boss eq "yes") {<br>
$real\_project\_time = $real\_project\_time / 2.5;<br>
$quality = 60;<br>
$bugs = random;<br>
}</htmltext>
<tokenext>my $ quality = 100 ; my $ initial \ _project \ _time = length ( $ piece \ _of \ _string ) / ( $ count \ _programmers ) ; my $ real \ _project \ _time = ( $ initial \ _project \ _time + ( $ scope \ _creep \ _time * $ count \ _non \ _it \ _business \ _staff ) ) * $ 3.14 ; if ( $ slave \ _driving \ _boss eq " yes " ) { $ real \ _project \ _time = $ real \ _project \ _time / 2.5 ; $ quality = 60 ; $ bugs = random ; }</tokentext>
<sentencetext>my $quality = 100; 
my $initial\_project\_time = length($piece\_of\_string) / ($count\_programmers);
my $real\_project\_time = ($initial\_project\_time + ($scope\_creep\_time * $count\_non\_it\_business\_staff)) * $3.14; 

if ($slave\_driving\_boss eq "yes") {
$real\_project\_time = $real\_project\_time / 2.5;
$quality = 60;
$bugs = random;
}</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076476</id>
	<title>Usually involves numbers from a sphinter...</title>
	<author>Fallen Kell</author>
	<datestamp>1265747520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>no text</htmltext>
<tokenext>no text</tokentext>
<sentencetext>no text</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076818</id>
	<title>Re:Chop features.</title>
	<author>fedos</author>
	<datestamp>1265748900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I am a cost estimator for an organization that contracts out development, I have never been employed in software development. Instead of asking how long it will take, we use parametric tools to estimate development schedules (including design, implementation, and test). We get estimates of the size and complexity of the software and then use a tool such as SEER-SEM or PRICE TruePlanning to estimate time for each phase of development. These tools can be calibrated to your organization's past performance and also provide risk analysis.</p><p>Does anyone use these tools outside of the cost estimating community?</p></htmltext>
<tokenext>I am a cost estimator for an organization that contracts out development , I have never been employed in software development .
Instead of asking how long it will take , we use parametric tools to estimate development schedules ( including design , implementation , and test ) .
We get estimates of the size and complexity of the software and then use a tool such as SEER-SEM or PRICE TruePlanning to estimate time for each phase of development .
These tools can be calibrated to your organization 's past performance and also provide risk analysis.Does anyone use these tools outside of the cost estimating community ?</tokentext>
<sentencetext>I am a cost estimator for an organization that contracts out development, I have never been employed in software development.
Instead of asking how long it will take, we use parametric tools to estimate development schedules (including design, implementation, and test).
We get estimates of the size and complexity of the software and then use a tool such as SEER-SEM or PRICE TruePlanning to estimate time for each phase of development.
These tools can be calibrated to your organization's past performance and also provide risk analysis.Does anyone use these tools outside of the cost estimating community?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077686</id>
	<title>Meh...</title>
	<author>Snarkalicious</author>
	<datestamp>1265709180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Find out the liscencing cost for somebody else's implementation, get your budget written for 30\% over that, buy the damn thing and get your ass to Maui. Quote two weeks on your way out the door and tell them you'll be coding it at home.</div>
	</htmltext>
<tokenext>Find out the liscencing cost for somebody else 's implementation , get your budget written for 30 \ % over that , buy the damn thing and get your ass to Maui .
Quote two weeks on your way out the door and tell them you 'll be coding it at home .</tokentext>
<sentencetext>Find out the liscencing cost for somebody else's implementation, get your budget written for 30\% over that, buy the damn thing and get your ass to Maui.
Quote two weeks on your way out the door and tell them you'll be coding it at home.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076214</id>
	<title>Re:Quid pro quo</title>
	<author>Bruiser80</author>
	<datestamp>1265746440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Bravo!
<br> <br>
I'm a mechanical design engineer who has to quote my work. The initial quote is most likely blown away when the customer comes back with more changes than budgeted in concept phase, and brings changes again when we're past "the point of no return".
<br> <br>
Oh how I miss the days of desparate customers willing to pay Time and Materials... sigh</div>
	</htmltext>
<tokenext>Bravo !
I 'm a mechanical design engineer who has to quote my work .
The initial quote is most likely blown away when the customer comes back with more changes than budgeted in concept phase , and brings changes again when we 're past " the point of no return " .
Oh how I miss the days of desparate customers willing to pay Time and Materials... sigh</tokentext>
<sentencetext>Bravo!
I'm a mechanical design engineer who has to quote my work.
The initial quote is most likely blown away when the customer comes back with more changes than budgeted in concept phase, and brings changes again when we're past "the point of no return".
Oh how I miss the days of desparate customers willing to pay Time and Materials... sigh
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076978</id>
	<title>This is a solved problem ;)</title>
	<author>Anonymous</author>
	<datestamp>1265706180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just follow the government's guide book and you will hit the right number every time:</p><p>http://www.stsc.hill.af.mil/consulting/sw\_estimation/SoftwareGuidebook.pdf</p><p>I am only half joking.  I have witnessed several 12 to 25 Million Dollar software projects finish within five figures of the original estimates.  The key is accurate historical data on which to base estimates.</p><p>1) Keep Task Descriptions (TDs) and Actual hours consumed working the tasks on past (historical) projects<br>2) Compare new project's task descriptions to historical task descriptions.<br>3) Sum the hours from the relevant historical tasks and make minor adjustments due to slight differences in tasks (Historical Basis of Estimate)<br>4) Multiply sum of hours times current labor rates to compute Cost for TD/BoEs and add a small reserve for the unforeseen<br>5) Multiply Cost of TD/BoEs times desired Fee to compute Price<br>6) Profit</p><p>I was skeptic too, but I have seen it work many times.</p></htmltext>
<tokenext>Just follow the government 's guide book and you will hit the right number every time : http : //www.stsc.hill.af.mil/consulting/sw \ _estimation/SoftwareGuidebook.pdfI am only half joking .
I have witnessed several 12 to 25 Million Dollar software projects finish within five figures of the original estimates .
The key is accurate historical data on which to base estimates.1 ) Keep Task Descriptions ( TDs ) and Actual hours consumed working the tasks on past ( historical ) projects2 ) Compare new project 's task descriptions to historical task descriptions.3 ) Sum the hours from the relevant historical tasks and make minor adjustments due to slight differences in tasks ( Historical Basis of Estimate ) 4 ) Multiply sum of hours times current labor rates to compute Cost for TD/BoEs and add a small reserve for the unforeseen5 ) Multiply Cost of TD/BoEs times desired Fee to compute Price6 ) ProfitI was skeptic too , but I have seen it work many times .</tokentext>
<sentencetext>Just follow the government's guide book and you will hit the right number every time:http://www.stsc.hill.af.mil/consulting/sw\_estimation/SoftwareGuidebook.pdfI am only half joking.
I have witnessed several 12 to 25 Million Dollar software projects finish within five figures of the original estimates.
The key is accurate historical data on which to base estimates.1) Keep Task Descriptions (TDs) and Actual hours consumed working the tasks on past (historical) projects2) Compare new project's task descriptions to historical task descriptions.3) Sum the hours from the relevant historical tasks and make minor adjustments due to slight differences in tasks (Historical Basis of Estimate)4) Multiply sum of hours times current labor rates to compute Cost for TD/BoEs and add a small reserve for the unforeseen5) Multiply Cost of TD/BoEs times desired Fee to compute Price6) ProfitI was skeptic too, but I have seen it work many times.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075518</id>
	<title>Schedules are complex</title>
	<author>plost</author>
	<datestamp>1265744160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Software schedules are complex.  There's a real part and there's an imaginary part.</htmltext>
<tokenext>Software schedules are complex .
There 's a real part and there 's an imaginary part .</tokentext>
<sentencetext>Software schedules are complex.
There's a real part and there's an imaginary part.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082714</id>
	<title>Every project of significance takes a year</title>
	<author>crispytwo</author>
	<datestamp>1265054760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It can take more, but if it is a full system with design, implementation and delivery, a year is a good rule of thumb.</p><p>Projects that include external clients always go slower than internal clients, but not by much. Meetings are delayed, features are dreamed up/changed, and requirements drift ("I meant X not Y -- didn't I say X? [no]"). Sales people want to talk about change management and well defined specs, but those are much more rare than you might think. Of the many many dozens of projects I've worked on, I can safely say only 2 were well spec'd.</p><p>I agree with the "estimate and multiply by pi" for the sub components of a full project, but the unspecified, "we want to do something like X" is going to be a long process... never forget the acceptance testing and debugging near the end, and maintenance after it's delivered. Oh ya, holidays. That can get you too.</p><p>However, small, well understood projects are easier to estimate and plan. If you've done something before, and it took 2 weeks to implement, it will take 2 weeks to implement -- 1 week to remember WTF you did last time and 1 week to do it again... If you remember WTF you did last time, you probably didn't do enough the first time.</p></htmltext>
<tokenext>It can take more , but if it is a full system with design , implementation and delivery , a year is a good rule of thumb.Projects that include external clients always go slower than internal clients , but not by much .
Meetings are delayed , features are dreamed up/changed , and requirements drift ( " I meant X not Y -- did n't I say X ?
[ no ] " ) . Sales people want to talk about change management and well defined specs , but those are much more rare than you might think .
Of the many many dozens of projects I 've worked on , I can safely say only 2 were well spec 'd.I agree with the " estimate and multiply by pi " for the sub components of a full project , but the unspecified , " we want to do something like X " is going to be a long process... never forget the acceptance testing and debugging near the end , and maintenance after it 's delivered .
Oh ya , holidays .
That can get you too.However , small , well understood projects are easier to estimate and plan .
If you 've done something before , and it took 2 weeks to implement , it will take 2 weeks to implement -- 1 week to remember WTF you did last time and 1 week to do it again... If you remember WTF you did last time , you probably did n't do enough the first time .</tokentext>
<sentencetext>It can take more, but if it is a full system with design, implementation and delivery, a year is a good rule of thumb.Projects that include external clients always go slower than internal clients, but not by much.
Meetings are delayed, features are dreamed up/changed, and requirements drift ("I meant X not Y -- didn't I say X?
[no]"). Sales people want to talk about change management and well defined specs, but those are much more rare than you might think.
Of the many many dozens of projects I've worked on, I can safely say only 2 were well spec'd.I agree with the "estimate and multiply by pi" for the sub components of a full project, but the unspecified, "we want to do something like X" is going to be a long process... never forget the acceptance testing and debugging near the end, and maintenance after it's delivered.
Oh ya, holidays.
That can get you too.However, small, well understood projects are easier to estimate and plan.
If you've done something before, and it took 2 weeks to implement, it will take 2 weeks to implement -- 1 week to remember WTF you did last time and 1 week to do it again... If you remember WTF you did last time, you probably didn't do enough the first time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075956</id>
	<title>Controlling Software Projects</title>
	<author>Oloryn</author>
	<datestamp>1265745600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Take a look at Tom DeMarco's <a href="http://www.amazon.com/Controlling-Software-Projects-Management-Measurement/dp/0131717111" title="amazon.com">Controlling Software Projects</a> [amazon.com].  He deals with the issues behind estimating (including that one of the reasons we're so bad at estimating is that we get so little practice - much of what we call "estimating" is actually deadline negotiating).  He ends up suggesting a separate measuring and estimating team - probably out of bounds except for fairly large companies, but the book has some good insights.</htmltext>
<tokenext>Take a look at Tom DeMarco 's Controlling Software Projects [ amazon.com ] .
He deals with the issues behind estimating ( including that one of the reasons we 're so bad at estimating is that we get so little practice - much of what we call " estimating " is actually deadline negotiating ) .
He ends up suggesting a separate measuring and estimating team - probably out of bounds except for fairly large companies , but the book has some good insights .</tokentext>
<sentencetext>Take a look at Tom DeMarco's Controlling Software Projects [amazon.com].
He deals with the issues behind estimating (including that one of the reasons we're so bad at estimating is that we get so little practice - much of what we call "estimating" is actually deadline negotiating).
He ends up suggesting a separate measuring and estimating team - probably out of bounds except for fairly large companies, but the book has some good insights.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076270</id>
	<title>Accurately according to who?</title>
	<author>TehBrando</author>
	<datestamp>1265746620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Most of the time I'll guess until the business I am developing the software for agrees with my estimate. Seems if they don't like my estimate the first week, they ask for a new estimate the week after or even a day later to try and get a lower number.</htmltext>
<tokenext>Most of the time I 'll guess until the business I am developing the software for agrees with my estimate .
Seems if they do n't like my estimate the first week , they ask for a new estimate the week after or even a day later to try and get a lower number .</tokentext>
<sentencetext>Most of the time I'll guess until the business I am developing the software for agrees with my estimate.
Seems if they don't like my estimate the first week, they ask for a new estimate the week after or even a day later to try and get a lower number.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075102</id>
	<title>Blindfold and dartboard</title>
	<author>91degrees</author>
	<datestamp>1265742900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Write down all the possible times on bits of paper.  Put on blindfold.  Throw darts.  There's your estimate.  I'm consistently getting more accurate times than any other method.</htmltext>
<tokenext>Write down all the possible times on bits of paper .
Put on blindfold .
Throw darts .
There 's your estimate .
I 'm consistently getting more accurate times than any other method .</tokentext>
<sentencetext>Write down all the possible times on bits of paper.
Put on blindfold.
Throw darts.
There's your estimate.
I'm consistently getting more accurate times than any other method.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075118</id>
	<title>There's a hard way and an easy way.</title>
	<author>Anonymous</author>
	<datestamp>1265742900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>How do you do it?"</p></div><p>Equivocally. Like everyone else</p></div>
	</htmltext>
<tokenext>How do you do it ? " Equivocally .
Like everyone else</tokentext>
<sentencetext>How do you do it?"Equivocally.
Like everyone else
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075082</id>
	<title>Specs</title>
	<author>TheTick21</author>
	<datestamp>1265742780000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>For me it really depends on how accurately they spec it out. If it is a general idea I can be an order of magnitude off easily. If it is a very accurate spec and needs little change throughout then I tend to be pretty accurate.</p></htmltext>
<tokenext>For me it really depends on how accurately they spec it out .
If it is a general idea I can be an order of magnitude off easily .
If it is a very accurate spec and needs little change throughout then I tend to be pretty accurate .</tokentext>
<sentencetext>For me it really depends on how accurately they spec it out.
If it is a general idea I can be an order of magnitude off easily.
If it is a very accurate spec and needs little change throughout then I tend to be pretty accurate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082658</id>
	<title>Re:Chop features.</title>
	<author>Kjella</author>
	<datestamp>1265745300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Have you ever asked which feature has the highest priority, and received the answer, "all of them"?</p></div><p>"In other words, none of them"</p></div>
	</htmltext>
<tokenext>Have you ever asked which feature has the highest priority , and received the answer , " all of them " ?
" In other words , none of them "</tokentext>
<sentencetext>Have you ever asked which feature has the highest priority, and received the answer, "all of them"?
"In other words, none of them"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075866</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31084744</id>
	<title>Re:Simply, no software required.</title>
	<author>Twylite</author>
	<datestamp>1265035080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The Weighted average estimate is (T1+(4*T2) + T3)/6</p></div><p>This is the <a href="http://en.wikipedia.org/wiki/Program\_Evaluation\_and\_Review\_Technique" title="wikipedia.org">PERT</a> [wikipedia.org] expected time applied to the project as a whole.  PERT is a great idea <i>especially</i> if you provide your optimistic (T1), pessimistic (T3) and most likely (T2) estimates along with the result T.  In that case you can cite the use of an established estimation technique and CYA as you have provided a clear indication (T3) that the project can miss the target.</p><p>Some things we find very useful:</p><ul>
<li>Break the project into chunks that look like something we've done before, and use PERT to estimate each chunk with respect to the developer mostly likely to do the work.  Ensure that your chunks cover requirements, development, testing, documentation, packaging, configuration/SCM, integration &amp; testing on site and user acceptance testing.</li><li>Construct a scheduling network from the chunks and determine the critical path.  That gives an overall estimate on project effort and linear time.</li><li>Revise the effort and linear time up by 14\% to 33\% reflecting only 6-7 productive hours per 8-hour work day due to non-project overheads (company meetings, general admin, those "quick answers" on maintenance questions or opportunities or complexity estimates).</li><li>Add a further 8\% to 12\% to the revised estimate for quality assurance.  This is over and above the time in each chunk for testing and review.  Even experienced estimators underestimate the time required for their code to be reviewed by other developers.</li><li>Add a further 10\% for risk.  Risk from poor understanding or estimation of the extend of the task is built into each chunk using PERT; this represents risk of an external interruption to the process or to management processes that may impact on the schedule.</li><li>Revise the linear time up by 2-3 days per month, reflecting expected sick leave, annual leave and public holidays of critical path developers.  We have 12 public holidays a year here; your figure may differ.</li><li>The result is the expected linear time to complete the project, assuming no interruptions and the availability of the identified development staff.</li><li>Inflate by 0\% to 30\% when promising a delivery date to customers, depending on the risk associated with late delivery.</li></ul></div>
	</htmltext>
<tokenext>The Weighted average estimate is ( T1 + ( 4 * T2 ) + T3 ) /6This is the PERT [ wikipedia.org ] expected time applied to the project as a whole .
PERT is a great idea especially if you provide your optimistic ( T1 ) , pessimistic ( T3 ) and most likely ( T2 ) estimates along with the result T. In that case you can cite the use of an established estimation technique and CYA as you have provided a clear indication ( T3 ) that the project can miss the target.Some things we find very useful : Break the project into chunks that look like something we 've done before , and use PERT to estimate each chunk with respect to the developer mostly likely to do the work .
Ensure that your chunks cover requirements , development , testing , documentation , packaging , configuration/SCM , integration &amp; testing on site and user acceptance testing.Construct a scheduling network from the chunks and determine the critical path .
That gives an overall estimate on project effort and linear time.Revise the effort and linear time up by 14 \ % to 33 \ % reflecting only 6-7 productive hours per 8-hour work day due to non-project overheads ( company meetings , general admin , those " quick answers " on maintenance questions or opportunities or complexity estimates ) .Add a further 8 \ % to 12 \ % to the revised estimate for quality assurance .
This is over and above the time in each chunk for testing and review .
Even experienced estimators underestimate the time required for their code to be reviewed by other developers.Add a further 10 \ % for risk .
Risk from poor understanding or estimation of the extend of the task is built into each chunk using PERT ; this represents risk of an external interruption to the process or to management processes that may impact on the schedule.Revise the linear time up by 2-3 days per month , reflecting expected sick leave , annual leave and public holidays of critical path developers .
We have 12 public holidays a year here ; your figure may differ.The result is the expected linear time to complete the project , assuming no interruptions and the availability of the identified development staff.Inflate by 0 \ % to 30 \ % when promising a delivery date to customers , depending on the risk associated with late delivery .</tokentext>
<sentencetext>The Weighted average estimate is (T1+(4*T2) + T3)/6This is the PERT [wikipedia.org] expected time applied to the project as a whole.
PERT is a great idea especially if you provide your optimistic (T1), pessimistic (T3) and most likely (T2) estimates along with the result T.  In that case you can cite the use of an established estimation technique and CYA as you have provided a clear indication (T3) that the project can miss the target.Some things we find very useful:
Break the project into chunks that look like something we've done before, and use PERT to estimate each chunk with respect to the developer mostly likely to do the work.
Ensure that your chunks cover requirements, development, testing, documentation, packaging, configuration/SCM, integration &amp; testing on site and user acceptance testing.Construct a scheduling network from the chunks and determine the critical path.
That gives an overall estimate on project effort and linear time.Revise the effort and linear time up by 14\% to 33\% reflecting only 6-7 productive hours per 8-hour work day due to non-project overheads (company meetings, general admin, those "quick answers" on maintenance questions or opportunities or complexity estimates).Add a further 8\% to 12\% to the revised estimate for quality assurance.
This is over and above the time in each chunk for testing and review.
Even experienced estimators underestimate the time required for their code to be reviewed by other developers.Add a further 10\% for risk.
Risk from poor understanding or estimation of the extend of the task is built into each chunk using PERT; this represents risk of an external interruption to the process or to management processes that may impact on the schedule.Revise the linear time up by 2-3 days per month, reflecting expected sick leave, annual leave and public holidays of critical path developers.
We have 12 public holidays a year here; your figure may differ.The result is the expected linear time to complete the project, assuming no interruptions and the availability of the identified development staff.Inflate by 0\% to 30\% when promising a delivery date to customers, depending on the risk associated with late delivery.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075342</id>
	<title>Cart before horse.</title>
	<author>PeanutButterBreath</author>
	<datestamp>1265743560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Typically, the solution is much more malleable than time or budget.  Determine the baseline requirements.  Then determine the resources available (time and money).  The project will likely fill the latter two.  Success should be measured against adherence to the requirements, not time or money saved.</p></htmltext>
<tokenext>Typically , the solution is much more malleable than time or budget .
Determine the baseline requirements .
Then determine the resources available ( time and money ) .
The project will likely fill the latter two .
Success should be measured against adherence to the requirements , not time or money saved .</tokentext>
<sentencetext>Typically, the solution is much more malleable than time or budget.
Determine the baseline requirements.
Then determine the resources available (time and money).
The project will likely fill the latter two.
Success should be measured against adherence to the requirements, not time or money saved.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078934</id>
	<title>too many variables</title>
	<author>Anonymous</author>
	<datestamp>1265714160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Is that including or excluding the time they spend on<nobr> <wbr></nobr>/. ?</p></htmltext>
<tokenext>Is that including or excluding the time they spend on / .
?</tokentext>
<sentencetext>Is that including or excluding the time they spend on /.
?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076894</id>
	<title>"how?" implies that you can</title>
	<author>bzipitidoo</author>
	<datestamp>1265749140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How long will it take for a computer program to halt?

</p><p>Why this constant striving and pushing to predict the possibly unpredictable?  And the demand to have those predictions be 100\% accurate?

</p><p>One of the things that bugged me about school programming assignments was how well behaved they were.  If you were given 2 weeks to do an assignment, you could be pretty sure that's about how long it would take the slower programmers.  The assignment was unlikely to be changed halfway through.  Does school give the false impression that all such work is as predictable?  Management is wont to suspect incompetence or laziness rather than understand that a problem is very hard.

</p><p>Even if you have a well defined problem and well known tools, and you know the problem is not impossible, and that it isn't research into the unknown, you can still have a great deal of uncertainty.  How long will it take to discover the next Mersenne Prime?  Look at how long it took to discover the next ones in the past, starting from the first 2, known around 400 BC when prime numbers were first seen to be interesting.  Maybe 200 years to find 2 more, about 1650 years, to Renaissance times, to find the next one, then 132 years for 2 more, and 184 more years for the next one.  During this time, mathematicians saw that these numbers were interesting, although there was no direct practical use.  The next batch of finds is out of order, illustrating yet another aspect of the unpredictability.  The next discovery was 104 years later, but the next one in order took an additional 13 years.  Then 28 years, and 3 more years for the next two.  After that, it was 38 years, to when a computer was first used on this problem and found 5 more within a year!  In the 58 years since that seminal event, computers have grown vastly more powerful.  Our techniques have also improved in this time.  And we've found uses for prime numbers, namely RSA cryptography.  The result is that we've found 30 more, nearly twice the number that had been found in the previous 2400 years.  Given that rate, we can estimate that the next one will likely be found within the next 2 years.  But maybe not-- maybe there's a huge gap between the largest one currently known and the next one.  In the past it has taken between less than 1 day to over 1600 years.  Immense variation there.  Or maybe we'll discover some magic closed form equation and we can compute as many Mersenne Primes as we want, so there is no longer any need to search at all.

</p><p>Or, why this constant pushing for predictions with information that is much more uncertain than it need be?  When no one even knows what is wanted, predictions are laughable.  Garbage in, garbage out.

</p><p>If I have good specs that have been carefully checked to make sure everything is defined, possible, and practical (sure, it's possible to factor any 1000 digit number, and it might even be very easy, but it might also take a very, very long time, and so not be practical), and I have tools that I know and which do not have any major bugs that must be worked around or fixed, or huge gaps in functionality that must be filled, then I can make a reasonable estimate of how long it will all take.  But you know what?  In the time all that takes, I could be off to a good start.  Even when accurate predictions are possible, they may take a significant percentage of the time it would take to just do it, and so may not be worth doing.

</p><p>Naturally, the closer a project is to done, the better the estimates can be.</p></htmltext>
<tokenext>How long will it take for a computer program to halt ?
Why this constant striving and pushing to predict the possibly unpredictable ?
And the demand to have those predictions be 100 \ % accurate ?
One of the things that bugged me about school programming assignments was how well behaved they were .
If you were given 2 weeks to do an assignment , you could be pretty sure that 's about how long it would take the slower programmers .
The assignment was unlikely to be changed halfway through .
Does school give the false impression that all such work is as predictable ?
Management is wont to suspect incompetence or laziness rather than understand that a problem is very hard .
Even if you have a well defined problem and well known tools , and you know the problem is not impossible , and that it is n't research into the unknown , you can still have a great deal of uncertainty .
How long will it take to discover the next Mersenne Prime ?
Look at how long it took to discover the next ones in the past , starting from the first 2 , known around 400 BC when prime numbers were first seen to be interesting .
Maybe 200 years to find 2 more , about 1650 years , to Renaissance times , to find the next one , then 132 years for 2 more , and 184 more years for the next one .
During this time , mathematicians saw that these numbers were interesting , although there was no direct practical use .
The next batch of finds is out of order , illustrating yet another aspect of the unpredictability .
The next discovery was 104 years later , but the next one in order took an additional 13 years .
Then 28 years , and 3 more years for the next two .
After that , it was 38 years , to when a computer was first used on this problem and found 5 more within a year !
In the 58 years since that seminal event , computers have grown vastly more powerful .
Our techniques have also improved in this time .
And we 've found uses for prime numbers , namely RSA cryptography .
The result is that we 've found 30 more , nearly twice the number that had been found in the previous 2400 years .
Given that rate , we can estimate that the next one will likely be found within the next 2 years .
But maybe not-- maybe there 's a huge gap between the largest one currently known and the next one .
In the past it has taken between less than 1 day to over 1600 years .
Immense variation there .
Or maybe we 'll discover some magic closed form equation and we can compute as many Mersenne Primes as we want , so there is no longer any need to search at all .
Or , why this constant pushing for predictions with information that is much more uncertain than it need be ?
When no one even knows what is wanted , predictions are laughable .
Garbage in , garbage out .
If I have good specs that have been carefully checked to make sure everything is defined , possible , and practical ( sure , it 's possible to factor any 1000 digit number , and it might even be very easy , but it might also take a very , very long time , and so not be practical ) , and I have tools that I know and which do not have any major bugs that must be worked around or fixed , or huge gaps in functionality that must be filled , then I can make a reasonable estimate of how long it will all take .
But you know what ?
In the time all that takes , I could be off to a good start .
Even when accurate predictions are possible , they may take a significant percentage of the time it would take to just do it , and so may not be worth doing .
Naturally , the closer a project is to done , the better the estimates can be .</tokentext>
<sentencetext>How long will it take for a computer program to halt?
Why this constant striving and pushing to predict the possibly unpredictable?
And the demand to have those predictions be 100\% accurate?
One of the things that bugged me about school programming assignments was how well behaved they were.
If you were given 2 weeks to do an assignment, you could be pretty sure that's about how long it would take the slower programmers.
The assignment was unlikely to be changed halfway through.
Does school give the false impression that all such work is as predictable?
Management is wont to suspect incompetence or laziness rather than understand that a problem is very hard.
Even if you have a well defined problem and well known tools, and you know the problem is not impossible, and that it isn't research into the unknown, you can still have a great deal of uncertainty.
How long will it take to discover the next Mersenne Prime?
Look at how long it took to discover the next ones in the past, starting from the first 2, known around 400 BC when prime numbers were first seen to be interesting.
Maybe 200 years to find 2 more, about 1650 years, to Renaissance times, to find the next one, then 132 years for 2 more, and 184 more years for the next one.
During this time, mathematicians saw that these numbers were interesting, although there was no direct practical use.
The next batch of finds is out of order, illustrating yet another aspect of the unpredictability.
The next discovery was 104 years later, but the next one in order took an additional 13 years.
Then 28 years, and 3 more years for the next two.
After that, it was 38 years, to when a computer was first used on this problem and found 5 more within a year!
In the 58 years since that seminal event, computers have grown vastly more powerful.
Our techniques have also improved in this time.
And we've found uses for prime numbers, namely RSA cryptography.
The result is that we've found 30 more, nearly twice the number that had been found in the previous 2400 years.
Given that rate, we can estimate that the next one will likely be found within the next 2 years.
But maybe not-- maybe there's a huge gap between the largest one currently known and the next one.
In the past it has taken between less than 1 day to over 1600 years.
Immense variation there.
Or maybe we'll discover some magic closed form equation and we can compute as many Mersenne Primes as we want, so there is no longer any need to search at all.
Or, why this constant pushing for predictions with information that is much more uncertain than it need be?
When no one even knows what is wanted, predictions are laughable.
Garbage in, garbage out.
If I have good specs that have been carefully checked to make sure everything is defined, possible, and practical (sure, it's possible to factor any 1000 digit number, and it might even be very easy, but it might also take a very, very long time, and so not be practical), and I have tools that I know and which do not have any major bugs that must be worked around or fixed, or huge gaps in functionality that must be filled, then I can make a reasonable estimate of how long it will all take.
But you know what?
In the time all that takes, I could be off to a good start.
Even when accurate predictions are possible, they may take a significant percentage of the time it would take to just do it, and so may not be worth doing.
Naturally, the closer a project is to done, the better the estimates can be.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31084438</id>
	<title>Beware black swans</title>
	<author>psysjal</author>
	<datestamp>1265032560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>For any large project read this <a href="http://en.wikipedia.org/wiki/Black\_swan\_theory/" title="wikipedia.org" rel="nofollow">Black swan theory</a> [wikipedia.org]. Something completely unexpected will probably ruin your plan, as others have said it's more about knowing what to chop to hit a date.

Also for any large project the cumulative effect of errors in estimating soon add up to make the plan almost irrelevant.</htmltext>
<tokenext>For any large project read this Black swan theory [ wikipedia.org ] .
Something completely unexpected will probably ruin your plan , as others have said it 's more about knowing what to chop to hit a date .
Also for any large project the cumulative effect of errors in estimating soon add up to make the plan almost irrelevant .</tokentext>
<sentencetext>For any large project read this Black swan theory [wikipedia.org].
Something completely unexpected will probably ruin your plan, as others have said it's more about knowing what to chop to hit a date.
Also for any large project the cumulative effect of errors in estimating soon add up to make the plan almost irrelevant.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082562</id>
	<title>You want an estimate? Pony up an accurate spec.</title>
	<author>buzzn</author>
	<datestamp>1265743440000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>It is to laugh. Developers are never given enough information about what it is they are supposed to deliver. You want a fast sort algorithm? I can do that in, say, less than a week. You want an award winning social networking web site that brings in millions of hits? Might take me, hmmm, a month or two? Maybe more. Oh, please remember to factor in testing and documentation time, people.</htmltext>
<tokenext>It is to laugh .
Developers are never given enough information about what it is they are supposed to deliver .
You want a fast sort algorithm ?
I can do that in , say , less than a week .
You want an award winning social networking web site that brings in millions of hits ?
Might take me , hmmm , a month or two ?
Maybe more .
Oh , please remember to factor in testing and documentation time , people .</tokentext>
<sentencetext>It is to laugh.
Developers are never given enough information about what it is they are supposed to deliver.
You want a fast sort algorithm?
I can do that in, say, less than a week.
You want an award winning social networking web site that brings in millions of hits?
Might take me, hmmm, a month or two?
Maybe more.
Oh, please remember to factor in testing and documentation time, people.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077388</id>
	<title>Re:Exact approximation.</title>
	<author>tool462</author>
	<datestamp>1265707920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The difference between an estimate and a guess is the difference between a climatological model and a groundhog in determining the end of winter.</p></htmltext>
<tokenext>The difference between an estimate and a guess is the difference between a climatological model and a groundhog in determining the end of winter .</tokentext>
<sentencetext>The difference between an estimate and a guess is the difference between a climatological model and a groundhog in determining the end of winter.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075616</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081024</id>
	<title>Evidence based estimating</title>
	<author>sashang</author>
	<datestamp>1265726100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Evidence based estimating is what I'd like to see more of and less of the abracadabra 'story points' rubbish that SCRUM practitioners advocated. At a previous organization we went down the SCRUM road and were told to use story points where a story point is a unit of effort (not time) required to do the task. Naturally all the devs were confused and eventually resorted to equating a story point with a unit of time (like an hour) and not a unit of effort as we were supposed to. There's also the problem were one dev's estimate of say 4 story points is not the same as another dev's estimate of 4 story points. There was never a consensus as to what a 'unit of effort' meant unless it was taken to be equivalent to a unit of time. Evidence based estimating seems to provide a better solution since it tracks the history of an individual dev's estimates, recognising the fact that an individuals estimate will differ from another. So for example if someone has a habit of underestimating a task, because of the feedback that goes into the system after the task is done, the system caters for this when that person makes another estimate.</htmltext>
<tokenext>Evidence based estimating is what I 'd like to see more of and less of the abracadabra 'story points ' rubbish that SCRUM practitioners advocated .
At a previous organization we went down the SCRUM road and were told to use story points where a story point is a unit of effort ( not time ) required to do the task .
Naturally all the devs were confused and eventually resorted to equating a story point with a unit of time ( like an hour ) and not a unit of effort as we were supposed to .
There 's also the problem were one dev 's estimate of say 4 story points is not the same as another dev 's estimate of 4 story points .
There was never a consensus as to what a 'unit of effort ' meant unless it was taken to be equivalent to a unit of time .
Evidence based estimating seems to provide a better solution since it tracks the history of an individual dev 's estimates , recognising the fact that an individuals estimate will differ from another .
So for example if someone has a habit of underestimating a task , because of the feedback that goes into the system after the task is done , the system caters for this when that person makes another estimate .</tokentext>
<sentencetext>Evidence based estimating is what I'd like to see more of and less of the abracadabra 'story points' rubbish that SCRUM practitioners advocated.
At a previous organization we went down the SCRUM road and were told to use story points where a story point is a unit of effort (not time) required to do the task.
Naturally all the devs were confused and eventually resorted to equating a story point with a unit of time (like an hour) and not a unit of effort as we were supposed to.
There's also the problem were one dev's estimate of say 4 story points is not the same as another dev's estimate of 4 story points.
There was never a consensus as to what a 'unit of effort' meant unless it was taken to be equivalent to a unit of time.
Evidence based estimating seems to provide a better solution since it tracks the history of an individual dev's estimates, recognising the fact that an individuals estimate will differ from another.
So for example if someone has a habit of underestimating a task, because of the feedback that goes into the system after the task is done, the system caters for this when that person makes another estimate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075792</id>
	<title>You don't...</title>
	<author>karcirate</author>
	<datestamp>1265745120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Accuracy in estimating programming time?

Last I heard, J.K Rowling hasn't written that book yet.</htmltext>
<tokenext>Accuracy in estimating programming time ?
Last I heard , J.K Rowling has n't written that book yet .</tokentext>
<sentencetext>Accuracy in estimating programming time?
Last I heard, J.K Rowling hasn't written that book yet.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076734</id>
	<title>Re:Simply, no software required.</title>
	<author>Low Ranked Craig</author>
	<datestamp>1265748600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Not sure why this is modded funny.  Seems pretty accurate and real-world to me.</htmltext>
<tokenext>Not sure why this is modded funny .
Seems pretty accurate and real-world to me .</tokentext>
<sentencetext>Not sure why this is modded funny.
Seems pretty accurate and real-world to me.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080978</id>
	<title>Re:Simply, no software required.</title>
	<author>UnknownSoldier</author>
	<datestamp>1265725860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's a variation of the classic 80/20 rule.</p></htmltext>
<tokenext>That 's a variation of the classic 80/20 rule .</tokentext>
<sentencetext>That's a variation of the classic 80/20 rule.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076428</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075434</id>
	<title>Multiply by Three</title>
	<author>4pins</author>
	<datestamp>1265743860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>1.  Break the program into it's component parts.<br>
2.  For each component ask, "How long should this take?"<br>
3.  Multiply that number by three and record it.<br>
4.  Add up all the numbers.<br>
<br>
I have used this method successfully for projects lasting only a few hours up to six months.</htmltext>
<tokenext>1 .
Break the program into it 's component parts .
2. For each component ask , " How long should this take ?
" 3 .
Multiply that number by three and record it .
4. Add up all the numbers .
I have used this method successfully for projects lasting only a few hours up to six months .</tokentext>
<sentencetext>1.
Break the program into it's component parts.
2.  For each component ask, "How long should this take?
"
3.
Multiply that number by three and record it.
4.  Add up all the numbers.
I have used this method successfully for projects lasting only a few hours up to six months.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075510</id>
	<title>Theory is nice, but....</title>
	<author>Anonymous</author>
	<datestamp>1265744160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Here's the problem with the above, it assumes the functionality has no unknowns. Meaning, once you spec it out, it just a matter of design and code and everything goes relatively smoothly. I just spent a few days trying to get an image module to work in C# and Silverlight. The code worked fine, but no image. Finally giving up with beating my head against the wall and reading MS documentation, I posted a question on the SL forums. Silverlight doesn't support GIF - that was the image format I was using. Apparently, MS thinks that GIF is old fashioned and going away. Translation? All the examples and techniques were written for SL2, they wouldn't even compile in SL3 let alone work.</p><p>Anyway, how do you plan for that? You choose a technology, say Java Beans or JBOSS and the problem you get isn't easily solved with the platform or may not even be supported. You're on your own - gotta roll your own. And even then, can you do it in Java? </p><p>How do you plan for that? And it seams as though, every project is like that - there's always something that pops up that's a big question mark and the solution could happen in a morning or never.</p><p>Sure, a typical database application: data in, data update, data delete, etc.. could work very well with that planning technique, but some new product? Something that hasn't been done before or has been done very infrequently?</p></htmltext>
<tokenext>Here 's the problem with the above , it assumes the functionality has no unknowns .
Meaning , once you spec it out , it just a matter of design and code and everything goes relatively smoothly .
I just spent a few days trying to get an image module to work in C # and Silverlight .
The code worked fine , but no image .
Finally giving up with beating my head against the wall and reading MS documentation , I posted a question on the SL forums .
Silverlight does n't support GIF - that was the image format I was using .
Apparently , MS thinks that GIF is old fashioned and going away .
Translation ? All the examples and techniques were written for SL2 , they would n't even compile in SL3 let alone work.Anyway , how do you plan for that ?
You choose a technology , say Java Beans or JBOSS and the problem you get is n't easily solved with the platform or may not even be supported .
You 're on your own - got ta roll your own .
And even then , can you do it in Java ?
How do you plan for that ?
And it seams as though , every project is like that - there 's always something that pops up that 's a big question mark and the solution could happen in a morning or never.Sure , a typical database application : data in , data update , data delete , etc.. could work very well with that planning technique , but some new product ?
Something that has n't been done before or has been done very infrequently ?</tokentext>
<sentencetext>Here's the problem with the above, it assumes the functionality has no unknowns.
Meaning, once you spec it out, it just a matter of design and code and everything goes relatively smoothly.
I just spent a few days trying to get an image module to work in C# and Silverlight.
The code worked fine, but no image.
Finally giving up with beating my head against the wall and reading MS documentation, I posted a question on the SL forums.
Silverlight doesn't support GIF - that was the image format I was using.
Apparently, MS thinks that GIF is old fashioned and going away.
Translation? All the examples and techniques were written for SL2, they wouldn't even compile in SL3 let alone work.Anyway, how do you plan for that?
You choose a technology, say Java Beans or JBOSS and the problem you get isn't easily solved with the platform or may not even be supported.
You're on your own - gotta roll your own.
And even then, can you do it in Java?
How do you plan for that?
And it seams as though, every project is like that - there's always something that pops up that's a big question mark and the solution could happen in a morning or never.Sure, a typical database application: data in, data update, data delete, etc.. could work very well with that planning technique, but some new product?
Something that hasn't been done before or has been done very infrequently?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076900</id>
	<title>Mythical</title>
	<author>Anonymous</author>
	<datestamp>1265706000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I am sure somebody already said this: Read "The Mythical Man-Month".</p></htmltext>
<tokenext>I am sure somebody already said this : Read " The Mythical Man-Month " .</tokentext>
<sentencetext>I am sure somebody already said this: Read "The Mythical Man-Month".</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075704</id>
	<title>virgin territory</title>
	<author>hey</author>
	<datestamp>1265744820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>By its nature software is always virgin territory.  If it had been before then why are they asking you to do it?  So its hard to estimate how long it will take because its never been done before.</p></htmltext>
<tokenext>By its nature software is always virgin territory .
If it had been before then why are they asking you to do it ?
So its hard to estimate how long it will take because its never been done before .</tokentext>
<sentencetext>By its nature software is always virgin territory.
If it had been before then why are they asking you to do it?
So its hard to estimate how long it will take because its never been done before.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076088</id>
	<title>Re:Simply, no software required.</title>
	<author>Stregano</author>
	<datestamp>1265745960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I wish I could do that at my job.
<br> <br>
Oh wait, I do.  I am working on a project right now where one feature I am adding should only take a day or two, but I am estimating one week.
<br> <br>
I have no trick or anything to estimating, but I am still new at doing it.</htmltext>
<tokenext>I wish I could do that at my job .
Oh wait , I do .
I am working on a project right now where one feature I am adding should only take a day or two , but I am estimating one week .
I have no trick or anything to estimating , but I am still new at doing it .</tokentext>
<sentencetext>I wish I could do that at my job.
Oh wait, I do.
I am working on a project right now where one feature I am adding should only take a day or two, but I am estimating one week.
I have no trick or anything to estimating, but I am still new at doing it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081260</id>
	<title>There is an easy cheat</title>
	<author>dilvish\_the\_damned</author>
	<datestamp>1265728020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Take 1/3 of your component completion estimates and multiply them by infinity, its a quick way to improve overall accuracy.</p></htmltext>
<tokenext>Take 1/3 of your component completion estimates and multiply them by infinity , its a quick way to improve overall accuracy .</tokentext>
<sentencetext>Take 1/3 of your component completion estimates and multiply them by infinity, its a quick way to improve overall accuracy.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077406</id>
	<title>Re:Simply, no software required.</title>
	<author>adamofgreyskull</author>
	<datestamp>1265708040000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p> <i>Exactly my method too. I assume we both stole it from the same place, but I can't remember where.</i></p></div> </blockquote><p>

fortune, aptly, sprung this on me last night:</p><blockquote><div><p>The Briggs - Chase Law of Program Development:<i>
        To determine how long it will take to write and debug a
        program, take your best estimate, multiply that by two, add
        one, and convert to the next higher units.</i></p></div> </blockquote></div>
	</htmltext>
<tokenext>Exactly my method too .
I assume we both stole it from the same place , but I ca n't remember where .
fortune , aptly , sprung this on me last night : The Briggs - Chase Law of Program Development : To determine how long it will take to write and debug a program , take your best estimate , multiply that by two , add one , and convert to the next higher units .</tokentext>
<sentencetext> Exactly my method too.
I assume we both stole it from the same place, but I can't remember where.
fortune, aptly, sprung this on me last night:The Briggs - Chase Law of Program Development:
        To determine how long it will take to write and debug a
        program, take your best estimate, multiply that by two, add
        one, and convert to the next higher units. 
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075418</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079940</id>
	<title>Good Estimates Lead to Layoffs</title>
	<author>Moof123</author>
	<datestamp>1265718840000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I am not a software guy, but an analog microwave design guy.  All too often management expectations can in no way jive with reality.  Instead it is often necessary to intentionally underestimate times, and later find specific items to pin the "delays" on.  Along the way so much money and resources get involved, that effectively you've gotten the project through the second trimester without management realizing they are pregnant.  Beatings ensue, but at that point those of us with scarce skills can't be laid off, so we shield our faces and live on to design another day.</p><p>Yay, another successful project out the door despite management...</p></htmltext>
<tokenext>I am not a software guy , but an analog microwave design guy .
All too often management expectations can in no way jive with reality .
Instead it is often necessary to intentionally underestimate times , and later find specific items to pin the " delays " on .
Along the way so much money and resources get involved , that effectively you 've gotten the project through the second trimester without management realizing they are pregnant .
Beatings ensue , but at that point those of us with scarce skills ca n't be laid off , so we shield our faces and live on to design another day.Yay , another successful project out the door despite management.. .</tokentext>
<sentencetext>I am not a software guy, but an analog microwave design guy.
All too often management expectations can in no way jive with reality.
Instead it is often necessary to intentionally underestimate times, and later find specific items to pin the "delays" on.
Along the way so much money and resources get involved, that effectively you've gotten the project through the second trimester without management realizing they are pregnant.
Beatings ensue, but at that point those of us with scarce skills can't be laid off, so we shield our faces and live on to design another day.Yay, another successful project out the door despite management...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083270</id>
	<title>Re:I am often subjected to mockery by it, but COCO</title>
	<author>Anonymous</author>
	<datestamp>1265018040000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p> "How many lines of code?" is often easier to answer than "how long will this take?"</p></div></blockquote><p>But it's not what was asked for.</p><p>SLOC is a useless metric of productivity - and measuring productivity isn't even the objective here.  It's to budget and plan a project.  Since the cost of most things involved depends on time (staff are paid by the day) and time is a what's used to coordinate activites  (we'll have the system up on 1 March - make sure the users are available), producing an answer in units of SLOC is about as useful as one in feet or ounces.</p><p>You say they subject you to mockery.  Really?</p></div>
	</htmltext>
<tokenext>" How many lines of code ?
" is often easier to answer than " how long will this take ?
" But it 's not what was asked for.SLOC is a useless metric of productivity - and measuring productivity is n't even the objective here .
It 's to budget and plan a project .
Since the cost of most things involved depends on time ( staff are paid by the day ) and time is a what 's used to coordinate activites ( we 'll have the system up on 1 March - make sure the users are available ) , producing an answer in units of SLOC is about as useful as one in feet or ounces.You say they subject you to mockery .
Really ?</tokentext>
<sentencetext> "How many lines of code?
" is often easier to answer than "how long will this take?
"But it's not what was asked for.SLOC is a useless metric of productivity - and measuring productivity isn't even the objective here.
It's to budget and plan a project.
Since the cost of most things involved depends on time (staff are paid by the day) and time is a what's used to coordinate activites  (we'll have the system up on 1 March - make sure the users are available), producing an answer in units of SLOC is about as useful as one in feet or ounces.You say they subject you to mockery.
Really?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077002</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076682</id>
	<title>Re:Simply, no software required.</title>
	<author>shock1970</author>
	<datestamp>1265748360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think you meant that the first 90\% of the project takes the first 10\% of the time line, and the remaining 10\% of the project takes the other 90\% of time.</htmltext>
<tokenext>I think you meant that the first 90 \ % of the project takes the first 10 \ % of the time line , and the remaining 10 \ % of the project takes the other 90 \ % of time .</tokentext>
<sentencetext>I think you meant that the first 90\% of the project takes the first 10\% of the time line, and the remaining 10\% of the project takes the other 90\% of time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076428</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078964</id>
	<title>Re:Uhh, Scrum is not an estimation method</title>
	<author>Anonymous</author>
	<datestamp>1265714220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You forgot the part where you split functionality up in user stories and estimate the stories in story points. After that you fill the sprint with as many stories as your velocity indicates you can achieve in one sprint.</p></htmltext>
<tokenext>You forgot the part where you split functionality up in user stories and estimate the stories in story points .
After that you fill the sprint with as many stories as your velocity indicates you can achieve in one sprint .</tokentext>
<sentencetext>You forgot the part where you split functionality up in user stories and estimate the stories in story points.
After that you fill the sprint with as many stories as your velocity indicates you can achieve in one sprint.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076028</id>
	<title>And the answer is ...</title>
	<author>Skapare</author>
	<datestamp>1265745780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>42</p><p>The units depends on what combination you want of:</p><ol> <li>works reliably</li><li>performs efficiently</li><li>easy to use</li><li>comes in on budget</li></ol></htmltext>
<tokenext>42The units depends on what combination you want of : works reliablyperforms efficientlyeasy to usecomes in on budget</tokentext>
<sentencetext>42The units depends on what combination you want of: works reliablyperforms efficientlyeasy to usecomes in on budget</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075610</id>
	<title>Re:Chop features.</title>
	<author>Rob the Bold</author>
	<datestamp>1265744520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate.  Once you start doing that, then you can adjust your estimates to allow for more features or yes.</p></div><p>Unfortunately, features usually get cut by chance rather than by plan since no one wants to give up on anything, including the deadline.  As you suggest, it would be be better to do it in a conscious way, but that seems way too rare in practice.</p></div>
	</htmltext>
<tokenext>The deal is , you have to be able to get a screen or database up and running ok in some x number of hours , and prioritize , to fit that estimate .
Once you start doing that , then you can adjust your estimates to allow for more features or yes.Unfortunately , features usually get cut by chance rather than by plan since no one wants to give up on anything , including the deadline .
As you suggest , it would be be better to do it in a conscious way , but that seems way too rare in practice .</tokentext>
<sentencetext>The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate.
Once you start doing that, then you can adjust your estimates to allow for more features or yes.Unfortunately, features usually get cut by chance rather than by plan since no one wants to give up on anything, including the deadline.
As you suggest, it would be be better to do it in a conscious way, but that seems way too rare in practice.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076104</id>
	<title>Done when it's done</title>
	<author>Anonymous</author>
	<datestamp>1265746020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I can pretty much estimate, dead-on, how many days it will take me to write a script.  The devil is in the details, though.</p><p>If the requestor doesn't fully comprehend what's needed, he will send back change request after change request after change request. Each request pushes out the estimate.  For example, I once had a request to write a script that copies a log file from one machine to another.  After the initial discussion, it was understood that the log file would be completed by 12:15AM every day.  My estimate was 2 hours to write the script.  And I did. It was a simple SCP wrapped in my standard shell template that took care of logging, reporting, and script miscellany.</p><p>The requestor tried it.. then informed that the 12:15AM deadline was not really true. The file may be written at any point, but each day the file gets rotated at 12:15AM.  It wasn't the main file that was needed, but the one from the day before. OK, no problem. I took it as a change request and adjusted the estimate. Sent back a script that grabbed the previous day's file. Tried it in the test environment and it worked great.</p><p>We move it to beta test. This time there's more data. Now we learn that the application initiates the rotation at 12:15AM, but it doesn't necessarily complete by the 1AM when we run our copy because some applications still may be writing to it.  I suggest creating a sentinel that the script can watch to only run when the copy is complete.  Another long-standing issue comes up, however. The log can't run past 5AM otherwise something requiring human intervention happens. This has *never* occurred, but with anticipated increase in activity, it could shrink our window from 4 hours to just 1 for the copy. No one is comfortable with that.</p><p>In the end, the application is modified so that it writes to a shared filesystem.</p><p>I know... In a sane IT shop the lowly script writer would know the requirements before that first #!/usr/bin/perl line was written. In reality it's almost never the case. We get requirements and a deadline. We churn out code that matches those requirements. The project managers and the architects are supposed to give good requirements and conditions, but that rarely happens. Certainly we must anticipate certain events so we trap for the standard issues, but often scripts are just stopgap solutions to keep something going long enough until that component is redesigned or replaced.</p></htmltext>
<tokenext>I can pretty much estimate , dead-on , how many days it will take me to write a script .
The devil is in the details , though.If the requestor does n't fully comprehend what 's needed , he will send back change request after change request after change request .
Each request pushes out the estimate .
For example , I once had a request to write a script that copies a log file from one machine to another .
After the initial discussion , it was understood that the log file would be completed by 12 : 15AM every day .
My estimate was 2 hours to write the script .
And I did .
It was a simple SCP wrapped in my standard shell template that took care of logging , reporting , and script miscellany.The requestor tried it.. then informed that the 12 : 15AM deadline was not really true .
The file may be written at any point , but each day the file gets rotated at 12 : 15AM .
It was n't the main file that was needed , but the one from the day before .
OK , no problem .
I took it as a change request and adjusted the estimate .
Sent back a script that grabbed the previous day 's file .
Tried it in the test environment and it worked great.We move it to beta test .
This time there 's more data .
Now we learn that the application initiates the rotation at 12 : 15AM , but it does n't necessarily complete by the 1AM when we run our copy because some applications still may be writing to it .
I suggest creating a sentinel that the script can watch to only run when the copy is complete .
Another long-standing issue comes up , however .
The log ca n't run past 5AM otherwise something requiring human intervention happens .
This has * never * occurred , but with anticipated increase in activity , it could shrink our window from 4 hours to just 1 for the copy .
No one is comfortable with that.In the end , the application is modified so that it writes to a shared filesystem.I know... In a sane IT shop the lowly script writer would know the requirements before that first # ! /usr/bin/perl line was written .
In reality it 's almost never the case .
We get requirements and a deadline .
We churn out code that matches those requirements .
The project managers and the architects are supposed to give good requirements and conditions , but that rarely happens .
Certainly we must anticipate certain events so we trap for the standard issues , but often scripts are just stopgap solutions to keep something going long enough until that component is redesigned or replaced .</tokentext>
<sentencetext>I can pretty much estimate, dead-on, how many days it will take me to write a script.
The devil is in the details, though.If the requestor doesn't fully comprehend what's needed, he will send back change request after change request after change request.
Each request pushes out the estimate.
For example, I once had a request to write a script that copies a log file from one machine to another.
After the initial discussion, it was understood that the log file would be completed by 12:15AM every day.
My estimate was 2 hours to write the script.
And I did.
It was a simple SCP wrapped in my standard shell template that took care of logging, reporting, and script miscellany.The requestor tried it.. then informed that the 12:15AM deadline was not really true.
The file may be written at any point, but each day the file gets rotated at 12:15AM.
It wasn't the main file that was needed, but the one from the day before.
OK, no problem.
I took it as a change request and adjusted the estimate.
Sent back a script that grabbed the previous day's file.
Tried it in the test environment and it worked great.We move it to beta test.
This time there's more data.
Now we learn that the application initiates the rotation at 12:15AM, but it doesn't necessarily complete by the 1AM when we run our copy because some applications still may be writing to it.
I suggest creating a sentinel that the script can watch to only run when the copy is complete.
Another long-standing issue comes up, however.
The log can't run past 5AM otherwise something requiring human intervention happens.
This has *never* occurred, but with anticipated increase in activity, it could shrink our window from 4 hours to just 1 for the copy.
No one is comfortable with that.In the end, the application is modified so that it writes to a shared filesystem.I know... In a sane IT shop the lowly script writer would know the requirements before that first #!/usr/bin/perl line was written.
In reality it's almost never the case.
We get requirements and a deadline.
We churn out code that matches those requirements.
The project managers and the architects are supposed to give good requirements and conditions, but that rarely happens.
Certainly we must anticipate certain events so we trap for the standard issues, but often scripts are just stopgap solutions to keep something going long enough until that component is redesigned or replaced.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083376</id>
	<title>I estimate it in...</title>
	<author>Anonymous</author>
	<datestamp>1265019300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Cups of Coffee. I mean Pitchers of coffee</p></htmltext>
<tokenext>Cups of Coffee .
I mean Pitchers of coffee</tokentext>
<sentencetext>Cups of Coffee.
I mean Pitchers of coffee</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078380</id>
	<title>Re:Simply, no software required.</title>
	<author>david\_thornley</author>
	<datestamp>1265711760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
That's why I completely ignore Hofstadter's Law, and never take it into account.</p></htmltext>
<tokenext>That 's why I completely ignore Hofstadter 's Law , and never take it into account .</tokentext>
<sentencetext>
That's why I completely ignore Hofstadter's Law, and never take it into account.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075816</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31085026</id>
	<title>Re:Function Point Analysis and Man Hours</title>
	<author>Anonymous</author>
	<datestamp>1265036820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>4) Multiple by PI</i></p><p>Is that what they call "rounding up" ?</p></htmltext>
<tokenext>4 ) Multiple by PIIs that what they call " rounding up " ?</tokentext>
<sentencetext>4) Multiple by PIIs that what they call "rounding up" ?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076376</id>
	<title>Re:Programming time?</title>
	<author>LowerTheBar</author>
	<datestamp>1265747040000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Our development time is estimated based on when management has promised a feature/enhancement. Even when management has forgotten to tell the development team the promised date, until a few days beforehand.

Apparently this is a very accurate way to estimate programming/testing time, because somehow we always make the dates.  Of course there are times when sleep is not accounted for in these estimates.</htmltext>
<tokenext>Our development time is estimated based on when management has promised a feature/enhancement .
Even when management has forgotten to tell the development team the promised date , until a few days beforehand .
Apparently this is a very accurate way to estimate programming/testing time , because somehow we always make the dates .
Of course there are times when sleep is not accounted for in these estimates .</tokentext>
<sentencetext>Our development time is estimated based on when management has promised a feature/enhancement.
Even when management has forgotten to tell the development team the promised date, until a few days beforehand.
Apparently this is a very accurate way to estimate programming/testing time, because somehow we always make the dates.
Of course there are times when sleep is not accounted for in these estimates.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075062</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082008</id>
	<title>TEA</title>
	<author>BlackHawk-666</author>
	<datestamp>1265736360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>For which they traded <i>OPIUM</i>! Tea drinkers are willing to deals thousands of kilos of opium to China in order to get that morning cup. Can coffee drinkers say the same?</p></htmltext>
<tokenext>For which they traded OPIUM !
Tea drinkers are willing to deals thousands of kilos of opium to China in order to get that morning cup .
Can coffee drinkers say the same ?</tokentext>
<sentencetext>For which they traded OPIUM!
Tea drinkers are willing to deals thousands of kilos of opium to China in order to get that morning cup.
Can coffee drinkers say the same?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076914</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075938</id>
	<title>Double</title>
	<author>borgasm</author>
	<datestamp>1265745540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Write up a one page document about the project, then go look at the code you are modifying. Make your best guess estimate, then double it.</p></htmltext>
<tokenext>Write up a one page document about the project , then go look at the code you are modifying .
Make your best guess estimate , then double it .</tokentext>
<sentencetext>Write up a one page document about the project, then go look at the code you are modifying.
Make your best guess estimate, then double it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077268</id>
	<title>Murphy's SWAG</title>
	<author>Anonymous</author>
	<datestamp>1265707380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What amount of time would cause the greatest harm to the largest number of involved participants?</p></htmltext>
<tokenext>What amount of time would cause the greatest harm to the largest number of involved participants ?</tokentext>
<sentencetext>What amount of time would cause the greatest harm to the largest number of involved participants?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076198</id>
	<title>Experience!</title>
	<author>sjames</author>
	<datestamp>1265746380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>At some level, it will always be a WAG tempered with experience. It is always best to assume there will be delays and try to add them in.</p><p>The real catch though depends on what you're estimating. Just the coding or the design? When management says we want a program that does X, how long will it take, they're asking the impossible. They want you to estimate the time to get the actual requirements documented, the time to design software meeting those requirements (which you can't know until step 1 is complete) and then the time to build that design (that you can't know until step 2 is complete). You can guess, of course, and perhaps even be in the ballpark, but that's about it. TFA doesn't address this either (perhaps because it's not addressable beyond GUESS!).</p><p>Inevitably they'll complain that buildings get built on schedule all the time. They conveniently forget (or just don't know) that that schedule doesn't appear until the design process is completed (step 2 above) and before that, it's a guess.</p></htmltext>
<tokenext>At some level , it will always be a WAG tempered with experience .
It is always best to assume there will be delays and try to add them in.The real catch though depends on what you 're estimating .
Just the coding or the design ?
When management says we want a program that does X , how long will it take , they 're asking the impossible .
They want you to estimate the time to get the actual requirements documented , the time to design software meeting those requirements ( which you ca n't know until step 1 is complete ) and then the time to build that design ( that you ca n't know until step 2 is complete ) .
You can guess , of course , and perhaps even be in the ballpark , but that 's about it .
TFA does n't address this either ( perhaps because it 's not addressable beyond GUESS !
) .Inevitably they 'll complain that buildings get built on schedule all the time .
They conveniently forget ( or just do n't know ) that that schedule does n't appear until the design process is completed ( step 2 above ) and before that , it 's a guess .</tokentext>
<sentencetext>At some level, it will always be a WAG tempered with experience.
It is always best to assume there will be delays and try to add them in.The real catch though depends on what you're estimating.
Just the coding or the design?
When management says we want a program that does X, how long will it take, they're asking the impossible.
They want you to estimate the time to get the actual requirements documented, the time to design software meeting those requirements (which you can't know until step 1 is complete) and then the time to build that design (that you can't know until step 2 is complete).
You can guess, of course, and perhaps even be in the ballpark, but that's about it.
TFA doesn't address this either (perhaps because it's not addressable beyond GUESS!
).Inevitably they'll complain that buildings get built on schedule all the time.
They conveniently forget (or just don't know) that that schedule doesn't appear until the design process is completed (step 2 above) and before that, it's a guess.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075910</id>
	<title>We agile the crap out of it...</title>
	<author>PmanAce</author>
	<datestamp>1265745480000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext>What we do is try and break down tasks as much as we can so they each take 1 day or less to accomplish. Then it is easier to estimate a bunch of small task that most of the time have already been estimated in previous projects.

Rinse and repeat.</htmltext>
<tokenext>What we do is try and break down tasks as much as we can so they each take 1 day or less to accomplish .
Then it is easier to estimate a bunch of small task that most of the time have already been estimated in previous projects .
Rinse and repeat .</tokentext>
<sentencetext>What we do is try and break down tasks as much as we can so they each take 1 day or less to accomplish.
Then it is easier to estimate a bunch of small task that most of the time have already been estimated in previous projects.
Rinse and repeat.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075418</id>
	<title>Re:Simply, no software required.</title>
	<author>Rob the Bold</author>
	<datestamp>1265743800000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>I take the amount of time I think it will take, double it and move it up a time unit.</p><p>So, if I think it will take two days, I estimate 4 weeks.  If I think it will take a week, I estimate two months and so on.</p></div><p>Exactly my method too.  I assume we both stole it from the same place, but I can't remember where.  I am also ashamed that it is often right.</p><p>Which either means I'm lousy at estimating or brilliant.  Or maybe just lousy at implementation.  Or maybe nothing at all.</p><p>But it doesn't matter, of course, since the boss will ask "Are you sure?"  And we all know that that means "try to come up with an estimate that fits my predetermined schedule."  So you either cut features/quality by plan or by fact.  Usually by fact, since no one wants to give up anything. So you give up whatever doesn't happen to be done (or give up your release date -- which is also a feature of a sort).</p><p>Deadlines are useful, though, in avoiding a DNF type situation.</p></div>
	</htmltext>
<tokenext>I take the amount of time I think it will take , double it and move it up a time unit.So , if I think it will take two days , I estimate 4 weeks .
If I think it will take a week , I estimate two months and so on.Exactly my method too .
I assume we both stole it from the same place , but I ca n't remember where .
I am also ashamed that it is often right.Which either means I 'm lousy at estimating or brilliant .
Or maybe just lousy at implementation .
Or maybe nothing at all.But it does n't matter , of course , since the boss will ask " Are you sure ?
" And we all know that that means " try to come up with an estimate that fits my predetermined schedule .
" So you either cut features/quality by plan or by fact .
Usually by fact , since no one wants to give up anything .
So you give up whatever does n't happen to be done ( or give up your release date -- which is also a feature of a sort ) .Deadlines are useful , though , in avoiding a DNF type situation .</tokentext>
<sentencetext>I take the amount of time I think it will take, double it and move it up a time unit.So, if I think it will take two days, I estimate 4 weeks.
If I think it will take a week, I estimate two months and so on.Exactly my method too.
I assume we both stole it from the same place, but I can't remember where.
I am also ashamed that it is often right.Which either means I'm lousy at estimating or brilliant.
Or maybe just lousy at implementation.
Or maybe nothing at all.But it doesn't matter, of course, since the boss will ask "Are you sure?
"  And we all know that that means "try to come up with an estimate that fits my predetermined schedule.
"  So you either cut features/quality by plan or by fact.
Usually by fact, since no one wants to give up anything.
So you give up whatever doesn't happen to be done (or give up your release date -- which is also a feature of a sort).Deadlines are useful, though, in avoiding a DNF type situation.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076276</id>
	<title>18d20</title>
	<author>Anonymous</author>
	<datestamp>1265746620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Eighteen twenty sided dice.  5d6 for smaller projects.</p></htmltext>
<tokenext>Eighteen twenty sided dice .
5d6 for smaller projects .</tokentext>
<sentencetext>Eighteen twenty sided dice.
5d6 for smaller projects.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050</id>
	<title>Chop features.</title>
	<author>Anonymous</author>
	<datestamp>1265742780000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it.  The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate.  Once you start doing that, then you can adjust your estimates to allow for more features or yes.</p></htmltext>
<tokenext>Estimating accurately is n't so much of an art of estimating accurately , as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it .
The deal is , you have to be able to get a screen or database up and running ok in some x number of hours , and prioritize , to fit that estimate .
Once you start doing that , then you can adjust your estimates to allow for more features or yes .</tokentext>
<sentencetext>Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it.
The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate.
Once you start doing that, then you can adjust your estimates to allow for more features or yes.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075486</id>
	<title>Re:Simply, no software required.</title>
	<author>Anonymous</author>
	<datestamp>1265744040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>1 month becomes 2 years?</p></htmltext>
<tokenext>1 month becomes 2 years ?</tokentext>
<sentencetext>1 month becomes 2 years?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076036</id>
	<title>Re:My Ass</title>
	<author>Anonymous</author>
	<datestamp>1265745840000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've taken this a step further and convinced my boss that the numbers I pull out of my ass don't mean anything.  They continue to ask for them but understand that it's possible for me to be WAY out in either direction.</p></htmltext>
<tokenext>I 've taken this a step further and convinced my boss that the numbers I pull out of my ass do n't mean anything .
They continue to ask for them but understand that it 's possible for me to be WAY out in either direction .</tokentext>
<sentencetext>I've taken this a step further and convinced my boss that the numbers I pull out of my ass don't mean anything.
They continue to ask for them but understand that it's possible for me to be WAY out in either direction.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080366</id>
	<title>Re:Simply, no software required.</title>
	<author>Anonymous</author>
	<datestamp>1265721660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Should be 2pi for complete circles</p></htmltext>
<tokenext>Should be 2pi for complete circles</tokentext>
<sentencetext>Should be 2pi for complete circles</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076676</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075300</id>
	<title>Does it matter?</title>
	<author>Opportunist</author>
	<datestamp>1265743440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Why should I bother to figure out how long it will take to implement it? Marketing has certainly already set a delivery date, so that burden is taken off your shoulders.</p></htmltext>
<tokenext>Why should I bother to figure out how long it will take to implement it ?
Marketing has certainly already set a delivery date , so that burden is taken off your shoulders .</tokentext>
<sentencetext>Why should I bother to figure out how long it will take to implement it?
Marketing has certainly already set a delivery date, so that burden is taken off your shoulders.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077332</id>
	<title>SEI's PSP/TSP</title>
	<author>Intellectual Elitist</author>
	<datestamp>1265707740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Estimate the parts required using historical proxies based around size and content.  Use historical development time data based on the part estimates.  Consolidate the group of smaller estimates for yourself, or ideally across an entire team, to allow estimation error to cancel itself out as much as possible across the group.  Now you have a solid estimate of the total effort required, and you just have to map that to the available development hours in each developer's schedule, rebalance as necessary, and see what your end date looks like.

<a href="http://www.sei.cmu.edu/tsp/" title="cmu.edu">Team Software Process</a> [cmu.edu]</htmltext>
<tokenext>Estimate the parts required using historical proxies based around size and content .
Use historical development time data based on the part estimates .
Consolidate the group of smaller estimates for yourself , or ideally across an entire team , to allow estimation error to cancel itself out as much as possible across the group .
Now you have a solid estimate of the total effort required , and you just have to map that to the available development hours in each developer 's schedule , rebalance as necessary , and see what your end date looks like .
Team Software Process [ cmu.edu ]</tokentext>
<sentencetext>Estimate the parts required using historical proxies based around size and content.
Use historical development time data based on the part estimates.
Consolidate the group of smaller estimates for yourself, or ideally across an entire team, to allow estimation error to cancel itself out as much as possible across the group.
Now you have a solid estimate of the total effort required, and you just have to map that to the available development hours in each developer's schedule, rebalance as necessary, and see what your end date looks like.
Team Software Process [cmu.edu]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075472</id>
	<title>Depends</title>
	<author>DoofusOfDeath</author>
	<datestamp>1265744040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Are we talking before or after the contract is signed?</p></htmltext>
<tokenext>Are we talking before or after the contract is signed ?</tokentext>
<sentencetext>Are we talking before or after the contract is signed?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076306</id>
	<title>Re:It's Easy</title>
	<author>Chrutil</author>
	<datestamp>1265746740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>This is very true as far as the delivery date for the application/component.
However, estimation is not used for determining the ship date of your software, dates and such comes from marketing.<br>
Estimation is used to determine how many subtasks/features that can be done within the given time
so that you can scope out features that won't make from the very beginning.<br>
<br>
^C</htmltext>
<tokenext>This is very true as far as the delivery date for the application/component .
However , estimation is not used for determining the ship date of your software , dates and such comes from marketing .
Estimation is used to determine how many subtasks/features that can be done within the given time so that you can scope out features that wo n't make from the very beginning .
^ C</tokentext>
<sentencetext>This is very true as far as the delivery date for the application/component.
However, estimation is not used for determining the ship date of your software, dates and such comes from marketing.
Estimation is used to determine how many subtasks/features that can be done within the given time
so that you can scope out features that won't make from the very beginning.
^C</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079592</id>
	<title>Re:W.A.G.</title>
	<author>Anonymous</author>
	<datestamp>1265716860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>One of the biggest reasons for estimating (and trying to do it accurately) is so that if marketing's desires and reality are too far out of line, you know to get your resume' updated.</p><p>(Depending on your circumstances, that may be the \_main\_ reason for attempting to estimate accurately.)</p></htmltext>
<tokenext>One of the biggest reasons for estimating ( and trying to do it accurately ) is so that if marketing 's desires and reality are too far out of line , you know to get your resume ' updated .
( Depending on your circumstances , that may be the \ _main \ _ reason for attempting to estimate accurately .
)</tokentext>
<sentencetext>One of the biggest reasons for estimating (and trying to do it accurately) is so that if marketing's desires and reality are too far out of line, you know to get your resume' updated.
(Depending on your circumstances, that may be the \_main\_ reason for attempting to estimate accurately.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076716</id>
	<title>Re:Simply, no software required.</title>
	<author>BabyDuckHat</author>
	<datestamp>1265748480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>But it doesn't matter, of course, since the boss will ask "Are you sure?" And we all know that that means "try to come up with an estimate that fits my predetermined schedule."</i> <br>
<br>
My other favorite manager question is, "How easy would it be to do such and such?".<br>
<br>
My reply, "If it's not easy does that mean I don't have to do it?"</htmltext>
<tokenext>But it does n't matter , of course , since the boss will ask " Are you sure ?
" And we all know that that means " try to come up with an estimate that fits my predetermined schedule .
" My other favorite manager question is , " How easy would it be to do such and such ? " .
My reply , " If it 's not easy does that mean I do n't have to do it ?
"</tokentext>
<sentencetext>But it doesn't matter, of course, since the boss will ask "Are you sure?
" And we all know that that means "try to come up with an estimate that fits my predetermined schedule.
" 

My other favorite manager question is, "How easy would it be to do such and such?".
My reply, "If it's not easy does that mean I don't have to do it?
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075418</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075150</id>
	<title>joel on software</title>
	<author>Anonymous</author>
	<datestamp>1265743020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I just make a wild guess and multiply by 2.  Joel Sposky had a different take on time management:</p><p><a href="http://www.joelonsoftware.com/items/2007/10/26.html" title="joelonsoftware.com" rel="nofollow">http://www.joelonsoftware.com/items/2007/10/26.html</a> [joelonsoftware.com]</p></htmltext>
<tokenext>I just make a wild guess and multiply by 2 .
Joel Sposky had a different take on time management : http : //www.joelonsoftware.com/items/2007/10/26.html [ joelonsoftware.com ]</tokentext>
<sentencetext>I just make a wild guess and multiply by 2.
Joel Sposky had a different take on time management:http://www.joelonsoftware.com/items/2007/10/26.html [joelonsoftware.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31095578</id>
	<title>Re:Uhh, Scrum is not an estimation method</title>
	<author>Anonymous</author>
	<datestamp>1265044560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You can within a 2 week window (dumbass)</p></htmltext>
<tokenext>You can within a 2 week window ( dumbass )</tokentext>
<sentencetext>You can within a 2 week window (dumbass)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076568</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081550</id>
	<title>Re:My Ass</title>
	<author>Anonymous</author>
	<datestamp>1265730480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Any experienced developer will be thinking about who / what to blame for their estimates being out before they even give them.  The reasons will depend on how far out the estimate ends up.  If it is a couple of hours then "we were unable to connect to the development environment due to a network issue" will suffice or "Bob was sick on this day, hence why we are slightly out", if they are weeks / months out then you have to pull out the good 'ol "the customer was on the crack pipe when they put together the requirements - the requirements are nothing like what they actually needed" regardless of how well specced and thought through the requirements are.  "Scope creep" is another good one to save the day, especially if you can back it up with emails to the PM outlining your concerns (the idea is to email the PM regarding scope creep over ANY request by the customer regardless of whether or not it is within scope).  When the shit hits the fan you can blame the PM for "not managing customer expectations properly" and the customer for "not fully understanding what they wanted before they began the project".  If you put your story together well enough you can end up way out with your estimates yet end up the hero by making it look that the only reason the project ever finished was because of you and everyone else just plain sucked.  Management doesn't know any better - just point out that the customer wasn't using  which is why they were so hopeless and any experienced PM would have picked up on this and handled the situation.</p><p>Oh no - management are not the only ones who can play those games *evil laugh*</p></htmltext>
<tokenext>Any experienced developer will be thinking about who / what to blame for their estimates being out before they even give them .
The reasons will depend on how far out the estimate ends up .
If it is a couple of hours then " we were unable to connect to the development environment due to a network issue " will suffice or " Bob was sick on this day , hence why we are slightly out " , if they are weeks / months out then you have to pull out the good 'ol " the customer was on the crack pipe when they put together the requirements - the requirements are nothing like what they actually needed " regardless of how well specced and thought through the requirements are .
" Scope creep " is another good one to save the day , especially if you can back it up with emails to the PM outlining your concerns ( the idea is to email the PM regarding scope creep over ANY request by the customer regardless of whether or not it is within scope ) .
When the shit hits the fan you can blame the PM for " not managing customer expectations properly " and the customer for " not fully understanding what they wanted before they began the project " .
If you put your story together well enough you can end up way out with your estimates yet end up the hero by making it look that the only reason the project ever finished was because of you and everyone else just plain sucked .
Management does n't know any better - just point out that the customer was n't using which is why they were so hopeless and any experienced PM would have picked up on this and handled the situation.Oh no - management are not the only ones who can play those games * evil laugh *</tokentext>
<sentencetext>Any experienced developer will be thinking about who / what to blame for their estimates being out before they even give them.
The reasons will depend on how far out the estimate ends up.
If it is a couple of hours then "we were unable to connect to the development environment due to a network issue" will suffice or "Bob was sick on this day, hence why we are slightly out", if they are weeks / months out then you have to pull out the good 'ol "the customer was on the crack pipe when they put together the requirements - the requirements are nothing like what they actually needed" regardless of how well specced and thought through the requirements are.
"Scope creep" is another good one to save the day, especially if you can back it up with emails to the PM outlining your concerns (the idea is to email the PM regarding scope creep over ANY request by the customer regardless of whether or not it is within scope).
When the shit hits the fan you can blame the PM for "not managing customer expectations properly" and the customer for "not fully understanding what they wanted before they began the project".
If you put your story together well enough you can end up way out with your estimates yet end up the hero by making it look that the only reason the project ever finished was because of you and everyone else just plain sucked.
Management doesn't know any better - just point out that the customer wasn't using  which is why they were so hopeless and any experienced PM would have picked up on this and handled the situation.Oh no - management are not the only ones who can play those games *evil laugh*</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078068</id>
	<title>Re:Simply, no software required.</title>
	<author>Anonymous</author>
	<datestamp>1265710680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I think he meant that the last 10\% takes just as much time as the first 90\% and the project will take longer than you thought it would.</p></htmltext>
<tokenext>I think he meant that the last 10 \ % takes just as much time as the first 90 \ % and the project will take longer than you thought it would .</tokentext>
<sentencetext>I think he meant that the last 10\% takes just as much time as the first 90\% and the project will take longer than you thought it would.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076682</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076316</id>
	<title>Re:Simply, no software required.</title>
	<author>Anonymous</author>
	<datestamp>1265746800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I just triple the time.  2 days = 6.  That works.</p></htmltext>
<tokenext>I just triple the time .
2 days = 6 .
That works .</tokentext>
<sentencetext>I just triple the time.
2 days = 6.
That works.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082080</id>
	<title>Re:Simply, no software required.</title>
	<author>pnewhook</author>
	<datestamp>1265737260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So when you realized it would take longer than the first estimate you gave did you give the new estimate to your boss or did you just wait to get fried for your first incorrect estimate?</p></htmltext>
<tokenext>So when you realized it would take longer than the first estimate you gave did you give the new estimate to your boss or did you just wait to get fried for your first incorrect estimate ?</tokentext>
<sentencetext>So when you realized it would take longer than the first estimate you gave did you give the new estimate to your boss or did you just wait to get fried for your first incorrect estimate?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080394</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077954</id>
	<title>And puts a two week horizon on your creativity</title>
	<author>tlambert</author>
	<datestamp>1265710320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And puts a two week horizon on your creativity</p><p>Which is great if all you need to do is crank out grunt work, but a bit hairy if you are trying to do anything innovative that won't fit into a two week period.  In creative organizations or fields of endeavor, nothing kills your chance of coming up with a great product as cutting things into two week deadlines.</p><p>-- Terry</p></htmltext>
<tokenext>And puts a two week horizon on your creativityWhich is great if all you need to do is crank out grunt work , but a bit hairy if you are trying to do anything innovative that wo n't fit into a two week period .
In creative organizations or fields of endeavor , nothing kills your chance of coming up with a great product as cutting things into two week deadlines.-- Terry</tokentext>
<sentencetext>And puts a two week horizon on your creativityWhich is great if all you need to do is crank out grunt work, but a bit hairy if you are trying to do anything innovative that won't fit into a two week period.
In creative organizations or fields of endeavor, nothing kills your chance of coming up with a great product as cutting things into two week deadlines.-- Terry</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078580</id>
	<title>Mind reading.</title>
	<author>Richard Steiner</author>
	<datestamp>1265712600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Anticipate your customers' needs.  Write the code first and have it working, and when they come to you with an idea and a request for an estimate, give them the time it took you times 3 plus 20\%, and then spend the "estimated" time in a hot tub at a resort with your girlfriend while your customers are happily awaiting the results of your "development".</p><p>See?  Programming *can* be fun!<nobr> <wbr></nobr>:-)</p></htmltext>
<tokenext>Anticipate your customers ' needs .
Write the code first and have it working , and when they come to you with an idea and a request for an estimate , give them the time it took you times 3 plus 20 \ % , and then spend the " estimated " time in a hot tub at a resort with your girlfriend while your customers are happily awaiting the results of your " development " .See ?
Programming * can * be fun !
: - )</tokentext>
<sentencetext>Anticipate your customers' needs.
Write the code first and have it working, and when they come to you with an idea and a request for an estimate, give them the time it took you times 3 plus 20\%, and then spend the "estimated" time in a hot tub at a resort with your girlfriend while your customers are happily awaiting the results of your "development".See?
Programming *can* be fun!
:-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083164</id>
	<title>You don't estimate -- you guess</title>
	<author>lpq</author>
	<datestamp>1265016900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Anyone who thinks they can predict that which has not been done before, is full of it.  If it can be predicted with any accuracy its because it has been done before -- in which case, why are you doing it AGAIN!?</p><p>People who can give schedules are people who are pulling the wool over management's eye.  But software isn't like manufacturing, where you take known parts, and known formula and combine them in a known way to get a the same result as you got last week.  It's doing something that hasn't been done before.  How people think they can accurately predict that is beyond me.    You have to do the project to know how long it's really going to take.</p><p>The closer you get to the end, the more accurate your estimates may get.  OR not, if you succumb to some 90/10<br>rule.</p></htmltext>
<tokenext>Anyone who thinks they can predict that which has not been done before , is full of it .
If it can be predicted with any accuracy its because it has been done before -- in which case , why are you doing it AGAIN !
? People who can give schedules are people who are pulling the wool over management 's eye .
But software is n't like manufacturing , where you take known parts , and known formula and combine them in a known way to get a the same result as you got last week .
It 's doing something that has n't been done before .
How people think they can accurately predict that is beyond me .
You have to do the project to know how long it 's really going to take.The closer you get to the end , the more accurate your estimates may get .
OR not , if you succumb to some 90/10rule .</tokentext>
<sentencetext>Anyone who thinks they can predict that which has not been done before, is full of it.
If it can be predicted with any accuracy its because it has been done before -- in which case, why are you doing it AGAIN!
?People who can give schedules are people who are pulling the wool over management's eye.
But software isn't like manufacturing, where you take known parts, and known formula and combine them in a known way to get a the same result as you got last week.
It's doing something that hasn't been done before.
How people think they can accurately predict that is beyond me.
You have to do the project to know how long it's really going to take.The closer you get to the end, the more accurate your estimates may get.
OR not, if you succumb to some 90/10rule.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081856</id>
	<title>Never done it with my programming. . .</title>
	<author>MagusSlurpy</author>
	<datestamp>1265734200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>. . . which is jolted and horrible and not done professionally so I've never worried about time, but whenever I build anything, or undertake any project whatsoever, what I do is estimate the time to the best of my ability, and then triple it.  That usually gets me right on target.<nobr> <wbr></nobr>;-)</htmltext>
<tokenext>.
. .
which is jolted and horrible and not done professionally so I 've never worried about time , but whenever I build anything , or undertake any project whatsoever , what I do is estimate the time to the best of my ability , and then triple it .
That usually gets me right on target .
; - )</tokentext>
<sentencetext>.
. .
which is jolted and horrible and not done professionally so I've never worried about time, but whenever I build anything, or undertake any project whatsoever, what I do is estimate the time to the best of my ability, and then triple it.
That usually gets me right on target.
;-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078262</id>
	<title>Break it down</title>
	<author>dsmoses</author>
	<datestamp>1265711400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>When estimating an application, I break it down into much smaller pieces.  Then I estimate each manageable piece, which usually can be compared to some previous known effort.  I will also estimate complexity of each piece and if there is something that is not well defined, understood, or done before, then I overestimate that portion.  You'll run under on some and over on others, balancing out.</p><p>I also use a multiplier on the total effort based on how well defined the application and/or requirements are.  This accounts for time spend not actually writing code.</p><p>I've been told before that I am the only developer that people have worked with that has a less than 1 coefficient on developer estimates.  Meaning, I get it done in less than my estimate.  Whereas other developers typically need 1.4 (or more) times the estimate.  This is usually due to the fact that with the above stated multiplier, I've already factored in the 1.4 times the estimate.</p><p>My estimates are typically higher than the next developer, but I have a positive reputation of consistently come in under estimate and delivering on time.</p></htmltext>
<tokenext>When estimating an application , I break it down into much smaller pieces .
Then I estimate each manageable piece , which usually can be compared to some previous known effort .
I will also estimate complexity of each piece and if there is something that is not well defined , understood , or done before , then I overestimate that portion .
You 'll run under on some and over on others , balancing out.I also use a multiplier on the total effort based on how well defined the application and/or requirements are .
This accounts for time spend not actually writing code.I 've been told before that I am the only developer that people have worked with that has a less than 1 coefficient on developer estimates .
Meaning , I get it done in less than my estimate .
Whereas other developers typically need 1.4 ( or more ) times the estimate .
This is usually due to the fact that with the above stated multiplier , I 've already factored in the 1.4 times the estimate.My estimates are typically higher than the next developer , but I have a positive reputation of consistently come in under estimate and delivering on time .</tokentext>
<sentencetext>When estimating an application, I break it down into much smaller pieces.
Then I estimate each manageable piece, which usually can be compared to some previous known effort.
I will also estimate complexity of each piece and if there is something that is not well defined, understood, or done before, then I overestimate that portion.
You'll run under on some and over on others, balancing out.I also use a multiplier on the total effort based on how well defined the application and/or requirements are.
This accounts for time spend not actually writing code.I've been told before that I am the only developer that people have worked with that has a less than 1 coefficient on developer estimates.
Meaning, I get it done in less than my estimate.
Whereas other developers typically need 1.4 (or more) times the estimate.
This is usually due to the fact that with the above stated multiplier, I've already factored in the 1.4 times the estimate.My estimates are typically higher than the next developer, but I have a positive reputation of consistently come in under estimate and delivering on time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079568</id>
	<title>Re:And puts a two week horizon on your creativity</title>
	<author>pclminion</author>
	<datestamp>1265716800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p> <em>And puts a two week horizon on your creativity</em> </p><p>It puts no horizon on anything. I'm having a hard time imagining a task that simply cannot be broken into manageable pieces, but suppose there was such a thing. At the end of two weeks, the item will not have been completed. Ok, fine -- unless you're working somewhere really weird, where failing to complete a backlog results in you getting fired or something, I don't see what the problem is. You don't just throw it all away and start over, you push onward. If you're tracking velocity like you should, this will ripple down and affect the number of story points you allocate in the next sprint, which should allow you to pull in additional team members to help get the tasks completed.</p><p>The time-boxed sprints are a <i>critical</i> component of Scrum, because they force development and QA work to be interleaved. A backlog will include development work AND whatever testing work is required to fulfill the item's acceptance criteria. Once you start to try to work outside the sprints, you run the huge risk of doing a large chunk of development without any testing until the very end. If your backlogs are repeatedly unfulfilled/unfulfillable, then there is a problem with the construction of the backlogs themselves, your measurement of velocity, or your team size and responsibilities -- this is a management error, not a fault of the process.</p></htmltext>
<tokenext>And puts a two week horizon on your creativity It puts no horizon on anything .
I 'm having a hard time imagining a task that simply can not be broken into manageable pieces , but suppose there was such a thing .
At the end of two weeks , the item will not have been completed .
Ok , fine -- unless you 're working somewhere really weird , where failing to complete a backlog results in you getting fired or something , I do n't see what the problem is .
You do n't just throw it all away and start over , you push onward .
If you 're tracking velocity like you should , this will ripple down and affect the number of story points you allocate in the next sprint , which should allow you to pull in additional team members to help get the tasks completed.The time-boxed sprints are a critical component of Scrum , because they force development and QA work to be interleaved .
A backlog will include development work AND whatever testing work is required to fulfill the item 's acceptance criteria .
Once you start to try to work outside the sprints , you run the huge risk of doing a large chunk of development without any testing until the very end .
If your backlogs are repeatedly unfulfilled/unfulfillable , then there is a problem with the construction of the backlogs themselves , your measurement of velocity , or your team size and responsibilities -- this is a management error , not a fault of the process .</tokentext>
<sentencetext> And puts a two week horizon on your creativity It puts no horizon on anything.
I'm having a hard time imagining a task that simply cannot be broken into manageable pieces, but suppose there was such a thing.
At the end of two weeks, the item will not have been completed.
Ok, fine -- unless you're working somewhere really weird, where failing to complete a backlog results in you getting fired or something, I don't see what the problem is.
You don't just throw it all away and start over, you push onward.
If you're tracking velocity like you should, this will ripple down and affect the number of story points you allocate in the next sprint, which should allow you to pull in additional team members to help get the tasks completed.The time-boxed sprints are a critical component of Scrum, because they force development and QA work to be interleaved.
A backlog will include development work AND whatever testing work is required to fulfill the item's acceptance criteria.
Once you start to try to work outside the sprints, you run the huge risk of doing a large chunk of development without any testing until the very end.
If your backlogs are repeatedly unfulfilled/unfulfillable, then there is a problem with the construction of the backlogs themselves, your measurement of velocity, or your team size and responsibilities -- this is a management error, not a fault of the process.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077954</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080716</id>
	<title>Write the program, measure the time it takes.</title>
	<author>DamnStupidElf</author>
	<datestamp>1265723820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The only accurate way to estimate it, I'd say.</htmltext>
<tokenext>The only accurate way to estimate it , I 'd say .</tokentext>
<sentencetext>The only accurate way to estimate it, I'd say.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076210</id>
	<title>Re:Simply, no software required.</title>
	<author>maxwell demon</author>
	<datestamp>1265746440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Conclusion: The expected time is infinite. Because only infinity doesn't change if you add some finite amount to it.</p></htmltext>
<tokenext>Conclusion : The expected time is infinite .
Because only infinity does n't change if you add some finite amount to it .</tokentext>
<sentencetext>Conclusion: The expected time is infinite.
Because only infinity doesn't change if you add some finite amount to it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075816</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075514</id>
	<title>Thumbrule</title>
	<author>N8F8</author>
	<datestamp>1265744160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Look at past performance, adjust for scope of the job, triple it and add 30\%. We programmers are always too optimistic. It's always the unpredictable 20\% that takes  80\% of the time.</p></htmltext>
<tokenext>Look at past performance , adjust for scope of the job , triple it and add 30 \ % .
We programmers are always too optimistic .
It 's always the unpredictable 20 \ % that takes 80 \ % of the time .</tokentext>
<sentencetext>Look at past performance, adjust for scope of the job, triple it and add 30\%.
We programmers are always too optimistic.
It's always the unpredictable 20\% that takes  80\% of the time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077544</id>
	<title>Re:Quid pro quo</title>
	<author>Anonymous</author>
	<datestamp>1265708580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Brilliant! And dead on.</p></htmltext>
<tokenext>Brilliant !
And dead on .</tokentext>
<sentencetext>Brilliant!
And dead on.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076496</id>
	<title>Proportional to the programmer's ego</title>
	<author>Anonymous</author>
	<datestamp>1265747580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I rank the ego of the programmer from 1-10, then multiply their time estimate by that number.</p></htmltext>
<tokenext>I rank the ego of the programmer from 1-10 , then multiply their time estimate by that number .</tokentext>
<sentencetext>I rank the ego of the programmer from 1-10, then multiply their time estimate by that number.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078244</id>
	<title>I Quit Trying...</title>
	<author>Anonymous</author>
	<datestamp>1265711280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>My boss loves to change the freakin' spec midstream and near the end. I had my sanity before I started working here. It's a crying shame. My boss is the owner, the other coder, and the one pushing my buttons</p></htmltext>
<tokenext>My boss loves to change the freakin ' spec midstream and near the end .
I had my sanity before I started working here .
It 's a crying shame .
My boss is the owner , the other coder , and the one pushing my buttons</tokentext>
<sentencetext>My boss loves to change the freakin' spec midstream and near the end.
I had my sanity before I started working here.
It's a crying shame.
My boss is the owner, the other coder, and the one pushing my buttons</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075828</id>
	<title>How long can we stretch it out?</title>
	<author>Anonymous</author>
	<datestamp>1265745180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Ask any consultant and they'll say that it takes as long as we think we can get away with.</htmltext>
<tokenext>Ask any consultant and they 'll say that it takes as long as we think we can get away with .</tokentext>
<sentencetext>Ask any consultant and they'll say that it takes as long as we think we can get away with.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076358</id>
	<title>Re:Simply, no software required.</title>
	<author>Hognoxious</author>
	<datestamp>1265746920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>If I think it will take a week, I estimate two months and so on.</p></div></blockquote><p>One month (two <i>fortnights</i>).</p></div>
	</htmltext>
<tokenext>If I think it will take a week , I estimate two months and so on.One month ( two fortnights ) .</tokentext>
<sentencetext>If I think it will take a week, I estimate two months and so on.One month (two fortnights).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079406</id>
	<title>For whom ...</title>
	<author>PPH</author>
	<datestamp>1265716080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>... are you generating these estimates?
</p><p>If you know your customer and you know how they state problems, provide requirements, understand the process they've asked you to work, then estimating can be done with some confidence.
</p><p>If you've got a new customer, or a clueless one, then you've got to get involved in an iterative discovery process. You have to boil requirements down to something you can estimate, design and build to. But the problem here is that the effort for initial requirements distillation process can be rather indeterminate. And in a well managed project, its important not to skimp on this initial project stage.
</p><p>So I guess my answer is: We can give you a very precise estimate. But we don't know how much time or money it will take to generate the estimate.</p></htmltext>
<tokenext>... are you generating these estimates ?
If you know your customer and you know how they state problems , provide requirements , understand the process they 've asked you to work , then estimating can be done with some confidence .
If you 've got a new customer , or a clueless one , then you 've got to get involved in an iterative discovery process .
You have to boil requirements down to something you can estimate , design and build to .
But the problem here is that the effort for initial requirements distillation process can be rather indeterminate .
And in a well managed project , its important not to skimp on this initial project stage .
So I guess my answer is : We can give you a very precise estimate .
But we do n't know how much time or money it will take to generate the estimate .</tokentext>
<sentencetext>... are you generating these estimates?
If you know your customer and you know how they state problems, provide requirements, understand the process they've asked you to work, then estimating can be done with some confidence.
If you've got a new customer, or a clueless one, then you've got to get involved in an iterative discovery process.
You have to boil requirements down to something you can estimate, design and build to.
But the problem here is that the effort for initial requirements distillation process can be rather indeterminate.
And in a well managed project, its important not to skimp on this initial project stage.
So I guess my answer is: We can give you a very precise estimate.
But we don't know how much time or money it will take to generate the estimate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079948</id>
	<title>Re:Chop features.</title>
	<author>ScrewMaster</author>
	<datestamp>1265718900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it.  The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate.  Once you start doing that, then you can adjust your estimates to allow for more features or yes.</p></div><p>Dirty Harry: <i>A man's got to know his limitations.</i></p></div>
	</htmltext>
<tokenext>Estimating accurately is n't so much of an art of estimating accurately , as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it .
The deal is , you have to be able to get a screen or database up and running ok in some x number of hours , and prioritize , to fit that estimate .
Once you start doing that , then you can adjust your estimates to allow for more features or yes.Dirty Harry : A man 's got to know his limitations .</tokentext>
<sentencetext>Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it.
The deal is, you have to be able to get a screen or database up and running ok in some x number of hours, and prioritize, to fit that estimate.
Once you start doing that, then you can adjust your estimates to allow for more features or yes.Dirty Harry: A man's got to know his limitations.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122</id>
	<title>This is what I usually do.</title>
	<author>tool462</author>
	<datestamp>1265742900000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>I'll throw together a script that takes in all of the project parameters as input, then based on the number of people in the team, past performance, scheduling deadlines and intermediate deliverables, comes up with an estimate for final delivery.</p><p>Then I throw out that number completely, and just multiply the time it took me to develop that script by five.  This method has proven disturbingly accurate.</p></htmltext>
<tokenext>I 'll throw together a script that takes in all of the project parameters as input , then based on the number of people in the team , past performance , scheduling deadlines and intermediate deliverables , comes up with an estimate for final delivery.Then I throw out that number completely , and just multiply the time it took me to develop that script by five .
This method has proven disturbingly accurate .</tokentext>
<sentencetext>I'll throw together a script that takes in all of the project parameters as input, then based on the number of people in the team, past performance, scheduling deadlines and intermediate deliverables, comes up with an estimate for final delivery.Then I throw out that number completely, and just multiply the time it took me to develop that script by five.
This method has proven disturbingly accurate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075694</id>
	<title>Depends</title>
	<author>93 Escort Wagon</author>
	<datestamp>1265744760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>For simple projects I can usually draw upon past experience. With complex projects, if the "client" was good about thinking through what they really are asking for, estimating the time needed is normally still pretty straightforward. But most of the time the client hasn't truly thought about any specifics regarding what they think they want, and will almost certainly bring up very involved new features mid-project - so in those cases I make a wild guess and then round up.</p><p>In all instances, though, there's another significant factor. If my boss is going to be materially involved in the project, I take my initial estimate and multiply by 3.</p></htmltext>
<tokenext>For simple projects I can usually draw upon past experience .
With complex projects , if the " client " was good about thinking through what they really are asking for , estimating the time needed is normally still pretty straightforward .
But most of the time the client has n't truly thought about any specifics regarding what they think they want , and will almost certainly bring up very involved new features mid-project - so in those cases I make a wild guess and then round up.In all instances , though , there 's another significant factor .
If my boss is going to be materially involved in the project , I take my initial estimate and multiply by 3 .</tokentext>
<sentencetext>For simple projects I can usually draw upon past experience.
With complex projects, if the "client" was good about thinking through what they really are asking for, estimating the time needed is normally still pretty straightforward.
But most of the time the client hasn't truly thought about any specifics regarding what they think they want, and will almost certainly bring up very involved new features mid-project - so in those cases I make a wild guess and then round up.In all instances, though, there's another significant factor.
If my boss is going to be materially involved in the project, I take my initial estimate and multiply by 3.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075838</id>
	<title>Re:My Ass</title>
	<author>coinreturn</author>
	<datestamp>1265745240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>We have a name for this - PIDOOMA, which stands for Pulled It Directly Out Of My Ass. If the numbers are particularly rough, we will sometimes call it unwashed PIDOOMA to emphasize that we have not analyzed the numbers at all.</htmltext>
<tokenext>We have a name for this - PIDOOMA , which stands for Pulled It Directly Out Of My Ass .
If the numbers are particularly rough , we will sometimes call it unwashed PIDOOMA to emphasize that we have not analyzed the numbers at all .</tokentext>
<sentencetext>We have a name for this - PIDOOMA, which stands for Pulled It Directly Out Of My Ass.
If the numbers are particularly rough, we will sometimes call it unwashed PIDOOMA to emphasize that we have not analyzed the numbers at all.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078554</id>
	<title>Here's what you do...</title>
	<author>Anonymous</author>
	<datestamp>1265712480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Step one: Set up dartboard<br>Step two: Throw dart<br>Step three: You now have an estimate</p></htmltext>
<tokenext>Step one : Set up dartboardStep two : Throw dartStep three : You now have an estimate</tokentext>
<sentencetext>Step one: Set up dartboardStep two: Throw dartStep three: You now have an estimate</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076152</id>
	<title>Re:This is what I usually do.</title>
	<author>noidentity</author>
	<datestamp>1265746200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Then I throw out that number completely, and just multiply the time it took me to develop that script by five. This method has proven disturbingly accurate.</p></div>
</blockquote><p>So in other words, you could offer to the one asking for an estimate, "I can give you an estimate, or complete the project 17\% faster; your choice."</p></div>
	</htmltext>
<tokenext>Then I throw out that number completely , and just multiply the time it took me to develop that script by five .
This method has proven disturbingly accurate .
So in other words , you could offer to the one asking for an estimate , " I can give you an estimate , or complete the project 17 \ % faster ; your choice .
"</tokentext>
<sentencetext>Then I throw out that number completely, and just multiply the time it took me to develop that script by five.
This method has proven disturbingly accurate.
So in other words, you could offer to the one asking for an estimate, "I can give you an estimate, or complete the project 17\% faster; your choice.
"
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078646</id>
	<title>Re:W.A.G.</title>
	<author>TrackBike2</author>
	<datestamp>1265712900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Minor correction, Scientific WAG. Sounds better. I do remember one programmer who was accurate. He was called ARP (for Anal Retentive Programmer). He was fired because he could did not change his estimates when asked to compromise. Let us review. He was accurate, when done his code required no fixes, therefore he was fired for not playing the game. Better game players promised on reduced time, but when all the fixes and reworks were added in, the project took way longer than the correct estimate of ARP. Conclusion, when accurate estimates and good code are devalued, let the games begin and good luck to the poor slob forced to use the bad code.</htmltext>
<tokenext>Minor correction , Scientific WAG .
Sounds better .
I do remember one programmer who was accurate .
He was called ARP ( for Anal Retentive Programmer ) .
He was fired because he could did not change his estimates when asked to compromise .
Let us review .
He was accurate , when done his code required no fixes , therefore he was fired for not playing the game .
Better game players promised on reduced time , but when all the fixes and reworks were added in , the project took way longer than the correct estimate of ARP .
Conclusion , when accurate estimates and good code are devalued , let the games begin and good luck to the poor slob forced to use the bad code .</tokentext>
<sentencetext>Minor correction, Scientific WAG.
Sounds better.
I do remember one programmer who was accurate.
He was called ARP (for Anal Retentive Programmer).
He was fired because he could did not change his estimates when asked to compromise.
Let us review.
He was accurate, when done his code required no fixes, therefore he was fired for not playing the game.
Better game players promised on reduced time, but when all the fixes and reworks were added in, the project took way longer than the correct estimate of ARP.
Conclusion, when accurate estimates and good code are devalued, let the games begin and good luck to the poor slob forced to use the bad code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075916</id>
	<title>Re:Chop features.</title>
	<author>2short</author>
	<datestamp>1265745480000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><br>Exactly.  Ship date is a feature.  It will have lower priority than some features, and higher priority than some other features.<br>I've never seen a team that could estimate, months in advance, when a particular feature set would ship.<br>I've been part of great teams that regularly review progress and have the power to adjust priorities.</htmltext>
<tokenext>Exactly .
Ship date is a feature .
It will have lower priority than some features , and higher priority than some other features.I 've never seen a team that could estimate , months in advance , when a particular feature set would ship.I 've been part of great teams that regularly review progress and have the power to adjust priorities .</tokentext>
<sentencetext>Exactly.
Ship date is a feature.
It will have lower priority than some features, and higher priority than some other features.I've never seen a team that could estimate, months in advance, when a particular feature set would ship.I've been part of great teams that regularly review progress and have the power to adjust priorities.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31089262</id>
	<title>Re:Chop features.</title>
	<author>kwerle</author>
	<datestamp>1265054700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Exactly.  Ship date is a feature.  It will have lower priority than some features, and higher priority than some other features...</p></div><p>Wow.  I've been doing this for decades, and I've never seen it put so succinctly.</p><p>Thank you.</p></div>
	</htmltext>
<tokenext>Exactly .
Ship date is a feature .
It will have lower priority than some features , and higher priority than some other features...Wow .
I 've been doing this for decades , and I 've never seen it put so succinctly.Thank you .</tokentext>
<sentencetext>Exactly.
Ship date is a feature.
It will have lower priority than some features, and higher priority than some other features...Wow.
I've been doing this for decades, and I've never seen it put so succinctly.Thank you.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075916</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080880</id>
	<title>Shipping date is Just Another Feature...</title>
	<author>refactored</author>
	<datestamp>1265725200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>...same as any other feature, with a priority higher than some lower than other features.<br><br>Now that's really insightful.<br><br>Although I would also add that it is one of the buggier and more unstable features, since it is highly coupled to a large number of other features and bug fixes.</htmltext>
<tokenext>...same as any other feature , with a priority higher than some lower than other features.Now that 's really insightful.Although I would also add that it is one of the buggier and more unstable features , since it is highly coupled to a large number of other features and bug fixes .</tokentext>
<sentencetext>...same as any other feature, with a priority higher than some lower than other features.Now that's really insightful.Although I would also add that it is one of the buggier and more unstable features, since it is highly coupled to a large number of other features and bug fixes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075916</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080960</id>
	<title>Re:Function Point Analysis and Man Hours</title>
	<author>PommeFritz</author>
	<datestamp>1265725740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Interesting, this is the first time I see someone else use the 'pi' factor in time estimates. I once did a project that had a huge amount of overhead due to the usual (bad requirements analisys, big management overhead, inefficient testing etc etc) that really made a factor of more than three times the original estimate a realistic estimate.</htmltext>
<tokenext>Interesting , this is the first time I see someone else use the 'pi ' factor in time estimates .
I once did a project that had a huge amount of overhead due to the usual ( bad requirements analisys , big management overhead , inefficient testing etc etc ) that really made a factor of more than three times the original estimate a realistic estimate .</tokentext>
<sentencetext>Interesting, this is the first time I see someone else use the 'pi' factor in time estimates.
I once did a project that had a huge amount of overhead due to the usual (bad requirements analisys, big management overhead, inefficient testing etc etc) that really made a factor of more than three times the original estimate a realistic estimate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078462</id>
	<title>You are a bad programmer then ..</title>
	<author>roguegramma</author>
	<datestamp>1265712060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Clearly multiplying all estimates by 3 and then adding them is less efficient than adding them and then multiplying by 3 once.</p></htmltext>
<tokenext>Clearly multiplying all estimates by 3 and then adding them is less efficient than adding them and then multiplying by 3 once .</tokentext>
<sentencetext>Clearly multiplying all estimates by 3 and then adding them is less efficient than adding them and then multiplying by 3 once.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075378</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081906</id>
	<title>Old Traditionalist</title>
	<author>nicholdraper</author>
	<datestamp>1265734920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I never found accurate estimates to be all that difficult.  I don't subscribe to the extreme/agile/scrum/what ever is the latest process is in the news.  Create a design, mock up each page/dialog box whatever.  Code one up, write your unit tests.  Count up how many database tables you have, code up persistence to one and run your automated tests.  Determine how many blocks of logic you will have and code up one and test it.  You should have coded up the most difficult part in each category.  Then simple math add up each part as though it will take as long as the longest part in each category..  Then as you complete each project, only count completely done parts, don't give partial credit.

Recognize that if you estimate four days on a part and two days into it, you are pulled off, you still have four days that have to be made up.  Thrashing eliminates all part work not fully completed.  Now, if marketing, or your boss or whoever says, you missed this page, your estimate stands only for original design work.  New features get new estimates.  If you follow this and track your work through two or three projects, you will get better at determining the most difficult parts and learn to code those before you complete your estimate.

After doing this for a few years, you will get projects for which you can see the end and you can give better estimates from the hip.  But, never promise estimates to be more that +200\% -50\% accurate.  I've had many bonuses tied to finishing on time and I always get my bonuses.

Realize that I've architected over five projects with over a million dollar budgets and each took over a year to complete all phases, some multiple years.  I also have managed teams from myself to a dozen programmers and support personal (testers, graphic artists, tech writers, etc..).  My first project didn't go that well, but after multiple projects I learned how to do it correctly.  Don't buy into the comments here that say since so many people do estimating badly, that it is impossible.  Also, realize that you will have to read code from the programmers on your team and fire the non-performers.

And last of all, ask the programmers on your team for their estimates, but don't use them, use your senior architect's estimates.  If a programmer estimates long, there needs to be more training to show them how to code up whatever it is you are writing in the time the architect estimates.  If they estimate short they also need training.  You must also make sure that sub-tasks are broken down into &#189; day to 2 days chunks.  If a programmer doesn't finish the first sub-task in time, retrain or re-estimate.

You may have a boss that comes in and says, how long will this take, I want the estimate now and I don't want you to do any design or prototyping first.  Estimate how long it will take you to find a new boss and add two weeks for notice.</htmltext>
<tokenext>I never found accurate estimates to be all that difficult .
I do n't subscribe to the extreme/agile/scrum/what ever is the latest process is in the news .
Create a design , mock up each page/dialog box whatever .
Code one up , write your unit tests .
Count up how many database tables you have , code up persistence to one and run your automated tests .
Determine how many blocks of logic you will have and code up one and test it .
You should have coded up the most difficult part in each category .
Then simple math add up each part as though it will take as long as the longest part in each category.. Then as you complete each project , only count completely done parts , do n't give partial credit .
Recognize that if you estimate four days on a part and two days into it , you are pulled off , you still have four days that have to be made up .
Thrashing eliminates all part work not fully completed .
Now , if marketing , or your boss or whoever says , you missed this page , your estimate stands only for original design work .
New features get new estimates .
If you follow this and track your work through two or three projects , you will get better at determining the most difficult parts and learn to code those before you complete your estimate .
After doing this for a few years , you will get projects for which you can see the end and you can give better estimates from the hip .
But , never promise estimates to be more that + 200 \ % -50 \ % accurate .
I 've had many bonuses tied to finishing on time and I always get my bonuses .
Realize that I 've architected over five projects with over a million dollar budgets and each took over a year to complete all phases , some multiple years .
I also have managed teams from myself to a dozen programmers and support personal ( testers , graphic artists , tech writers , etc.. ) .
My first project did n't go that well , but after multiple projects I learned how to do it correctly .
Do n't buy into the comments here that say since so many people do estimating badly , that it is impossible .
Also , realize that you will have to read code from the programmers on your team and fire the non-performers .
And last of all , ask the programmers on your team for their estimates , but do n't use them , use your senior architect 's estimates .
If a programmer estimates long , there needs to be more training to show them how to code up whatever it is you are writing in the time the architect estimates .
If they estimate short they also need training .
You must also make sure that sub-tasks are broken down into   day to 2 days chunks .
If a programmer does n't finish the first sub-task in time , retrain or re-estimate .
You may have a boss that comes in and says , how long will this take , I want the estimate now and I do n't want you to do any design or prototyping first .
Estimate how long it will take you to find a new boss and add two weeks for notice .</tokentext>
<sentencetext>I never found accurate estimates to be all that difficult.
I don't subscribe to the extreme/agile/scrum/what ever is the latest process is in the news.
Create a design, mock up each page/dialog box whatever.
Code one up, write your unit tests.
Count up how many database tables you have, code up persistence to one and run your automated tests.
Determine how many blocks of logic you will have and code up one and test it.
You should have coded up the most difficult part in each category.
Then simple math add up each part as though it will take as long as the longest part in each category..  Then as you complete each project, only count completely done parts, don't give partial credit.
Recognize that if you estimate four days on a part and two days into it, you are pulled off, you still have four days that have to be made up.
Thrashing eliminates all part work not fully completed.
Now, if marketing, or your boss or whoever says, you missed this page, your estimate stands only for original design work.
New features get new estimates.
If you follow this and track your work through two or three projects, you will get better at determining the most difficult parts and learn to code those before you complete your estimate.
After doing this for a few years, you will get projects for which you can see the end and you can give better estimates from the hip.
But, never promise estimates to be more that +200\% -50\% accurate.
I've had many bonuses tied to finishing on time and I always get my bonuses.
Realize that I've architected over five projects with over a million dollar budgets and each took over a year to complete all phases, some multiple years.
I also have managed teams from myself to a dozen programmers and support personal (testers, graphic artists, tech writers, etc..).
My first project didn't go that well, but after multiple projects I learned how to do it correctly.
Don't buy into the comments here that say since so many people do estimating badly, that it is impossible.
Also, realize that you will have to read code from the programmers on your team and fire the non-performers.
And last of all, ask the programmers on your team for their estimates, but don't use them, use your senior architect's estimates.
If a programmer estimates long, there needs to be more training to show them how to code up whatever it is you are writing in the time the architect estimates.
If they estimate short they also need training.
You must also make sure that sub-tasks are broken down into ½ day to 2 days chunks.
If a programmer doesn't finish the first sub-task in time, retrain or re-estimate.
You may have a boss that comes in and says, how long will this take, I want the estimate now and I don't want you to do any design or prototyping first.
Estimate how long it will take you to find a new boss and add two weeks for notice.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31086818</id>
	<title>Re:W.A.G.</title>
	<author>agentultra</author>
	<datestamp>1265044800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Pretty much.  Even when you're coding to a completely laid out specification, the time it takes to understand the specification and determine how many lines of code you'll need to write to meet each point of that specification is basically equal to the time it takes to code the specification less a factor based on your typing speed.</p></div><p>If you have a specification, you're done -- as long as you consider the software the specification as I do.</p><p>Anything I receive from a client or non-technical stakeholder is just documentation of wishful thinking. It's the equivalent of a sketch on a napkin. Even if it's twenty pages and "really thorough." Unless it compiles, it doesn't specify anything.</p><p>The exception of course are specifications written by -- programmers! Unless they're n00bs with a lot of wishful thinking, these will tend to be more like blue-prints and less like napkin sketches. Unless they already compile. Even better.</p><p>If a client insists for an estimate and they aren't satisfied with the reasons for my reticence, I just let them know that it's a WAG and will be readjusted once the project moves ahead and I get a better understanding of the system and its specification.</p><p>How do I guess my WAG? I look back at past projects I've worked on that resembles what their project is going to be and pad it out from there based on numerous qualitative feelings. I ask myself, "Does this feel more or less complex? Has this client worked on software projects before? Do I trust these people? What's the worst thing that could go wrong?" That sort of thing.</p></div>
	</htmltext>
<tokenext>Pretty much .
Even when you 're coding to a completely laid out specification , the time it takes to understand the specification and determine how many lines of code you 'll need to write to meet each point of that specification is basically equal to the time it takes to code the specification less a factor based on your typing speed.If you have a specification , you 're done -- as long as you consider the software the specification as I do.Anything I receive from a client or non-technical stakeholder is just documentation of wishful thinking .
It 's the equivalent of a sketch on a napkin .
Even if it 's twenty pages and " really thorough .
" Unless it compiles , it does n't specify anything.The exception of course are specifications written by -- programmers !
Unless they 're n00bs with a lot of wishful thinking , these will tend to be more like blue-prints and less like napkin sketches .
Unless they already compile .
Even better.If a client insists for an estimate and they are n't satisfied with the reasons for my reticence , I just let them know that it 's a WAG and will be readjusted once the project moves ahead and I get a better understanding of the system and its specification.How do I guess my WAG ?
I look back at past projects I 've worked on that resembles what their project is going to be and pad it out from there based on numerous qualitative feelings .
I ask myself , " Does this feel more or less complex ?
Has this client worked on software projects before ?
Do I trust these people ?
What 's the worst thing that could go wrong ?
" That sort of thing .</tokentext>
<sentencetext>Pretty much.
Even when you're coding to a completely laid out specification, the time it takes to understand the specification and determine how many lines of code you'll need to write to meet each point of that specification is basically equal to the time it takes to code the specification less a factor based on your typing speed.If you have a specification, you're done -- as long as you consider the software the specification as I do.Anything I receive from a client or non-technical stakeholder is just documentation of wishful thinking.
It's the equivalent of a sketch on a napkin.
Even if it's twenty pages and "really thorough.
" Unless it compiles, it doesn't specify anything.The exception of course are specifications written by -- programmers!
Unless they're n00bs with a lot of wishful thinking, these will tend to be more like blue-prints and less like napkin sketches.
Unless they already compile.
Even better.If a client insists for an estimate and they aren't satisfied with the reasons for my reticence, I just let them know that it's a WAG and will be readjusted once the project moves ahead and I get a better understanding of the system and its specification.How do I guess my WAG?
I look back at past projects I've worked on that resembles what their project is going to be and pad it out from there based on numerous qualitative feelings.
I ask myself, "Does this feel more or less complex?
Has this client worked on software projects before?
Do I trust these people?
What's the worst thing that could go wrong?
" That sort of thing.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075580</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076444</id>
	<title>Re:Chop features.</title>
	<author>haruharaharu</author>
	<datestamp>1265747400000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>If you can get people to actually prioritize features, then you have a chance in hell of cutting features by plan. The common first response to such a request is to rate all features as pri 1, to which the formula response is "so you mean I can just implement in any order i like?". If business is at all reasonable, they can be brought around to at least grouping features into required, really want, nice to have, and maybe, but the first challenge there is talking to them at all. This isn't really something you should be talking to middle management about if you expect an answer in reasonable time.</htmltext>
<tokenext>If you can get people to actually prioritize features , then you have a chance in hell of cutting features by plan .
The common first response to such a request is to rate all features as pri 1 , to which the formula response is " so you mean I can just implement in any order i like ? " .
If business is at all reasonable , they can be brought around to at least grouping features into required , really want , nice to have , and maybe , but the first challenge there is talking to them at all .
This is n't really something you should be talking to middle management about if you expect an answer in reasonable time .</tokentext>
<sentencetext>If you can get people to actually prioritize features, then you have a chance in hell of cutting features by plan.
The common first response to such a request is to rate all features as pri 1, to which the formula response is "so you mean I can just implement in any order i like?".
If business is at all reasonable, they can be brought around to at least grouping features into required, really want, nice to have, and maybe, but the first challenge there is talking to them at all.
This isn't really something you should be talking to middle management about if you expect an answer in reasonable time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075610</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077324</id>
	<title>Effective Productivity</title>
	<author>James-NSC</author>
	<datestamp>1265707620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I start by rating each coders &ldquo;effective productivity&rdquo; where for an hour worked, how much time/code actually gets generated. Some will be<nobr> <wbr></nobr>.5:1 if they have to stop frequently to answer questions, some will be at<nobr> <wbr></nobr>.75:1 if they code well, know what they need to do and are stationed in a broom closet so they aren&rsquo;t interrupted, some will be<nobr> <wbr></nobr>.25:1 or even<nobr> <wbr></nobr>.1:1 because they are an intern or a new recruit.

Then I consider how long it will take to produce each section of the product (just broken down into logical groups) in a &ldquo;perfect world&rdquo; where everyone is coding at 1:1. I then apply each members effective productivity to that time for each logical group. I then add 20\%-40\% to each individual module I broke it down into, depending on how complete the requirements, specifications, etc are going into that module where 20 is better, 40 is worse (usually). So if I had five modules, time of each would expand by at minimum 20\%+ the expansion of the effective productivity of those working on it. Then add all the time up, add 30\% for testing then 20\% buffer and you&rsquo;ll find, surprisingly, you&rsquo;re stabbing at a number that is as realistic as you can make it this early in the game. You also have a number that can be presented to those outside of IT and, dressed up with the math, presents an estimate that is based on real numbers and is quite hard to argue with. Ultimately, it&rsquo;s a more formalized SWAG, all programming estimates have Some Wild Ass Guess in them though, as quantifying the time involved in being creative is quite hard to do.</htmltext>
<tokenext>I start by rating each coders    effective productivity    where for an hour worked , how much time/code actually gets generated .
Some will be .5 : 1 if they have to stop frequently to answer questions , some will be at .75 : 1 if they code well , know what they need to do and are stationed in a broom closet so they aren    t interrupted , some will be .25 : 1 or even .1 : 1 because they are an intern or a new recruit .
Then I consider how long it will take to produce each section of the product ( just broken down into logical groups ) in a    perfect world    where everyone is coding at 1 : 1 .
I then apply each members effective productivity to that time for each logical group .
I then add 20 \ % -40 \ % to each individual module I broke it down into , depending on how complete the requirements , specifications , etc are going into that module where 20 is better , 40 is worse ( usually ) .
So if I had five modules , time of each would expand by at minimum 20 \ % + the expansion of the effective productivity of those working on it .
Then add all the time up , add 30 \ % for testing then 20 \ % buffer and you    ll find , surprisingly , you    re stabbing at a number that is as realistic as you can make it this early in the game .
You also have a number that can be presented to those outside of IT and , dressed up with the math , presents an estimate that is based on real numbers and is quite hard to argue with .
Ultimately , it    s a more formalized SWAG , all programming estimates have Some Wild Ass Guess in them though , as quantifying the time involved in being creative is quite hard to do .</tokentext>
<sentencetext>I start by rating each coders “effective productivity” where for an hour worked, how much time/code actually gets generated.
Some will be .5:1 if they have to stop frequently to answer questions, some will be at .75:1 if they code well, know what they need to do and are stationed in a broom closet so they aren’t interrupted, some will be .25:1 or even .1:1 because they are an intern or a new recruit.
Then I consider how long it will take to produce each section of the product (just broken down into logical groups) in a “perfect world” where everyone is coding at 1:1.
I then apply each members effective productivity to that time for each logical group.
I then add 20\%-40\% to each individual module I broke it down into, depending on how complete the requirements, specifications, etc are going into that module where 20 is better, 40 is worse (usually).
So if I had five modules, time of each would expand by at minimum 20\%+ the expansion of the effective productivity of those working on it.
Then add all the time up, add 30\% for testing then 20\% buffer and you’ll find, surprisingly, you’re stabbing at a number that is as realistic as you can make it this early in the game.
You also have a number that can be presented to those outside of IT and, dressed up with the math, presents an estimate that is based on real numbers and is quite hard to argue with.
Ultimately, it’s a more formalized SWAG, all programming estimates have Some Wild Ass Guess in them though, as quantifying the time involved in being creative is quite hard to do.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076084</id>
	<title>Re:Multiply by Three</title>
	<author>computational super</author>
	<datestamp>1265745960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>Break the program into it's component parts.</i>
<p>a) You spent more time "breaking the program into it's component parts" than you would have spent just writing the damned thing.</p><p>b) The component parts you came up with aren't the component parts you actually end up needing.</p></htmltext>
<tokenext>Break the program into it 's component parts .
a ) You spent more time " breaking the program into it 's component parts " than you would have spent just writing the damned thing.b ) The component parts you came up with are n't the component parts you actually end up needing .</tokentext>
<sentencetext>Break the program into it's component parts.
a) You spent more time "breaking the program into it's component parts" than you would have spent just writing the damned thing.b) The component parts you came up with aren't the component parts you actually end up needing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075434</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076014</id>
	<title>Re:Quid pro quo</title>
	<author>computational super</author>
	<datestamp>1265745780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Them: "How long is it going to take?"</p><p>Me: "Well, I can't estimate it until the specs are finished."</p><p>Them: "Well, then how long will it take until the specs are finished?"</p><p>Me: "Ah-ha..."</p></htmltext>
<tokenext>Them : " How long is it going to take ?
" Me : " Well , I ca n't estimate it until the specs are finished .
" Them : " Well , then how long will it take until the specs are finished ?
" Me : " Ah-ha... "</tokentext>
<sentencetext>Them: "How long is it going to take?
"Me: "Well, I can't estimate it until the specs are finished.
"Them: "Well, then how long will it take until the specs are finished?
"Me: "Ah-ha..."</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075338</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076534</id>
	<title>Re:Well, I *used* to use the entrails of goats...</title>
	<author>haruharaharu</author>
	<datestamp>1265747640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>One of the tea drinkers from my last job was ex-navy. I don't think I'll be taking his cup any time soon.</htmltext>
<tokenext>One of the tea drinkers from my last job was ex-navy .
I do n't think I 'll be taking his cup any time soon .</tokentext>
<sentencetext>One of the tea drinkers from my last job was ex-navy.
I don't think I'll be taking his cup any time soon.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080528</id>
	<title>Re:Well, I *used* to use the entrails of goats...</title>
	<author>Anonymous</author>
	<datestamp>1265722620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'm a tea drinker, you insensitive clod!</p></htmltext>
<tokenext>I 'm a tea drinker , you insensitive clod !</tokentext>
<sentencetext>I'm a tea drinker, you insensitive clod!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016</id>
	<title>Re:Function Point Analysis and Man Hours</title>
	<author>boaworm</author>
	<datestamp>1265706360000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p>I always learned it like this:</p><p>1) Make a guess, very generous one. Make sure there's plenty of space.<br>2) Double it, as you will need an equal amount of time for testing and bugfixing when you're done writing.<br>3) Double it again, as Murphy will make sure everything will fail, which will lead to inevitable delays.<br>4) Multiple by PI</p><p>Now you're pretty close to a realistic estimate!</p></htmltext>
<tokenext>I always learned it like this : 1 ) Make a guess , very generous one .
Make sure there 's plenty of space.2 ) Double it , as you will need an equal amount of time for testing and bugfixing when you 're done writing.3 ) Double it again , as Murphy will make sure everything will fail , which will lead to inevitable delays.4 ) Multiple by PINow you 're pretty close to a realistic estimate !</tokentext>
<sentencetext>I always learned it like this:1) Make a guess, very generous one.
Make sure there's plenty of space.2) Double it, as you will need an equal amount of time for testing and bugfixing when you're done writing.3) Double it again, as Murphy will make sure everything will fail, which will lead to inevitable delays.4) Multiple by PINow you're pretty close to a realistic estimate!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079198</id>
	<title>Formula</title>
	<author>Anonymous</author>
	<datestamp>1265715240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I have always used a <a href="http://en.wikipedia.org/wiki/Markov\_model" title="wikipedia.org" rel="nofollow">Markov</a> [wikipedia.org] process such that development time will end up being within several days of :

The summation from 1 to the total number of development tasks of the gamma of the summation from 1 to the number of developers of the zeta of the probability of the risk of ruin of a,b times the base-two log of the probability of the risk of ruin of a,b + one month.

Kindof like <a href="http://en.wikipedia.org/wiki/Information\_entropy#Data\_as\_a\_Markov\_process" title="wikipedia.org" rel="nofollow">this</a> [wikipedia.org] give or take a few bits.</htmltext>
<tokenext>I have always used a Markov [ wikipedia.org ] process such that development time will end up being within several days of : The summation from 1 to the total number of development tasks of the gamma of the summation from 1 to the number of developers of the zeta of the probability of the risk of ruin of a,b times the base-two log of the probability of the risk of ruin of a,b + one month .
Kindof like this [ wikipedia.org ] give or take a few bits .</tokentext>
<sentencetext>I have always used a Markov [wikipedia.org] process such that development time will end up being within several days of :

The summation from 1 to the total number of development tasks of the gamma of the summation from 1 to the number of developers of the zeta of the probability of the risk of ruin of a,b times the base-two log of the probability of the risk of ruin of a,b + one month.
Kindof like this [wikipedia.org] give or take a few bits.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076624</id>
	<title>Re:Uhh, Scrum is not an estimation method</title>
	<author>haruharaharu</author>
	<datestamp>1265748060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Wait, you said it doesn't make sense, then demonstrated that it did - are you confused or just overly clever?</htmltext>
<tokenext>Wait , you said it does n't make sense , then demonstrated that it did - are you confused or just overly clever ?</tokentext>
<sentencetext>Wait, you said it doesn't make sense, then demonstrated that it did - are you confused or just overly clever?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31089880</id>
	<title>Re:Function Point Analysis and Man Hours</title>
	<author>b4dc0d3r</author>
	<datestamp>1265057520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'd moderate this retarded if I could, but it's not an option.  Probably Palin had it removed.  Anyway, allow me to explain.</p><p>Not sure if I'm being clear here, but a "standard change" is not an estimate - it's something we've done before and know exactly how long it takes.  If you are doing any actual estimating, the more "estimating" you do vs. using historical data, the more range of error you'll have.  I'll babble on this subject for a while, but that's the gist of this post.</p><p>There are different types of changes.  If you're estimating something you've done a hundred times, you know exactly how long it will take.  Something like custom configuration for a client, routine maintenance, things like that.  You'll be correct on how long it takes.</p><p>If a customer wants a new web service, and you've never done a web service, you're going to be wrong no matter how much you quantify.  You can determine how many objects you need to create/update, but you can't tell how long it will take.</p><p>In other words, estimating has to take into account many different things:</p><p>How many objects will be updated/added<br>How many of those will be trivial vs. complex changes<br>Level of familiarity of the person/people implementing it<br>Assumption that the number of objects is correct, and nothing was missed<br>Necessary documentation available *and correct*<br>Historical accuracy of estimating (are you getting better at estimating overall?)<br>Historical accuracy of estimating the kind of change requested (are you getting better at estimating *this*?)<br>Overhead of gates/reviews and change control or other process<br>Testing resource availability, familiarity with the new items, correct documentation supplied to whomever is testing</p><p>If MSDN or man page isn't correct, you're going to do a lot of debugging.  If the client's web service you're connecting to doesn't match what you were given, you're doing rewrites once you hit testing.  If your change is ready to go but a company-wide routing change is scheduled for the same date so you can't test your implementation, you're stuck.  If the CSS works until someone enters a long comment, and you need to find a workaround to the layout, you're better off just saying won't fix.</p><p>Bottom line, the more foreign something is, the more incorrect you will be.  If you are estimating something you've already done, there's not need to estimate - it's already done!  So by definition, we are either dealing with something simple like search/replace and run, or something foreign where you're going to be wrong no matter what.</p><p>I'll close with - in a modern company, all code should be reusable.  So you only do things once.  So you can't learn to estimate more accurately, since you're always estimating something different.  The only way to have accurate estimating is to have a solid team working together for a while, and doing similar work.  Just limit yourself to things you know, and you'll be right.</p></htmltext>
<tokenext>I 'd moderate this retarded if I could , but it 's not an option .
Probably Palin had it removed .
Anyway , allow me to explain.Not sure if I 'm being clear here , but a " standard change " is not an estimate - it 's something we 've done before and know exactly how long it takes .
If you are doing any actual estimating , the more " estimating " you do vs. using historical data , the more range of error you 'll have .
I 'll babble on this subject for a while , but that 's the gist of this post.There are different types of changes .
If you 're estimating something you 've done a hundred times , you know exactly how long it will take .
Something like custom configuration for a client , routine maintenance , things like that .
You 'll be correct on how long it takes.If a customer wants a new web service , and you 've never done a web service , you 're going to be wrong no matter how much you quantify .
You can determine how many objects you need to create/update , but you ca n't tell how long it will take.In other words , estimating has to take into account many different things : How many objects will be updated/addedHow many of those will be trivial vs. complex changesLevel of familiarity of the person/people implementing itAssumption that the number of objects is correct , and nothing was missedNecessary documentation available * and correct * Historical accuracy of estimating ( are you getting better at estimating overall ?
) Historical accuracy of estimating the kind of change requested ( are you getting better at estimating * this * ?
) Overhead of gates/reviews and change control or other processTesting resource availability , familiarity with the new items , correct documentation supplied to whomever is testingIf MSDN or man page is n't correct , you 're going to do a lot of debugging .
If the client 's web service you 're connecting to does n't match what you were given , you 're doing rewrites once you hit testing .
If your change is ready to go but a company-wide routing change is scheduled for the same date so you ca n't test your implementation , you 're stuck .
If the CSS works until someone enters a long comment , and you need to find a workaround to the layout , you 're better off just saying wo n't fix.Bottom line , the more foreign something is , the more incorrect you will be .
If you are estimating something you 've already done , there 's not need to estimate - it 's already done !
So by definition , we are either dealing with something simple like search/replace and run , or something foreign where you 're going to be wrong no matter what.I 'll close with - in a modern company , all code should be reusable .
So you only do things once .
So you ca n't learn to estimate more accurately , since you 're always estimating something different .
The only way to have accurate estimating is to have a solid team working together for a while , and doing similar work .
Just limit yourself to things you know , and you 'll be right .</tokentext>
<sentencetext>I'd moderate this retarded if I could, but it's not an option.
Probably Palin had it removed.
Anyway, allow me to explain.Not sure if I'm being clear here, but a "standard change" is not an estimate - it's something we've done before and know exactly how long it takes.
If you are doing any actual estimating, the more "estimating" you do vs. using historical data, the more range of error you'll have.
I'll babble on this subject for a while, but that's the gist of this post.There are different types of changes.
If you're estimating something you've done a hundred times, you know exactly how long it will take.
Something like custom configuration for a client, routine maintenance, things like that.
You'll be correct on how long it takes.If a customer wants a new web service, and you've never done a web service, you're going to be wrong no matter how much you quantify.
You can determine how many objects you need to create/update, but you can't tell how long it will take.In other words, estimating has to take into account many different things:How many objects will be updated/addedHow many of those will be trivial vs. complex changesLevel of familiarity of the person/people implementing itAssumption that the number of objects is correct, and nothing was missedNecessary documentation available *and correct*Historical accuracy of estimating (are you getting better at estimating overall?
)Historical accuracy of estimating the kind of change requested (are you getting better at estimating *this*?
)Overhead of gates/reviews and change control or other processTesting resource availability, familiarity with the new items, correct documentation supplied to whomever is testingIf MSDN or man page isn't correct, you're going to do a lot of debugging.
If the client's web service you're connecting to doesn't match what you were given, you're doing rewrites once you hit testing.
If your change is ready to go but a company-wide routing change is scheduled for the same date so you can't test your implementation, you're stuck.
If the CSS works until someone enters a long comment, and you need to find a workaround to the layout, you're better off just saying won't fix.Bottom line, the more foreign something is, the more incorrect you will be.
If you are estimating something you've already done, there's not need to estimate - it's already done!
So by definition, we are either dealing with something simple like search/replace and run, or something foreign where you're going to be wrong no matter what.I'll close with - in a modern company, all code should be reusable.
So you only do things once.
So you can't learn to estimate more accurately, since you're always estimating something different.
The only way to have accurate estimating is to have a solid team working together for a while, and doing similar work.
Just limit yourself to things you know, and you'll be right.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077240</id>
	<title>Suvro Upadhyaya is a confidence man</title>
	<author>syousef</author>
	<datestamp>1265707260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Suvro Upadhyaya, a Senior Software Engineer at Oracle is a liar and a con man. Quite simple really.</p><p>Scrum is the latest in a long line of religions I'm sorry I mean methodologies that claims to achieve the unachievable. I propose a new advanced version of Scrum called Scrotum. It's the same as scrum but Ridiculously Overtly Titsup.</p></htmltext>
<tokenext>Suvro Upadhyaya , a Senior Software Engineer at Oracle is a liar and a con man .
Quite simple really.Scrum is the latest in a long line of religions I 'm sorry I mean methodologies that claims to achieve the unachievable .
I propose a new advanced version of Scrum called Scrotum .
It 's the same as scrum but Ridiculously Overtly Titsup .</tokentext>
<sentencetext>Suvro Upadhyaya, a Senior Software Engineer at Oracle is a liar and a con man.
Quite simple really.Scrum is the latest in a long line of religions I'm sorry I mean methodologies that claims to achieve the unachievable.
I propose a new advanced version of Scrum called Scrotum.
It's the same as scrum but Ridiculously Overtly Titsup.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083372</id>
	<title>Sounds like Evidence-Based Scheduling</title>
	<author>jonaskoelker</author>
	<datestamp>1265019240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That sounds almost exactly like what Joel Spolsky talked about ("Evidence Based Scheduling") in his article at <a href="http://www.joelonsoftware.com/items/2007/10/26.html" title="joelonsoftware.com">http://www.joelonsoftware.com/items/2007/10/26.html</a> [joelonsoftware.com]</p></htmltext>
<tokenext>That sounds almost exactly like what Joel Spolsky talked about ( " Evidence Based Scheduling " ) in his article at http : //www.joelonsoftware.com/items/2007/10/26.html [ joelonsoftware.com ]</tokentext>
<sentencetext>That sounds almost exactly like what Joel Spolsky talked about ("Evidence Based Scheduling") in his article at http://www.joelonsoftware.com/items/2007/10/26.html [joelonsoftware.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075748</id>
	<title>How Do You Accurately Estimate Programming Time?</title>
	<author>weicco</author>
	<datestamp>1265744940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't.</p><p>There are situations where I can take a wild guess but questioner must understand that a) it's a wild guess b) it only works in perfect world and if something goes wrong, and especially if that something is something I have no power over with, then you can safely double my bet. These situations are like if I'm asked to write some web based app for people who really don't know what they want. (Web based apps are for some reason really hard for me)</p><p>Then there are situations where I can take an educated guess. These are typically situations where I've written same kind of application before. These situations are starting to come more and more common now when I have ten years of professional programming experience behind me.</p><p>But if you keep gun to my head and demand exact estimate (can estimate even be exact?) then you could just go ahead and shoot me.</p></htmltext>
<tokenext>I do n't.There are situations where I can take a wild guess but questioner must understand that a ) it 's a wild guess b ) it only works in perfect world and if something goes wrong , and especially if that something is something I have no power over with , then you can safely double my bet .
These situations are like if I 'm asked to write some web based app for people who really do n't know what they want .
( Web based apps are for some reason really hard for me ) Then there are situations where I can take an educated guess .
These are typically situations where I 've written same kind of application before .
These situations are starting to come more and more common now when I have ten years of professional programming experience behind me.But if you keep gun to my head and demand exact estimate ( can estimate even be exact ?
) then you could just go ahead and shoot me .</tokentext>
<sentencetext>I don't.There are situations where I can take a wild guess but questioner must understand that a) it's a wild guess b) it only works in perfect world and if something goes wrong, and especially if that something is something I have no power over with, then you can safely double my bet.
These situations are like if I'm asked to write some web based app for people who really don't know what they want.
(Web based apps are for some reason really hard for me)Then there are situations where I can take an educated guess.
These are typically situations where I've written same kind of application before.
These situations are starting to come more and more common now when I have ten years of professional programming experience behind me.But if you keep gun to my head and demand exact estimate (can estimate even be exact?
) then you could just go ahead and shoot me.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080594</id>
	<title>Agile and punting</title>
	<author>drew\_eckhardt</author>
	<datestamp>1265722980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Break everything down into approximately 3 ideal day pieces including unit + system test and adjust to real days using the velocity observed doing similar things in the same environment and you're likely to get close (within a factor of two).</p><p>You might get within an order of magnitude (days, weeks, months, years) without the low level design.</p><p>A lesser multiplier than order of magnitude generally applies when you haven't done similar things before.</p><p>And an even smaller multiplier  (2-4) is likely where the environment changed (more customer support overhead, move from offices to cubicles etc.)</p><p>Having all the necessary conditions satisfied for accurate estimates can be unlikely in early stage startups.</p></htmltext>
<tokenext>Break everything down into approximately 3 ideal day pieces including unit + system test and adjust to real days using the velocity observed doing similar things in the same environment and you 're likely to get close ( within a factor of two ) .You might get within an order of magnitude ( days , weeks , months , years ) without the low level design.A lesser multiplier than order of magnitude generally applies when you have n't done similar things before.And an even smaller multiplier ( 2-4 ) is likely where the environment changed ( more customer support overhead , move from offices to cubicles etc .
) Having all the necessary conditions satisfied for accurate estimates can be unlikely in early stage startups .</tokentext>
<sentencetext>Break everything down into approximately 3 ideal day pieces including unit + system test and adjust to real days using the velocity observed doing similar things in the same environment and you're likely to get close (within a factor of two).You might get within an order of magnitude (days, weeks, months, years) without the low level design.A lesser multiplier than order of magnitude generally applies when you haven't done similar things before.And an even smaller multiplier  (2-4) is likely where the environment changed (more customer support overhead, move from offices to cubicles etc.
)Having all the necessary conditions satisfied for accurate estimates can be unlikely in early stage startups.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079828</id>
	<title>Re:Evidence-based scheduling</title>
	<author>russotto</author>
	<datestamp>1265718180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Joel Spolsky has a method which ostensibly accommodates for consistent over- or under-estimating by any individual developer. It takes a couple release cycles to collect the necessary information, then tries to use that data to provide a likelihood that a product will ship by a given date.</p></div></blockquote><p>Doesn't work.  It turns out if you collect the necessary information properly, the product is invariably canceled as soon as you have enough information to make a schedule.</p><p>Seriously, his method fails at Step 1 -- "You have to break your schedule into very small tasks that can be measured in hours. Nothing longer than 16 hours. "  I've never been on a project which had a detailed design to that level by the time a schedule was demanded.</p></div>
	</htmltext>
<tokenext>Joel Spolsky has a method which ostensibly accommodates for consistent over- or under-estimating by any individual developer .
It takes a couple release cycles to collect the necessary information , then tries to use that data to provide a likelihood that a product will ship by a given date.Does n't work .
It turns out if you collect the necessary information properly , the product is invariably canceled as soon as you have enough information to make a schedule.Seriously , his method fails at Step 1 -- " You have to break your schedule into very small tasks that can be measured in hours .
Nothing longer than 16 hours .
" I 've never been on a project which had a detailed design to that level by the time a schedule was demanded .</tokentext>
<sentencetext>Joel Spolsky has a method which ostensibly accommodates for consistent over- or under-estimating by any individual developer.
It takes a couple release cycles to collect the necessary information, then tries to use that data to provide a likelihood that a product will ship by a given date.Doesn't work.
It turns out if you collect the necessary information properly, the product is invariably canceled as soon as you have enough information to make a schedule.Seriously, his method fails at Step 1 -- "You have to break your schedule into very small tasks that can be measured in hours.
Nothing longer than 16 hours.
"  I've never been on a project which had a detailed design to that level by the time a schedule was demanded.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076190</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077116</id>
	<title>easy</title>
	<author>kdemetter</author>
	<datestamp>1265706720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Make your estimation , than do that time x2 .</p><p>No matter how good you estimate things, there is always a chance things can go wrong , and the less room you leave for that , the higher the chance something will actually go wrong ( Murphy's law ? )</p></htmltext>
<tokenext>Make your estimation , than do that time x2 .No matter how good you estimate things , there is always a chance things can go wrong , and the less room you leave for that , the higher the chance something will actually go wrong ( Murphy 's law ?
)</tokentext>
<sentencetext>Make your estimation , than do that time x2 .No matter how good you estimate things, there is always a chance things can go wrong , and the less room you leave for that , the higher the chance something will actually go wrong ( Murphy's law ?
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083628</id>
	<title>Re:It's Easy</title>
	<author>Realistic\_Dragon</author>
	<datestamp>1265023200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I have actually written some software to plan projects this way (working backwards from deadlines), as it's basically how things work in reality.<br><br>If anyone's interested I'd be happy to hand out a few beta invites.</htmltext>
<tokenext>I have actually written some software to plan projects this way ( working backwards from deadlines ) , as it 's basically how things work in reality.If anyone 's interested I 'd be happy to hand out a few beta invites .</tokentext>
<sentencetext>I have actually written some software to plan projects this way (working backwards from deadlines), as it's basically how things work in reality.If anyone's interested I'd be happy to hand out a few beta invites.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075750</id>
	<title>My Method...</title>
	<author>gers0667</author>
	<datestamp>1265744940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Think of the time it will take in an optimal environment.</p><p>Multiple by 3.</p></htmltext>
<tokenext>Think of the time it will take in an optimal environment.Multiple by 3 .</tokentext>
<sentencetext>Think of the time it will take in an optimal environment.Multiple by 3.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076888</id>
	<title>I don't.</title>
	<author>fredjh</author>
	<datestamp>1265749140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That is, I don't accurately estimate programming time.  The people here get pissed, but too bad... they give me a project, I say it'll take me x number of days, then they keep changing what they want and get mad at me when x comes and goes and I'm not done.</p><p>Oh well.</p></htmltext>
<tokenext>That is , I do n't accurately estimate programming time .
The people here get pissed , but too bad... they give me a project , I say it 'll take me x number of days , then they keep changing what they want and get mad at me when x comes and goes and I 'm not done.Oh well .</tokentext>
<sentencetext>That is, I don't accurately estimate programming time.
The people here get pissed, but too bad... they give me a project, I say it'll take me x number of days, then they keep changing what they want and get mad at me when x comes and goes and I'm not done.Oh well.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082702</id>
	<title>Re:Simply, no software required.</title>
	<author>YeeHaW\_Jelte</author>
	<datestamp>1265054700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"Manage expectations, and don't let the customer down (particularly when things are outside my control)."</p><p>As interesting as the Anderson method for estimations is, I find it more usefull to present customers not with a single estimate but a range. It'll be done in 5-10 days e.g. The more unknowns, the wider the range. The farther into the project, the tighter the range.</p><p>This gives the client a usefull insight in the unknowns of software development, and sets his or her mind to the realities of it. Their expectations are more realistic, and if you manage to finish within the range; you've a happy customer.</p></htmltext>
<tokenext>" Manage expectations , and do n't let the customer down ( particularly when things are outside my control ) .
" As interesting as the Anderson method for estimations is , I find it more usefull to present customers not with a single estimate but a range .
It 'll be done in 5-10 days e.g .
The more unknowns , the wider the range .
The farther into the project , the tighter the range.This gives the client a usefull insight in the unknowns of software development , and sets his or her mind to the realities of it .
Their expectations are more realistic , and if you manage to finish within the range ; you 've a happy customer .</tokentext>
<sentencetext>"Manage expectations, and don't let the customer down (particularly when things are outside my control).
"As interesting as the Anderson method for estimations is, I find it more usefull to present customers not with a single estimate but a range.
It'll be done in 5-10 days e.g.
The more unknowns, the wider the range.
The farther into the project, the tighter the range.This gives the client a usefull insight in the unknowns of software development, and sets his or her mind to the realities of it.
Their expectations are more realistic, and if you manage to finish within the range; you've a happy customer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075866</id>
	<title>Re:Chop features.</title>
	<author>Hognoxious</author>
	<datestamp>1265745300000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><blockquote><div><p>features usually get cut by chance rather than by plan since no one wants to give up on anything, including the deadline.</p></div> </blockquote><p>Have you ever asked which feature has the highest priority, and received the answer, "all of them"?</p><p>The type of twits who give that answer always think they're combining the wit of Oscar Wilde, the insight of Confucius and the cock of John Holmes.</p></div>
	</htmltext>
<tokenext>features usually get cut by chance rather than by plan since no one wants to give up on anything , including the deadline .
Have you ever asked which feature has the highest priority , and received the answer , " all of them " ? The type of twits who give that answer always think they 're combining the wit of Oscar Wilde , the insight of Confucius and the cock of John Holmes .</tokentext>
<sentencetext>features usually get cut by chance rather than by plan since no one wants to give up on anything, including the deadline.
Have you ever asked which feature has the highest priority, and received the answer, "all of them"?The type of twits who give that answer always think they're combining the wit of Oscar Wilde, the insight of Confucius and the cock of John Holmes.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075610</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079444</id>
	<title>Re:Chop features.</title>
	<author>poopdeville</author>
	<datestamp>1265716260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Don't ask about priorities.  Ask what you should work on first.</p></htmltext>
<tokenext>Do n't ask about priorities .
Ask what you should work on first .</tokentext>
<sentencetext>Don't ask about priorities.
Ask what you should work on first.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075866</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075944</id>
	<title>Software Estimation: Demystifying the Black Art</title>
	<author>strimpster</author>
	<datestamp>1265745540000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>I would recommend reading "Software Estimation: Demystifying the Black Art" [http://www.stevemcconnell.com/est.htm]. When estimates are created, there are many tasks besides "programming" that need to be done that are totally forgot about in the estimates and thus throws things off from the very beginning. We have to admit from the beginning that it is an estimate and is hinged with certain unknowns. If the unknowns are cleared up, we can be more accurate with our quoting (this is why requirements gathering should be done with careful attention). Also, since the estimates are just that, they need to not just be a number, but more of a range (if you have to give a number, choose the far end and be sure that you are confident that it can be accomplished by then - with a minimum of 90\% certainty - and give the confidence with the estimate). One thing that I have learned is that I never negotiate on estimates/price, I only negotiate on functionality. If a manager/client wants it quicker/cheaper/less hours, fine, but I'm not going to change the number unless the functionality changes or more unknowns are cleared up (helping me to quote more accurately).</div>
	</htmltext>
<tokenext>I would recommend reading " Software Estimation : Demystifying the Black Art " [ http : //www.stevemcconnell.com/est.htm ] .
When estimates are created , there are many tasks besides " programming " that need to be done that are totally forgot about in the estimates and thus throws things off from the very beginning .
We have to admit from the beginning that it is an estimate and is hinged with certain unknowns .
If the unknowns are cleared up , we can be more accurate with our quoting ( this is why requirements gathering should be done with careful attention ) .
Also , since the estimates are just that , they need to not just be a number , but more of a range ( if you have to give a number , choose the far end and be sure that you are confident that it can be accomplished by then - with a minimum of 90 \ % certainty - and give the confidence with the estimate ) .
One thing that I have learned is that I never negotiate on estimates/price , I only negotiate on functionality .
If a manager/client wants it quicker/cheaper/less hours , fine , but I 'm not going to change the number unless the functionality changes or more unknowns are cleared up ( helping me to quote more accurately ) .</tokentext>
<sentencetext>I would recommend reading "Software Estimation: Demystifying the Black Art" [http://www.stevemcconnell.com/est.htm].
When estimates are created, there are many tasks besides "programming" that need to be done that are totally forgot about in the estimates and thus throws things off from the very beginning.
We have to admit from the beginning that it is an estimate and is hinged with certain unknowns.
If the unknowns are cleared up, we can be more accurate with our quoting (this is why requirements gathering should be done with careful attention).
Also, since the estimates are just that, they need to not just be a number, but more of a range (if you have to give a number, choose the far end and be sure that you are confident that it can be accomplished by then - with a minimum of 90\% certainty - and give the confidence with the estimate).
One thing that I have learned is that I never negotiate on estimates/price, I only negotiate on functionality.
If a manager/client wants it quicker/cheaper/less hours, fine, but I'm not going to change the number unless the functionality changes or more unknowns are cleared up (helping me to quote more accurately).
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075266</id>
	<title>Re:Why does a dog lick his balls?</title>
	<author>Anonymous</author>
	<datestamp>1265743320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"By implementing it and then telling them how long it has taken".</p><p>It's a bit like writing the specs AFTER coding the tool. Makes it heaps easier to deliver everything according to spec.</p></htmltext>
<tokenext>" By implementing it and then telling them how long it has taken " .It 's a bit like writing the specs AFTER coding the tool .
Makes it heaps easier to deliver everything according to spec .</tokentext>
<sentencetext>"By implementing it and then telling them how long it has taken".It's a bit like writing the specs AFTER coding the tool.
Makes it heaps easier to deliver everything according to spec.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075104</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079812</id>
	<title>easy</title>
	<author>StillNeedMoreCoffee</author>
	<datestamp>1265718120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>With a stopwatch!</p></htmltext>
<tokenext>With a stopwatch !</tokentext>
<sentencetext>With a stopwatch!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076726</id>
	<title>Re:Simply, no software required.</title>
	<author>kill-1</author>
	<datestamp>1265748540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Personally, I always use 2 * T3. Has always worked out nice for me, but those were all rather small projects.</p></htmltext>
<tokenext>Personally , I always use 2 * T3 .
Has always worked out nice for me , but those were all rather small projects .</tokentext>
<sentencetext>Personally, I always use 2 * T3.
Has always worked out nice for me, but those were all rather small projects.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078342</id>
	<title>Estimates</title>
	<author>RAMMS+EIN</author>
	<datestamp>1265711640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think the important thing to remember here is that estimates are \_estimates\_.</p><p>Based on limited information about what the customer wants, the availability/productivity of the team (people get sick, have good days and bad days,<nobr> <wbr></nobr>...), the bugs in the libraries you're working with, and the occurrence of disasters, you come up with an honest estimate.</p><p>It may be wildly wrong.</p><p>But that's your estimate.</p><p>Now, if the organization is going to raise that estimate to a sort of divine decree that The Project Shall Take That Long, and you'll only get resources for that many hours, and there will be a deadline which has already been agreed on with the customer, and you will get flamed if you miss the deadline (all these things are very likely), then perhaps you'd best not tell anyone your honest estimate.</p><p>Don't tell anyone how long you think it will take. Tell them how long you will need to be sure you get everything implemented, even if your team is sick half of the time, the scope keeps changing, and the libraries are so buggy that you'll end up spending more time than if you had written them yourself. Cause that's what will happen. And if, by some miracle, you still manage to finish early, that will be a happy surprise for management and a good mark for you.</p><p>I apply this technique, and while my colleagues always think my "estimates" are ridiculously high and what we end up reporting is usually adjusted downward a bit, it's spooky how often the ridiculously high numbers turn out to be right.</p></htmltext>
<tokenext>I think the important thing to remember here is that estimates are \ _estimates \ _.Based on limited information about what the customer wants , the availability/productivity of the team ( people get sick , have good days and bad days , ... ) , the bugs in the libraries you 're working with , and the occurrence of disasters , you come up with an honest estimate.It may be wildly wrong.But that 's your estimate.Now , if the organization is going to raise that estimate to a sort of divine decree that The Project Shall Take That Long , and you 'll only get resources for that many hours , and there will be a deadline which has already been agreed on with the customer , and you will get flamed if you miss the deadline ( all these things are very likely ) , then perhaps you 'd best not tell anyone your honest estimate.Do n't tell anyone how long you think it will take .
Tell them how long you will need to be sure you get everything implemented , even if your team is sick half of the time , the scope keeps changing , and the libraries are so buggy that you 'll end up spending more time than if you had written them yourself .
Cause that 's what will happen .
And if , by some miracle , you still manage to finish early , that will be a happy surprise for management and a good mark for you.I apply this technique , and while my colleagues always think my " estimates " are ridiculously high and what we end up reporting is usually adjusted downward a bit , it 's spooky how often the ridiculously high numbers turn out to be right .</tokentext>
<sentencetext>I think the important thing to remember here is that estimates are \_estimates\_.Based on limited information about what the customer wants, the availability/productivity of the team (people get sick, have good days and bad days, ...), the bugs in the libraries you're working with, and the occurrence of disasters, you come up with an honest estimate.It may be wildly wrong.But that's your estimate.Now, if the organization is going to raise that estimate to a sort of divine decree that The Project Shall Take That Long, and you'll only get resources for that many hours, and there will be a deadline which has already been agreed on with the customer, and you will get flamed if you miss the deadline (all these things are very likely), then perhaps you'd best not tell anyone your honest estimate.Don't tell anyone how long you think it will take.
Tell them how long you will need to be sure you get everything implemented, even if your team is sick half of the time, the scope keeps changing, and the libraries are so buggy that you'll end up spending more time than if you had written them yourself.
Cause that's what will happen.
And if, by some miracle, you still manage to finish early, that will be a happy surprise for management and a good mark for you.I apply this technique, and while my colleagues always think my "estimates" are ridiculously high and what we end up reporting is usually adjusted downward a bit, it's spooky how often the ridiculously high numbers turn out to be right.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077782</id>
	<title>"Just guess"</title>
	<author>NYMeatball</author>
	<datestamp>1265709600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>That's what my non-technical manager/boss tells me, so why should I bother doing anything different?</htmltext>
<tokenext>That 's what my non-technical manager/boss tells me , so why should I bother doing anything different ?</tokentext>
<sentencetext>That's what my non-technical manager/boss tells me, so why should I bother doing anything different?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</id>
	<title>Uhh, Scrum is not an estimation method</title>
	<author>pclminion</author>
	<datestamp>1265743860000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>Scrum is a way of chunking development into well-defined portions. The idea of using Scrum to estimate time just doesn't make sense. Everything in Scrum takes the same amount of time. Two weeks. (Or one week, or whatever your sprint length is.) The difference is that long projects are implemented over multiple sprints, since obviously, not everything can be done in two weeks. So the estimate is not of how long it will take, but how many backlog items will be required in order to reach some known endpoint. Once the backlogs have been created and agreed upon by the team, estimating the necessary time becomes a matter of multiplication: 12 backlogs * 2 weeks = 24 weeks to finish this product.</p><p>This makes you shift your thinking from "how long will it take to do all these things" to "how can I break this product development into chunks which each fit into a two-week period?" That's much easier than making wild-ass guesses about the time it takes to do something.</p></htmltext>
<tokenext>Scrum is a way of chunking development into well-defined portions .
The idea of using Scrum to estimate time just does n't make sense .
Everything in Scrum takes the same amount of time .
Two weeks .
( Or one week , or whatever your sprint length is .
) The difference is that long projects are implemented over multiple sprints , since obviously , not everything can be done in two weeks .
So the estimate is not of how long it will take , but how many backlog items will be required in order to reach some known endpoint .
Once the backlogs have been created and agreed upon by the team , estimating the necessary time becomes a matter of multiplication : 12 backlogs * 2 weeks = 24 weeks to finish this product.This makes you shift your thinking from " how long will it take to do all these things " to " how can I break this product development into chunks which each fit into a two-week period ?
" That 's much easier than making wild-ass guesses about the time it takes to do something .</tokentext>
<sentencetext>Scrum is a way of chunking development into well-defined portions.
The idea of using Scrum to estimate time just doesn't make sense.
Everything in Scrum takes the same amount of time.
Two weeks.
(Or one week, or whatever your sprint length is.
) The difference is that long projects are implemented over multiple sprints, since obviously, not everything can be done in two weeks.
So the estimate is not of how long it will take, but how many backlog items will be required in order to reach some known endpoint.
Once the backlogs have been created and agreed upon by the team, estimating the necessary time becomes a matter of multiplication: 12 backlogs * 2 weeks = 24 weeks to finish this product.This makes you shift your thinking from "how long will it take to do all these things" to "how can I break this product development into chunks which each fit into a two-week period?
" That's much easier than making wild-ass guesses about the time it takes to do something.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</id>
	<title>Simply, no software required.</title>
	<author>loftwyr</author>
	<datestamp>1265742780000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>I take the amount of time I think it will take, double it and move it up a time unit.</p><p>So, if I think it will take two days, I estimate 4 weeks.  If I think it will take a week, I estimate two months and so on.</p></htmltext>
<tokenext>I take the amount of time I think it will take , double it and move it up a time unit.So , if I think it will take two days , I estimate 4 weeks .
If I think it will take a week , I estimate two months and so on .</tokentext>
<sentencetext>I take the amount of time I think it will take, double it and move it up a time unit.So, if I think it will take two days, I estimate 4 weeks.
If I think it will take a week, I estimate two months and so on.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31094240</id>
	<title>90\% accuracy:</title>
	<author>Anonymous</author>
	<datestamp>1265035500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>1. Ask all the programmers and customers SEPARATELY how long they estimate.<br>2. Take the HIGHEST estimate<br>3. Multiply by 2.2</p><p>Over 50 projects I was never out by more than 8\%...</p><p>Dunno why it works.</p></htmltext>
<tokenext>1 .
Ask all the programmers and customers SEPARATELY how long they estimate.2 .
Take the HIGHEST estimate3 .
Multiply by 2.2Over 50 projects I was never out by more than 8 \ % ...Dunno why it works .</tokentext>
<sentencetext>1.
Ask all the programmers and customers SEPARATELY how long they estimate.2.
Take the HIGHEST estimate3.
Multiply by 2.2Over 50 projects I was never out by more than 8\%...Dunno why it works.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075344</id>
	<title>Fixed Price or Cost +?</title>
	<author>Anonymous</author>
	<datestamp>1265743560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>For fixed price, WAG*3<br>For Cost+, WAG*2</p></htmltext>
<tokenext>For fixed price , WAG * 3For Cost + , WAG * 2</tokentext>
<sentencetext>For fixed price, WAG*3For Cost+, WAG*2</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080172</id>
	<title>Re:Chop features.</title>
	<author>Anonymous</author>
	<datestamp>1265720280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Make sure to read Orson Scott Card's <a href="http://www.netjeff.com/humor/item.cgi?file=DeveloperBees" title="netjeff.com">How Software Companies Die</a> [netjeff.com] (commonly known as "Programmers and Bees").  This sort of over-refinement of estimation is not only pointless (in that it presumes far greater association between the past and the future than is likely to exist), it's destructive to the goal of making good software in a reasonable time-frame (if that is still the goal).</p><p>Some element of the planning and development process has to bake down to trust and awareness.  If a dev says that something will take an unreasonable amount of time, a good project manager should be able to smell the BS and, more importantly, recognize that the dev might be sand-bagging a feature he/she hates.  That dev might, in turn, <b> <i>actually</i> </b> take that long to do it.  If you have cultural and motivational problems, no amount of process refinement is going to help.  It's just going to drive the competent developers away and leave you with a slow death-spiral of longer estimates and crappier software.</p><p>High, low, medium risk?  When I hear people baking things into categories, that's fine.  When I see them plan schedules <b>from</b> the information reduced into categories (instead of cycling back and asking devs), the bozo-bit gets flipped.  <a href="http://portal.acm.org/citation.cfm?id=1165556" title="acm.org">Aggregability is NP-hard</a> [acm.org], and it's important to remember that you're not going to be able to bake something as complex as software down into a weekend management seminar.  If I could give one piece of advice to managers and devs looking to get better estimates, I'd say: <i>"Go with your gut.  As you get better at it, and your team gets better at working together, your intuitive estimates will get an order-of-magnitude better than the estimates that would have been derived from an over-simplified system.  If you try to commoditize software, you get whatever the market will bear."</i></p></htmltext>
<tokenext>Make sure to read Orson Scott Card 's How Software Companies Die [ netjeff.com ] ( commonly known as " Programmers and Bees " ) .
This sort of over-refinement of estimation is not only pointless ( in that it presumes far greater association between the past and the future than is likely to exist ) , it 's destructive to the goal of making good software in a reasonable time-frame ( if that is still the goal ) .Some element of the planning and development process has to bake down to trust and awareness .
If a dev says that something will take an unreasonable amount of time , a good project manager should be able to smell the BS and , more importantly , recognize that the dev might be sand-bagging a feature he/she hates .
That dev might , in turn , actually take that long to do it .
If you have cultural and motivational problems , no amount of process refinement is going to help .
It 's just going to drive the competent developers away and leave you with a slow death-spiral of longer estimates and crappier software.High , low , medium risk ?
When I hear people baking things into categories , that 's fine .
When I see them plan schedules from the information reduced into categories ( instead of cycling back and asking devs ) , the bozo-bit gets flipped .
Aggregability is NP-hard [ acm.org ] , and it 's important to remember that you 're not going to be able to bake something as complex as software down into a weekend management seminar .
If I could give one piece of advice to managers and devs looking to get better estimates , I 'd say : " Go with your gut .
As you get better at it , and your team gets better at working together , your intuitive estimates will get an order-of-magnitude better than the estimates that would have been derived from an over-simplified system .
If you try to commoditize software , you get whatever the market will bear .
"</tokentext>
<sentencetext>Make sure to read Orson Scott Card's How Software Companies Die [netjeff.com] (commonly known as "Programmers and Bees").
This sort of over-refinement of estimation is not only pointless (in that it presumes far greater association between the past and the future than is likely to exist), it's destructive to the goal of making good software in a reasonable time-frame (if that is still the goal).Some element of the planning and development process has to bake down to trust and awareness.
If a dev says that something will take an unreasonable amount of time, a good project manager should be able to smell the BS and, more importantly, recognize that the dev might be sand-bagging a feature he/she hates.
That dev might, in turn,  actually  take that long to do it.
If you have cultural and motivational problems, no amount of process refinement is going to help.
It's just going to drive the competent developers away and leave you with a slow death-spiral of longer estimates and crappier software.High, low, medium risk?
When I hear people baking things into categories, that's fine.
When I see them plan schedules from the information reduced into categories (instead of cycling back and asking devs), the bozo-bit gets flipped.
Aggregability is NP-hard [acm.org], and it's important to remember that you're not going to be able to bake something as complex as software down into a weekend management seminar.
If I could give one piece of advice to managers and devs looking to get better estimates, I'd say: "Go with your gut.
As you get better at it, and your team gets better at working together, your intuitive estimates will get an order-of-magnitude better than the estimates that would have been derived from an over-simplified system.
If you try to commoditize software, you get whatever the market will bear.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076818</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076310</id>
	<title>Re:Uhh, Scrum is not an estimation method</title>
	<author>MobyDisk</author>
	<datestamp>1265746740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Do you realize that you just explained why scrum is a great estimation method?  I'm gonna have to try that!</p></htmltext>
<tokenext>Do you realize that you just explained why scrum is a great estimation method ?
I 'm gon na have to try that !</tokentext>
<sentencetext>Do you realize that you just explained why scrum is a great estimation method?
I'm gonna have to try that!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081026</id>
	<title>This is the Wrong Question !</title>
	<author>presidenteloco</author>
	<datestamp>1265726100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What you should do is ask questions like:</p><p>Do I have really intelligent people who are also able and likely to work hard<br>when they are motivated well to build something new and interesting.</p><p>Do my team members take pride in producing excellent and elegant<br>code? (which includes really good, coherent, useful doc &amp; comments).</p><p>Do my team members know how to model domains?</p><p>Are my team members fully versed in patterns and re-use and 3rd party<br>software selection factors.</p><p>Do my team members understand that it is essential to look out for red-flag technical<br>risks, draw immediate attention to them, and actively manage the course of the project<br>based on the principle of addressing them first.</p><p>Are they also all good and smart social interactors? Do they know what<br>others need to know. Are they friendly, co-operative, good-humoured, and<br>willing to help each other.</p><p>Have I done what it takes to positively motivate this great team?</p><p>Is the project new and worthwhile and interesting, and do the developers think<br>so?</p><p>Have I created an environment where it is safe to spend your time helping<br>others on the team?</p><p>Have I given the people private environments where they can think and design<br>or code for long periods of time uninterrupted?</p><p>If you've done all these things, then let them go, and occasionally check in.</p><p>You will get software produced as well, and as fast, as you could possibly<br>hope for. So don't micro manage their work or schedule. Just continually<br>reassess the questions above, and how well you are continuing to do at<br>creating an environment for software development success.</p><p>You cannot hope to do better than that. If setting up those conditions won't<br>do it for you, nothing will and you had very unrealistic expectations.</p></htmltext>
<tokenext>What you should do is ask questions like : Do I have really intelligent people who are also able and likely to work hardwhen they are motivated well to build something new and interesting.Do my team members take pride in producing excellent and elegantcode ?
( which includes really good , coherent , useful doc &amp; comments ) .Do my team members know how to model domains ? Are my team members fully versed in patterns and re-use and 3rd partysoftware selection factors.Do my team members understand that it is essential to look out for red-flag technicalrisks , draw immediate attention to them , and actively manage the course of the projectbased on the principle of addressing them first.Are they also all good and smart social interactors ?
Do they know whatothers need to know .
Are they friendly , co-operative , good-humoured , andwilling to help each other.Have I done what it takes to positively motivate this great team ? Is the project new and worthwhile and interesting , and do the developers thinkso ? Have I created an environment where it is safe to spend your time helpingothers on the team ? Have I given the people private environments where they can think and designor code for long periods of time uninterrupted ? If you 've done all these things , then let them go , and occasionally check in.You will get software produced as well , and as fast , as you could possiblyhope for .
So do n't micro manage their work or schedule .
Just continuallyreassess the questions above , and how well you are continuing to do atcreating an environment for software development success.You can not hope to do better than that .
If setting up those conditions won'tdo it for you , nothing will and you had very unrealistic expectations .</tokentext>
<sentencetext>What you should do is ask questions like:Do I have really intelligent people who are also able and likely to work hardwhen they are motivated well to build something new and interesting.Do my team members take pride in producing excellent and elegantcode?
(which includes really good, coherent, useful doc &amp; comments).Do my team members know how to model domains?Are my team members fully versed in patterns and re-use and 3rd partysoftware selection factors.Do my team members understand that it is essential to look out for red-flag technicalrisks, draw immediate attention to them, and actively manage the course of the projectbased on the principle of addressing them first.Are they also all good and smart social interactors?
Do they know whatothers need to know.
Are they friendly, co-operative, good-humoured, andwilling to help each other.Have I done what it takes to positively motivate this great team?Is the project new and worthwhile and interesting, and do the developers thinkso?Have I created an environment where it is safe to spend your time helpingothers on the team?Have I given the people private environments where they can think and designor code for long periods of time uninterrupted?If you've done all these things, then let them go, and occasionally check in.You will get software produced as well, and as fast, as you could possiblyhope for.
So don't micro manage their work or schedule.
Just continuallyreassess the questions above, and how well you are continuing to do atcreating an environment for software development success.You cannot hope to do better than that.
If setting up those conditions won'tdo it for you, nothing will and you had very unrealistic expectations.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075368</id>
	<title>Estimate, Get Feedback, Repeat...</title>
	<author>fortapocalypse</author>
	<datestamp>1265743620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It is just like anything else. You practice, you get feedback, and you keep trying. That method should apply to getting better at both high-level and task-level estimation for any task (not just development). The methods that help you produce better estimates will develop based on experience and feedback. Historical reporting and adequate (but quick) data collection are key. While there are tools out there to help you determine where people are spending time, nothing substitutes for people estimating their work or the work of their team. Unfortunately, estimation is not valued in all environments, and can turn some developers off.</htmltext>
<tokenext>It is just like anything else .
You practice , you get feedback , and you keep trying .
That method should apply to getting better at both high-level and task-level estimation for any task ( not just development ) .
The methods that help you produce better estimates will develop based on experience and feedback .
Historical reporting and adequate ( but quick ) data collection are key .
While there are tools out there to help you determine where people are spending time , nothing substitutes for people estimating their work or the work of their team .
Unfortunately , estimation is not valued in all environments , and can turn some developers off .</tokentext>
<sentencetext>It is just like anything else.
You practice, you get feedback, and you keep trying.
That method should apply to getting better at both high-level and task-level estimation for any task (not just development).
The methods that help you produce better estimates will develop based on experience and feedback.
Historical reporting and adequate (but quick) data collection are key.
While there are tools out there to help you determine where people are spending time, nothing substitutes for people estimating their work or the work of their team.
Unfortunately, estimation is not valued in all environments, and can turn some developers off.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170</id>
	<title>W.A.G.</title>
	<author>ipb</author>
	<datestamp>1265743020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>After 40+ years of programming it's still a Wild Assed Guess.</p><p>You're never given enough time to prepare your estimate, marketing has already<br>determined the delivery date, and management doesn't know what it is you're<br>supposed to create anyway.,</p></htmltext>
<tokenext>After 40 + years of programming it 's still a Wild Assed Guess.You 're never given enough time to prepare your estimate , marketing has alreadydetermined the delivery date , and management does n't know what it is you'resupposed to create anyway.,</tokentext>
<sentencetext>After 40+ years of programming it's still a Wild Assed Guess.You're never given enough time to prepare your estimate, marketing has alreadydetermined the delivery date, and management doesn't know what it is you'resupposed to create anyway.,</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076650</id>
	<title>Re:W.A.G.</title>
	<author>Anonymous</author>
	<datestamp>1265748180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This has a chance of actually working as long as these factors stay constant:</p><p>1. Team members are the same.</p><p>2. Project's technical hurdles are the same exact hurdles as the ones encountered in all the previous projects.</p><p>3. The project has no creative (unrepetitive/unique) hurdles.</p><p>4. The company has not been doing something lately that affects the morale, such as decimating the workforce (laying off every tenth member).</p><p>And so on.  In other words, this strategy is probably not very accurate for most real world environments.</p></htmltext>
<tokenext>This has a chance of actually working as long as these factors stay constant : 1 .
Team members are the same.2 .
Project 's technical hurdles are the same exact hurdles as the ones encountered in all the previous projects.3 .
The project has no creative ( unrepetitive/unique ) hurdles.4 .
The company has not been doing something lately that affects the morale , such as decimating the workforce ( laying off every tenth member ) .And so on .
In other words , this strategy is probably not very accurate for most real world environments .</tokentext>
<sentencetext>This has a chance of actually working as long as these factors stay constant:1.
Team members are the same.2.
Project's technical hurdles are the same exact hurdles as the ones encountered in all the previous projects.3.
The project has no creative (unrepetitive/unique) hurdles.4.
The company has not been doing something lately that affects the morale, such as decimating the workforce (laying off every tenth member).And so on.
In other words, this strategy is probably not very accurate for most real world environments.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082192</id>
	<title>That depends</title>
	<author>tompaulco</author>
	<datestamp>1265738340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>How long it will take depends on whether I am allowed to work on it. I used to be in operations, which meant I fought fires 12 hours a day. Now I am a full time developer, which means I fight fires 12 hours a day, and then spend the rest of my day writing programs. Unfortunately, I am usually too tired from fighting fires to actually do any programming. So if they ask me how long it would take to do something, I tell them "It would take  if I am allowed to work on it, however, since I will not be allowed to work on it, it will never get done."<br>
My company also uses a new development approach that I have seen at the last two or three companies that I have worked at, but never seen before in my professional career. That is, instead of having multiple people work on a single project, they have a single person work on multiple projects. We have 7 developers and about 10 times that many active projects. On any given day, the Project Manager for two to three of those projects will be demanding that his project get top priority.</htmltext>
<tokenext>How long it will take depends on whether I am allowed to work on it .
I used to be in operations , which meant I fought fires 12 hours a day .
Now I am a full time developer , which means I fight fires 12 hours a day , and then spend the rest of my day writing programs .
Unfortunately , I am usually too tired from fighting fires to actually do any programming .
So if they ask me how long it would take to do something , I tell them " It would take if I am allowed to work on it , however , since I will not be allowed to work on it , it will never get done .
" My company also uses a new development approach that I have seen at the last two or three companies that I have worked at , but never seen before in my professional career .
That is , instead of having multiple people work on a single project , they have a single person work on multiple projects .
We have 7 developers and about 10 times that many active projects .
On any given day , the Project Manager for two to three of those projects will be demanding that his project get top priority .</tokentext>
<sentencetext>How long it will take depends on whether I am allowed to work on it.
I used to be in operations, which meant I fought fires 12 hours a day.
Now I am a full time developer, which means I fight fires 12 hours a day, and then spend the rest of my day writing programs.
Unfortunately, I am usually too tired from fighting fires to actually do any programming.
So if they ask me how long it would take to do something, I tell them "It would take  if I am allowed to work on it, however, since I will not be allowed to work on it, it will never get done.
"
My company also uses a new development approach that I have seen at the last two or three companies that I have worked at, but never seen before in my professional career.
That is, instead of having multiple people work on a single project, they have a single person work on multiple projects.
We have 7 developers and about 10 times that many active projects.
On any given day, the Project Manager for two to three of those projects will be demanding that his project get top priority.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075204</id>
	<title>The George Carlin Principle...</title>
	<author>TheDarkMinstrel</author>
	<datestamp>1265743140000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>Show me a staff that consistently delivers products on time and one of the following will always be true:<br> <br>
1) One or more of your highest performers works extensive amounts of overtime (and is likely to burnout)<br>
2) Project times are consistently overestimated.
<br> <br>
It's a variation of the George Carlin Principle... People will adapt to fill the space, one way or the other.</htmltext>
<tokenext>Show me a staff that consistently delivers products on time and one of the following will always be true : 1 ) One or more of your highest performers works extensive amounts of overtime ( and is likely to burnout ) 2 ) Project times are consistently overestimated .
It 's a variation of the George Carlin Principle... People will adapt to fill the space , one way or the other .</tokentext>
<sentencetext>Show me a staff that consistently delivers products on time and one of the following will always be true: 
1) One or more of your highest performers works extensive amounts of overtime (and is likely to burnout)
2) Project times are consistently overestimated.
It's a variation of the George Carlin Principle... People will adapt to fill the space, one way or the other.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075974</id>
	<title>It depends on why you are estimating</title>
	<author>ThinkTiM</author>
	<datestamp>1265745660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you're trying to estimate the size of project for budgeting purposes, then function-point counting is a useful method.  Over time you can learn how an organization performs and your estimates will become more accurate.

If you're trying to estimate for the purposes of visibility then don't&mdash;you're better of using one of the agile development methodologies.</htmltext>
<tokenext>If you 're trying to estimate the size of project for budgeting purposes , then function-point counting is a useful method .
Over time you can learn how an organization performs and your estimates will become more accurate .
If you 're trying to estimate for the purposes of visibility then do n't    you 're better of using one of the agile development methodologies .</tokentext>
<sentencetext>If you're trying to estimate the size of project for budgeting purposes, then function-point counting is a useful method.
Over time you can learn how an organization performs and your estimates will become more accurate.
If you're trying to estimate for the purposes of visibility then don't—you're better of using one of the agile development methodologies.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082256</id>
	<title>Re:Chop features.</title>
	<author>Ihmhi</author>
	<datestamp>1265739300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A buddy of mine is in a private contractor. He figures out the materials and time needed for a project and then adds 30\% to both. He has yet to go once over budget or past deadline, and he rarely comes sailing in way under budget or deadline either. It's a good rule of thumb.</p></htmltext>
<tokenext>A buddy of mine is in a private contractor .
He figures out the materials and time needed for a project and then adds 30 \ % to both .
He has yet to go once over budget or past deadline , and he rarely comes sailing in way under budget or deadline either .
It 's a good rule of thumb .</tokentext>
<sentencetext>A buddy of mine is in a private contractor.
He figures out the materials and time needed for a project and then adds 30\% to both.
He has yet to go once over budget or past deadline, and he rarely comes sailing in way under budget or deadline either.
It's a good rule of thumb.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078106</id>
	<title>Re:A better formula</title>
	<author>Anonymous</author>
	<datestamp>1265710860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Or, if you'd rather not get fired, add a day instead.</p></htmltext>
<tokenext>Or , if you 'd rather not get fired , add a day instead .</tokentext>
<sentencetext>Or, if you'd rather not get fired, add a day instead.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075880</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078072</id>
	<title>Re:Chop features.</title>
	<author>tempest69</author>
	<datestamp>1265710680000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p>Exactly. Ship date is a feature. It will have lower priority than some features, and higher priority than some other features.
I've never seen a team that could estimate, months in advance, when a particular feature set would ship.
I've been part of great teams that regularly review progress and have the power to adjust priorities.</p></div>
</blockquote><p>
Shipdate was the feature dropped in Duke Nukem Forever..  So it ships with all features..</p></div>
	</htmltext>
<tokenext>Exactly .
Ship date is a feature .
It will have lower priority than some features , and higher priority than some other features .
I 've never seen a team that could estimate , months in advance , when a particular feature set would ship .
I 've been part of great teams that regularly review progress and have the power to adjust priorities .
Shipdate was the feature dropped in Duke Nukem Forever.. So it ships with all features. .</tokentext>
<sentencetext>Exactly.
Ship date is a feature.
It will have lower priority than some features, and higher priority than some other features.
I've never seen a team that could estimate, months in advance, when a particular feature set would ship.
I've been part of great teams that regularly review progress and have the power to adjust priorities.
Shipdate was the feature dropped in Duke Nukem Forever..  So it ships with all features..
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075916</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077902</id>
	<title>Re:Simply, no software required.</title>
	<author>Hognoxious</author>
	<datestamp>1265710020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>the first 90\% of the project takes the first 90\% of the time line, and the remaining 10\% of the project takes the other 90\% of time.</p></div></blockquote><p>And the 50\% that didn't get done is either teething troubles, maintenance issues or a new project.</p></div>
	</htmltext>
<tokenext>the first 90 \ % of the project takes the first 90 \ % of the time line , and the remaining 10 \ % of the project takes the other 90 \ % of time.And the 50 \ % that did n't get done is either teething troubles , maintenance issues or a new project .</tokentext>
<sentencetext>the first 90\% of the project takes the first 90\% of the time line, and the remaining 10\% of the project takes the other 90\% of time.And the 50\% that didn't get done is either teething troubles, maintenance issues or a new project.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076428</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077328</id>
	<title>How ironic...</title>
	<author>Pawnn</author>
	<datestamp>1265707680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I just had to give an estimate the other day.  Not for programming, but for designing a program for others to write.

As asinine as it is to estimate programming time, I think estimating a design might be worse.

What I did was looked at the requirements and tried to figure out what the different pieces of the system were, then gave each one 3 weeks.  That came out to about 10 months...which seemed kinda big to me, but how many people are guilty of over-estimating?

As expected, the project manager thought that sounded high, so she found someone who she thought had more experience and asked him to help me make a more detailed estimate.  Over the course of a week, we spent probably 5 to 10 hours pouring over the details of the project, breaking it down further and giving an estimate to each little detail.  I let the "expert" give estimates to each piece.  It came out to two years!  (If I gave each of the new tasks 1 day a piece, it'd come out to 7 months)

Needless to say, the project manager didn't like that either and wants me to revise it to make it smaller.  I should just say "write down what you're going to say anyway and I'll make a plan around that", but I haven't.</htmltext>
<tokenext>I just had to give an estimate the other day .
Not for programming , but for designing a program for others to write .
As asinine as it is to estimate programming time , I think estimating a design might be worse .
What I did was looked at the requirements and tried to figure out what the different pieces of the system were , then gave each one 3 weeks .
That came out to about 10 months...which seemed kinda big to me , but how many people are guilty of over-estimating ?
As expected , the project manager thought that sounded high , so she found someone who she thought had more experience and asked him to help me make a more detailed estimate .
Over the course of a week , we spent probably 5 to 10 hours pouring over the details of the project , breaking it down further and giving an estimate to each little detail .
I let the " expert " give estimates to each piece .
It came out to two years !
( If I gave each of the new tasks 1 day a piece , it 'd come out to 7 months ) Needless to say , the project manager did n't like that either and wants me to revise it to make it smaller .
I should just say " write down what you 're going to say anyway and I 'll make a plan around that " , but I have n't .</tokentext>
<sentencetext>I just had to give an estimate the other day.
Not for programming, but for designing a program for others to write.
As asinine as it is to estimate programming time, I think estimating a design might be worse.
What I did was looked at the requirements and tried to figure out what the different pieces of the system were, then gave each one 3 weeks.
That came out to about 10 months...which seemed kinda big to me, but how many people are guilty of over-estimating?
As expected, the project manager thought that sounded high, so she found someone who she thought had more experience and asked him to help me make a more detailed estimate.
Over the course of a week, we spent probably 5 to 10 hours pouring over the details of the project, breaking it down further and giving an estimate to each little detail.
I let the "expert" give estimates to each piece.
It came out to two years!
(If I gave each of the new tasks 1 day a piece, it'd come out to 7 months)

Needless to say, the project manager didn't like that either and wants me to revise it to make it smaller.
I should just say "write down what you're going to say anyway and I'll make a plan around that", but I haven't.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079402</id>
	<title>The 80\% rule</title>
	<author>NicknamesAreStupid</author>
	<datestamp>1265716020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I have a rule that has served me well -- whatever I seriously estimate for a project's duration, the first half will take 80\% of that time.  Then half of the remaining project will take another 80\%.  After that, half of the remaining project will take another 80\%.  This regression continues into perpetuity.  Eventually, it is decided to declare the project complete and live with what got done.  Therefore, I have always planned a product to only encompass that which could be done in the "first half" of the project.  If that was not enough for the product, then it was not feasible.
<br> <br>
Another rule of thumb for tech products, if the project slips more than 50\% beyond its targeted release date, then break up the team.  The team that slips this much will never keep up with the market.</htmltext>
<tokenext>I have a rule that has served me well -- whatever I seriously estimate for a project 's duration , the first half will take 80 \ % of that time .
Then half of the remaining project will take another 80 \ % .
After that , half of the remaining project will take another 80 \ % .
This regression continues into perpetuity .
Eventually , it is decided to declare the project complete and live with what got done .
Therefore , I have always planned a product to only encompass that which could be done in the " first half " of the project .
If that was not enough for the product , then it was not feasible .
Another rule of thumb for tech products , if the project slips more than 50 \ % beyond its targeted release date , then break up the team .
The team that slips this much will never keep up with the market .</tokentext>
<sentencetext>I have a rule that has served me well -- whatever I seriously estimate for a project's duration, the first half will take 80\% of that time.
Then half of the remaining project will take another 80\%.
After that, half of the remaining project will take another 80\%.
This regression continues into perpetuity.
Eventually, it is decided to declare the project complete and live with what got done.
Therefore, I have always planned a product to only encompass that which could be done in the "first half" of the project.
If that was not enough for the product, then it was not feasible.
Another rule of thumb for tech products, if the project slips more than 50\% beyond its targeted release date, then break up the team.
The team that slips this much will never keep up with the market.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076592</id>
	<title>Here At A Land Grant University</title>
	<author>Anonymous</author>
	<datestamp>1265747940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I take the boss' estimate and multiply it by 5.</p><p>If it's my estimate, I'll multiply by 3 because I'm more in touch with the world.</p><p>Yours In New Orleans,<br><a href="http://www.youtube.com/watch?v=qvSBby38R5o" title="youtube.com" rel="nofollow">Kilgore  Trout</a> [youtube.com]</p></htmltext>
<tokenext>I take the boss ' estimate and multiply it by 5.If it 's my estimate , I 'll multiply by 3 because I 'm more in touch with the world.Yours In New Orleans,Kilgore Trout [ youtube.com ]</tokentext>
<sentencetext>I take the boss' estimate and multiply it by 5.If it's my estimate, I'll multiply by 3 because I'm more in touch with the world.Yours In New Orleans,Kilgore  Trout [youtube.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31104744</id>
	<title>Estimate based on historic data.</title>
	<author>xplinuxmac</author>
	<datestamp>1265882280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A good (experienced) programmer should eventually have a good 'feel' for how much time certain tasks take (but having domain knowledge does help too), and the scrum planning poker is a way to get to such an estimate, but it is of course not perfect. Very important is a proper brake down of the tasks (not forgetting any tasks). Many developers under estimate the time it takes to write some code and provide proper unit tests for the test team, this results sometimes in going to the other extreme and estimating too much time. Another approach is to look at historical data of your developers. This guy wrote a case study that uses historical data of his developers to estimate future tasks : <a href="http://vanlingen.name/web/cv/unpublished/article/2010/02metrics/metrics.pdf" title="vanlingen.name" rel="nofollow">http://vanlingen.name/web/cv/unpublished/article/2010/02metrics/metrics.pdf</a> [vanlingen.name]  It is an interesting approach, but I would not only rely on that. A combination of techniques: historical data, estimation by developers, good task breakdown (not forgetting tasks), I think is needed for estimating the time it takes to complete a project.</htmltext>
<tokenext>A good ( experienced ) programmer should eventually have a good 'feel ' for how much time certain tasks take ( but having domain knowledge does help too ) , and the scrum planning poker is a way to get to such an estimate , but it is of course not perfect .
Very important is a proper brake down of the tasks ( not forgetting any tasks ) .
Many developers under estimate the time it takes to write some code and provide proper unit tests for the test team , this results sometimes in going to the other extreme and estimating too much time .
Another approach is to look at historical data of your developers .
This guy wrote a case study that uses historical data of his developers to estimate future tasks : http : //vanlingen.name/web/cv/unpublished/article/2010/02metrics/metrics.pdf [ vanlingen.name ] It is an interesting approach , but I would not only rely on that .
A combination of techniques : historical data , estimation by developers , good task breakdown ( not forgetting tasks ) , I think is needed for estimating the time it takes to complete a project .</tokentext>
<sentencetext>A good (experienced) programmer should eventually have a good 'feel' for how much time certain tasks take (but having domain knowledge does help too), and the scrum planning poker is a way to get to such an estimate, but it is of course not perfect.
Very important is a proper brake down of the tasks (not forgetting any tasks).
Many developers under estimate the time it takes to write some code and provide proper unit tests for the test team, this results sometimes in going to the other extreme and estimating too much time.
Another approach is to look at historical data of your developers.
This guy wrote a case study that uses historical data of his developers to estimate future tasks : http://vanlingen.name/web/cv/unpublished/article/2010/02metrics/metrics.pdf [vanlingen.name]  It is an interesting approach, but I would not only rely on that.
A combination of techniques: historical data, estimation by developers, good task breakdown (not forgetting tasks), I think is needed for estimating the time it takes to complete a project.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077926</id>
	<title>Re:Uhh, Scrum is not an estimation method</title>
	<author>Snyper1000</author>
	<datestamp>1265710200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>wait, I thought part of the sprint creation was team estimates of "points", 1, 2, 4, 8, 64, and 128.  After developing for a while you get a velocity.  Then you can take that velocity, see how many points per sprint get done, and accuratly estimate time.  Trouble is, sometimes velocity changes, specs change, 64 and 128 time estimates need to be broken down b/c they are unmanageable and not really estimatable.  I likes the scrum projects we worked, so did our customers, and managers (well, the ones who could get over the waterfall method that is)</htmltext>
<tokenext>wait , I thought part of the sprint creation was team estimates of " points " , 1 , 2 , 4 , 8 , 64 , and 128 .
After developing for a while you get a velocity .
Then you can take that velocity , see how many points per sprint get done , and accuratly estimate time .
Trouble is , sometimes velocity changes , specs change , 64 and 128 time estimates need to be broken down b/c they are unmanageable and not really estimatable .
I likes the scrum projects we worked , so did our customers , and managers ( well , the ones who could get over the waterfall method that is )</tokentext>
<sentencetext>wait, I thought part of the sprint creation was team estimates of "points", 1, 2, 4, 8, 64, and 128.
After developing for a while you get a velocity.
Then you can take that velocity, see how many points per sprint get done, and accuratly estimate time.
Trouble is, sometimes velocity changes, specs change, 64 and 128 time estimates need to be broken down b/c they are unmanageable and not really estimatable.
I likes the scrum projects we worked, so did our customers, and managers (well, the ones who could get over the waterfall method that is)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31092182</id>
	<title>Like they listen to YOU?</title>
	<author>Anonymous</author>
	<datestamp>1265024640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It doesn't matter what you say.  They will increase the feature set and move up the deadline anyway.  Usually its best to find out what they want to hear and just tell them something close to that, because that is all they will hear anyway.</p></htmltext>
<tokenext>It does n't matter what you say .
They will increase the feature set and move up the deadline anyway .
Usually its best to find out what they want to hear and just tell them something close to that , because that is all they will hear anyway .</tokentext>
<sentencetext>It doesn't matter what you say.
They will increase the feature set and move up the deadline anyway.
Usually its best to find out what they want to hear and just tell them something close to that, because that is all they will hear anyway.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080320</id>
	<title>smallest known unit</title>
	<author>roman\_mir</author>
	<datestamp>1265721240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I have to do many estimates, and mine are within 10\% error of actual time, then I add 30\% on top of that, done.</p><p>Today a funny thing happened, I had to switch one implementation of web service call for a totally different one.  At 1:16 I said I would be done in half an hour, after changing the build script, build properties, creating the client and switching the implementation in business logic, I sent the message that it was done.  Then I looked at the clock, it was 1:46.  So I told the other side, that instead of half an hour it took me 30 minutes.</p><p>Seriously though, take the task and divide it into smallest chunks that you know can be estimated, this would be close to reality, so add 30\%.  I can't add more than that, our competitors would get the project then.  This method only works for projects that are similar to each other though.</p></htmltext>
<tokenext>I have to do many estimates , and mine are within 10 \ % error of actual time , then I add 30 \ % on top of that , done.Today a funny thing happened , I had to switch one implementation of web service call for a totally different one .
At 1 : 16 I said I would be done in half an hour , after changing the build script , build properties , creating the client and switching the implementation in business logic , I sent the message that it was done .
Then I looked at the clock , it was 1 : 46 .
So I told the other side , that instead of half an hour it took me 30 minutes.Seriously though , take the task and divide it into smallest chunks that you know can be estimated , this would be close to reality , so add 30 \ % .
I ca n't add more than that , our competitors would get the project then .
This method only works for projects that are similar to each other though .</tokentext>
<sentencetext>I have to do many estimates, and mine are within 10\% error of actual time, then I add 30\% on top of that, done.Today a funny thing happened, I had to switch one implementation of web service call for a totally different one.
At 1:16 I said I would be done in half an hour, after changing the build script, build properties, creating the client and switching the implementation in business logic, I sent the message that it was done.
Then I looked at the clock, it was 1:46.
So I told the other side, that instead of half an hour it took me 30 minutes.Seriously though, take the task and divide it into smallest chunks that you know can be estimated, this would be close to reality, so add 30\%.
I can't add more than that, our competitors would get the project then.
This method only works for projects that are similar to each other though.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075880</id>
	<title>A better formula</title>
	<author>Anonymous</author>
	<datestamp>1265745360000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext>Find out how much time you can spend on the project before you'd get fired for laziness, then subtract a day.</htmltext>
<tokenext>Find out how much time you can spend on the project before you 'd get fired for laziness , then subtract a day .</tokentext>
<sentencetext>Find out how much time you can spend on the project before you'd get fired for laziness, then subtract a day.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075068</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077178</id>
	<title>Apply this formula</title>
	<author>kimvette</author>
	<datestamp>1265706960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Hold scrum meetings, and then ask each developer and tester individually how long each step will take. Take their wild assed guess, compare it to what estimates you come up with in scrum meetings, and average those. Multiply that estimate by 2.25 to take into account vacations, side projects, meetings (which for some positions can consume 60\% of your time, and you NEVER take those things into account when giving the project manager your estimate). Allow for some buffer time for bug fixes, fighting with Microsoft about hotfixes for libraries in which you find critical bugs when you're at the final beta stages, and also allow for some buffer time for having to issue emergency bug fixes on your released branch.</p><p>Estimates you come up with in scrum meetings and individuals' wild-assed guesses never take any of the unknowns into account. The engineers with no management experience invariably think "well, I work 40 hours a week, and I think this module will take me 120 hours, then another 120 to integrate into the project - so yeah. I can be done with my first phase in six weeks." That does not take into account sick days, dependencies (waiting on other developers for the components you need from them), time for getting sucked into meetings, time to rearchitect your piece when you find Microsoft's library doesn't actually worked as documented (or Microsoft's memory manager incurs eighteen gadzillion context switches per minute, slowing your process to a screeching halt under a moderate load) requiring you to invent your own or evaluate third-party libraries.</p><p>Always provide buffers to allow for bureaucracy/politics (read: meetings you are required to attend but you think are a complete waste of your time), unknowns (You don't know what you don't know so be generous here), and so forth. If you provide generous padding for these inevitable realities of corporate life, you can create a schedule which will allow you to come in on time and under-budget. If your project manager does not allow you to pad your estimate with unknowns, meetings, etc. but requires you to give an estimate based on 40 actual coding hours per week, you're getting set up for failure. That means no bonuses, poor performance review, and generally bad morale because your team will be "late" on a project based on a half-assed schedule based on fiction.</p><p>Even worse is when management says "Here is your next project: feature set is X, you have Y resources, and by the way, the due date is Z."   Those are the absolute worst conditions to work under in development because management a) doesn't even know what out of X is possible, whether Y resources can actually accomplish it, and if even 1/3 of it can be accomplished within Z time based even on an ideal 40 hour workweek dedicated to writing code and doing nothing else.</p><p>By the way: do not base it on 40 hours of coding at ALL to begin with. You will spend 1-2 hours on emails, and a <i>lot</i> of time just engineering (actually just thinking the problem through) not to mention reviewing API calls you use and that time will easily match the time you spent coding. Plan on <i>maybe</i> 20-25 measurable "productive"[sic]* hours per week.</p><p>* "productive" meaning what a PHB considers productive, i.e., lines of code written, dialogs flashing on the screen, etc.</p></htmltext>
<tokenext>Hold scrum meetings , and then ask each developer and tester individually how long each step will take .
Take their wild assed guess , compare it to what estimates you come up with in scrum meetings , and average those .
Multiply that estimate by 2.25 to take into account vacations , side projects , meetings ( which for some positions can consume 60 \ % of your time , and you NEVER take those things into account when giving the project manager your estimate ) .
Allow for some buffer time for bug fixes , fighting with Microsoft about hotfixes for libraries in which you find critical bugs when you 're at the final beta stages , and also allow for some buffer time for having to issue emergency bug fixes on your released branch.Estimates you come up with in scrum meetings and individuals ' wild-assed guesses never take any of the unknowns into account .
The engineers with no management experience invariably think " well , I work 40 hours a week , and I think this module will take me 120 hours , then another 120 to integrate into the project - so yeah .
I can be done with my first phase in six weeks .
" That does not take into account sick days , dependencies ( waiting on other developers for the components you need from them ) , time for getting sucked into meetings , time to rearchitect your piece when you find Microsoft 's library does n't actually worked as documented ( or Microsoft 's memory manager incurs eighteen gadzillion context switches per minute , slowing your process to a screeching halt under a moderate load ) requiring you to invent your own or evaluate third-party libraries.Always provide buffers to allow for bureaucracy/politics ( read : meetings you are required to attend but you think are a complete waste of your time ) , unknowns ( You do n't know what you do n't know so be generous here ) , and so forth .
If you provide generous padding for these inevitable realities of corporate life , you can create a schedule which will allow you to come in on time and under-budget .
If your project manager does not allow you to pad your estimate with unknowns , meetings , etc .
but requires you to give an estimate based on 40 actual coding hours per week , you 're getting set up for failure .
That means no bonuses , poor performance review , and generally bad morale because your team will be " late " on a project based on a half-assed schedule based on fiction.Even worse is when management says " Here is your next project : feature set is X , you have Y resources , and by the way , the due date is Z .
" Those are the absolute worst conditions to work under in development because management a ) does n't even know what out of X is possible , whether Y resources can actually accomplish it , and if even 1/3 of it can be accomplished within Z time based even on an ideal 40 hour workweek dedicated to writing code and doing nothing else.By the way : do not base it on 40 hours of coding at ALL to begin with .
You will spend 1-2 hours on emails , and a lot of time just engineering ( actually just thinking the problem through ) not to mention reviewing API calls you use and that time will easily match the time you spent coding .
Plan on maybe 20-25 measurable " productive " [ sic ] * hours per week .
* " productive " meaning what a PHB considers productive , i.e. , lines of code written , dialogs flashing on the screen , etc .</tokentext>
<sentencetext>Hold scrum meetings, and then ask each developer and tester individually how long each step will take.
Take their wild assed guess, compare it to what estimates you come up with in scrum meetings, and average those.
Multiply that estimate by 2.25 to take into account vacations, side projects, meetings (which for some positions can consume 60\% of your time, and you NEVER take those things into account when giving the project manager your estimate).
Allow for some buffer time for bug fixes, fighting with Microsoft about hotfixes for libraries in which you find critical bugs when you're at the final beta stages, and also allow for some buffer time for having to issue emergency bug fixes on your released branch.Estimates you come up with in scrum meetings and individuals' wild-assed guesses never take any of the unknowns into account.
The engineers with no management experience invariably think "well, I work 40 hours a week, and I think this module will take me 120 hours, then another 120 to integrate into the project - so yeah.
I can be done with my first phase in six weeks.
" That does not take into account sick days, dependencies (waiting on other developers for the components you need from them), time for getting sucked into meetings, time to rearchitect your piece when you find Microsoft's library doesn't actually worked as documented (or Microsoft's memory manager incurs eighteen gadzillion context switches per minute, slowing your process to a screeching halt under a moderate load) requiring you to invent your own or evaluate third-party libraries.Always provide buffers to allow for bureaucracy/politics (read: meetings you are required to attend but you think are a complete waste of your time), unknowns (You don't know what you don't know so be generous here), and so forth.
If you provide generous padding for these inevitable realities of corporate life, you can create a schedule which will allow you to come in on time and under-budget.
If your project manager does not allow you to pad your estimate with unknowns, meetings, etc.
but requires you to give an estimate based on 40 actual coding hours per week, you're getting set up for failure.
That means no bonuses, poor performance review, and generally bad morale because your team will be "late" on a project based on a half-assed schedule based on fiction.Even worse is when management says "Here is your next project: feature set is X, you have Y resources, and by the way, the due date is Z.
"   Those are the absolute worst conditions to work under in development because management a) doesn't even know what out of X is possible, whether Y resources can actually accomplish it, and if even 1/3 of it can be accomplished within Z time based even on an ideal 40 hour workweek dedicated to writing code and doing nothing else.By the way: do not base it on 40 hours of coding at ALL to begin with.
You will spend 1-2 hours on emails, and a lot of time just engineering (actually just thinking the problem through) not to mention reviewing API calls you use and that time will easily match the time you spent coding.
Plan on maybe 20-25 measurable "productive"[sic]* hours per week.
* "productive" meaning what a PHB considers productive, i.e., lines of code written, dialogs flashing on the screen, etc.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076378</id>
	<title>My estimation model</title>
	<author>thePowerOfGrayskull</author>
	<datestamp>1265747040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><ol>
<li> Come up with how long I think it would take a group of skilled developers to do it, then 2x because we employ precious few skilled developers.</li>
<li>Is it onshore work? 1.5x</li>
<li>Is it a mix of offshore and onshore work? 2x</li>
<li>Is it offshore work? 3x</li>
</ol><p>
Surprisingly accurate most of the time.
</p><p>
<i>Edit: Hm, I hope that "&lt;ol&gt;" only looks that bad in the preview... guess I'm about to find out. </i></p></htmltext>
<tokenext>Come up with how long I think it would take a group of skilled developers to do it , then 2x because we employ precious few skilled developers .
Is it onshore work ?
1.5x Is it a mix of offshore and onshore work ?
2x Is it offshore work ?
3x Surprisingly accurate most of the time .
Edit : Hm , I hope that " " only looks that bad in the preview... guess I 'm about to find out .</tokentext>
<sentencetext>
 Come up with how long I think it would take a group of skilled developers to do it, then 2x because we employ precious few skilled developers.
Is it onshore work?
1.5x
Is it a mix of offshore and onshore work?
2x
Is it offshore work?
3x

Surprisingly accurate most of the time.
Edit: Hm, I hope that "" only looks that bad in the preview... guess I'm about to find out. </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083364</id>
	<title>Use evidence-based scheduling!</title>
	<author>jonaskoelker</author>
	<datestamp>1265019180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Joel Spolsky has written about making useful estimates at <a href="http://www.joelonsoftware.com/items/2007/10/26.html" title="joelonsoftware.com">http://www.joelonsoftware.com/items/2007/10/26.html</a> [joelonsoftware.com]</p><p>The short version: for each developer, gather their estimated times and actual times for each of their projects.</p><p>If the ratio between the two is always 1, that person is the perfect estimator.  If it's systematically close to some x != 1, you just divide all their estimates by x to compensate for their optimism (or pessimism, as the case may be).  If the estimate factors are all over the board, you teach them how to estimate times better.</p></htmltext>
<tokenext>Joel Spolsky has written about making useful estimates at http : //www.joelonsoftware.com/items/2007/10/26.html [ joelonsoftware.com ] The short version : for each developer , gather their estimated times and actual times for each of their projects.If the ratio between the two is always 1 , that person is the perfect estimator .
If it 's systematically close to some x ! = 1 , you just divide all their estimates by x to compensate for their optimism ( or pessimism , as the case may be ) .
If the estimate factors are all over the board , you teach them how to estimate times better .</tokentext>
<sentencetext>Joel Spolsky has written about making useful estimates at http://www.joelonsoftware.com/items/2007/10/26.html [joelonsoftware.com]The short version: for each developer, gather their estimated times and actual times for each of their projects.If the ratio between the two is always 1, that person is the perfect estimator.
If it's systematically close to some x != 1, you just divide all their estimates by x to compensate for their optimism (or pessimism, as the case may be).
If the estimate factors are all over the board, you teach them how to estimate times better.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234</id>
	<title>It's Easy</title>
	<author>BabyDuckHat</author>
	<datestamp>1265743200000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>I just ask my manager how long he's already told the client it's going to take.</htmltext>
<tokenext>I just ask my manager how long he 's already told the client it 's going to take .</tokentext>
<sentencetext>I just ask my manager how long he's already told the client it's going to take.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078036</id>
	<title>Re:Specs</title>
	<author>quanticle</author>
	<datestamp>1265710560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The thing that has bitten me before is that sometimes the spec. constrains the design and significantly increases the cost.  To use the example provided by another post: lets say your client wants a Silverlight viewer for GIF images.  The specification for the viewer is detailed enough that you can come up with a detailed estimate.  However, unless you knew Silverlight very well ahead of time, you would not have realized that Silverlight could not display GIF images.  This would blow any estimate out of the water, since now you have to spend a potentially indefinite amount of time looking for a reusable component or coding up your own viewer.</p></htmltext>
<tokenext>The thing that has bitten me before is that sometimes the spec .
constrains the design and significantly increases the cost .
To use the example provided by another post : lets say your client wants a Silverlight viewer for GIF images .
The specification for the viewer is detailed enough that you can come up with a detailed estimate .
However , unless you knew Silverlight very well ahead of time , you would not have realized that Silverlight could not display GIF images .
This would blow any estimate out of the water , since now you have to spend a potentially indefinite amount of time looking for a reusable component or coding up your own viewer .</tokentext>
<sentencetext>The thing that has bitten me before is that sometimes the spec.
constrains the design and significantly increases the cost.
To use the example provided by another post: lets say your client wants a Silverlight viewer for GIF images.
The specification for the viewer is detailed enough that you can come up with a detailed estimate.
However, unless you knew Silverlight very well ahead of time, you would not have realized that Silverlight could not display GIF images.
This would blow any estimate out of the water, since now you have to spend a potentially indefinite amount of time looking for a reusable component or coding up your own viewer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083980</id>
	<title>Gummy Bears</title>
	<author>PMBjornerud</author>
	<datestamp>1265027340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I though the idea was to estimate in units after complexity. Units can be gummy bears or whatnot, but not bound to time in any way.</p><p>The reason being that it is much easier to relate to complexity than factor in everything to get a correct time estimate. Complexity can also be agreed upon by different people, even though the time required for them to complete an equally complex task can be very different for different developers, depending on skill or amount of disturbances from programming time.</p><p>Estimate a task in complexity. Multiply with a factor to get the time estimate. The factor depends on the developer, complexity depends on the task. Keep them separate.</p></htmltext>
<tokenext>I though the idea was to estimate in units after complexity .
Units can be gummy bears or whatnot , but not bound to time in any way.The reason being that it is much easier to relate to complexity than factor in everything to get a correct time estimate .
Complexity can also be agreed upon by different people , even though the time required for them to complete an equally complex task can be very different for different developers , depending on skill or amount of disturbances from programming time.Estimate a task in complexity .
Multiply with a factor to get the time estimate .
The factor depends on the developer , complexity depends on the task .
Keep them separate .</tokentext>
<sentencetext>I though the idea was to estimate in units after complexity.
Units can be gummy bears or whatnot, but not bound to time in any way.The reason being that it is much easier to relate to complexity than factor in everything to get a correct time estimate.
Complexity can also be agreed upon by different people, even though the time required for them to complete an equally complex task can be very different for different developers, depending on skill or amount of disturbances from programming time.Estimate a task in complexity.
Multiply with a factor to get the time estimate.
The factor depends on the developer, complexity depends on the task.
Keep them separate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076278</id>
	<title>All projects..</title>
	<author>Anonymous</author>
	<datestamp>1265746620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>All projects take 2 weeks to 6 months.  Anything beyond 6 months is Duke Nukem Forever.</p></htmltext>
<tokenext>All projects take 2 weeks to 6 months .
Anything beyond 6 months is Duke Nukem Forever .</tokentext>
<sentencetext>All projects take 2 weeks to 6 months.
Anything beyond 6 months is Duke Nukem Forever.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080240</id>
	<title>Re:Simply, no software required.</title>
	<author>emt377</author>
	<datestamp>1265720760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The next big factor hinted at elsewhere is the domain knowledge.  I can estimate better if I'm modifying my own code to do something similar.  I estimate badly when it's a section of code I'm unfamiliar with or a large framework.  This stuff, like the bug fixes, involves a lot of investigation, research, learning, etc.  You can't easily estimate that stuff.</p></div><p>Then you need to start with something more easily estimated: a ramp up task.  This can usually be estimated.  It usually helps to make up a few goals, like 1) being able to create a debug build from scratch on your dev system, 2) understanding of the problem solved by the software, 3) understanding of external interfaces (black box behavior) and a broad understanding of the design, 4) scoping out which parts of the implementation are relevant to your changes, and 5) a broad idea of what changes you will have to make.</p><p>In the iteration after this you can then usually scope out the actual implementation task.</p></div>
	</htmltext>
<tokenext>The next big factor hinted at elsewhere is the domain knowledge .
I can estimate better if I 'm modifying my own code to do something similar .
I estimate badly when it 's a section of code I 'm unfamiliar with or a large framework .
This stuff , like the bug fixes , involves a lot of investigation , research , learning , etc .
You ca n't easily estimate that stuff.Then you need to start with something more easily estimated : a ramp up task .
This can usually be estimated .
It usually helps to make up a few goals , like 1 ) being able to create a debug build from scratch on your dev system , 2 ) understanding of the problem solved by the software , 3 ) understanding of external interfaces ( black box behavior ) and a broad understanding of the design , 4 ) scoping out which parts of the implementation are relevant to your changes , and 5 ) a broad idea of what changes you will have to make.In the iteration after this you can then usually scope out the actual implementation task .</tokentext>
<sentencetext>The next big factor hinted at elsewhere is the domain knowledge.
I can estimate better if I'm modifying my own code to do something similar.
I estimate badly when it's a section of code I'm unfamiliar with or a large framework.
This stuff, like the bug fixes, involves a lot of investigation, research, learning, etc.
You can't easily estimate that stuff.Then you need to start with something more easily estimated: a ramp up task.
This can usually be estimated.
It usually helps to make up a few goals, like 1) being able to create a debug build from scratch on your dev system, 2) understanding of the problem solved by the software, 3) understanding of external interfaces (black box behavior) and a broad understanding of the design, 4) scoping out which parts of the implementation are relevant to your changes, and 5) a broad idea of what changes you will have to make.In the iteration after this you can then usually scope out the actual implementation task.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077358</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080154</id>
	<title>Re:Bill per hour</title>
	<author>Anonymous</author>
	<datestamp>1265720160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>All that to write "I don't do a good job of estimating, so I won't do it."  Well, you wouldn't get hired by me... we don't hire contractors by the hour.  You get paid to do a job.  Just like a plumber.</p></htmltext>
<tokenext>All that to write " I do n't do a good job of estimating , so I wo n't do it .
" Well , you would n't get hired by me... we do n't hire contractors by the hour .
You get paid to do a job .
Just like a plumber .</tokentext>
<sentencetext>All that to write "I don't do a good job of estimating, so I won't do it.
"  Well, you wouldn't get hired by me... we don't hire contractors by the hour.
You get paid to do a job.
Just like a plumber.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075868</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078022</id>
	<title>It's easy</title>
	<author>ucblockhead</author>
	<datestamp>1265710560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You make a wild at guess at the time it will take.  Then you double that.  Then you add a week for bugfixing.</p><p>Then, during the schedule, if you start to get ahead, spend more time browsing the web.  If you start to get behind, work extra and/or cut things like "unit testing" or "error checking".  Do this as needed to deliver one day ahead of schedule.  Then bask your reputation as an awesome scheduler.</p></htmltext>
<tokenext>You make a wild at guess at the time it will take .
Then you double that .
Then you add a week for bugfixing.Then , during the schedule , if you start to get ahead , spend more time browsing the web .
If you start to get behind , work extra and/or cut things like " unit testing " or " error checking " .
Do this as needed to deliver one day ahead of schedule .
Then bask your reputation as an awesome scheduler .</tokentext>
<sentencetext>You make a wild at guess at the time it will take.
Then you double that.
Then you add a week for bugfixing.Then, during the schedule, if you start to get ahead, spend more time browsing the web.
If you start to get behind, work extra and/or cut things like "unit testing" or "error checking".
Do this as needed to deliver one day ahead of schedule.
Then bask your reputation as an awesome scheduler.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075488</id>
	<title>Dilbert</title>
	<author>Anonymous</author>
	<datestamp>1265744100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Collect the relevant cartoons together and you'll have a fairly thorough treatise on the subject.</p></htmltext>
<tokenext>Collect the relevant cartoons together and you 'll have a fairly thorough treatise on the subject .</tokentext>
<sentencetext>Collect the relevant cartoons together and you'll have a fairly thorough treatise on the subject.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075396</id>
	<title>Re:Specs</title>
	<author>Lumpy</author>
	<datestamp>1265743740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You nailed it.</p><p>If the Scope of work document is inaccurate then the estimate on time will be inaccurate.</p><p>Give me a real Scope of work, I'll give you a real estimate of time.   If someone would clamp battery terminals to the Executives nipples and not stop shocking them until they get it through their heads, we all would not have to guess.</p></htmltext>
<tokenext>You nailed it.If the Scope of work document is inaccurate then the estimate on time will be inaccurate.Give me a real Scope of work , I 'll give you a real estimate of time .
If someone would clamp battery terminals to the Executives nipples and not stop shocking them until they get it through their heads , we all would not have to guess .</tokentext>
<sentencetext>You nailed it.If the Scope of work document is inaccurate then the estimate on time will be inaccurate.Give me a real Scope of work, I'll give you a real estimate of time.
If someone would clamp battery terminals to the Executives nipples and not stop shocking them until they get it through their heads, we all would not have to guess.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075082</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075258</id>
	<title>Hofstadter's Law</title>
	<author>Anonymous</author>
	<datestamp>1265743260000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>1</modscore>
	<htmltext><p>http://en.wikipedia.org/wiki/Hofstadter\%27s\_law</p><p>Hofstadter's Law:  It always takes longer than you expect, even when you take into account Hofstadter's Law.</p></htmltext>
<tokenext>http : //en.wikipedia.org/wiki/Hofstadter \ % 27s \ _lawHofstadter 's Law : It always takes longer than you expect , even when you take into account Hofstadter 's Law .</tokentext>
<sentencetext>http://en.wikipedia.org/wiki/Hofstadter\%27s\_lawHofstadter's Law:  It always takes longer than you expect, even when you take into account Hofstadter's Law.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081902</id>
	<title>Re:Easy</title>
	<author>mgblst</author>
	<datestamp>1265734920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>So multiply by 20 then?</p></htmltext>
<tokenext>So multiply by 20 then ?</tokentext>
<sentencetext>So multiply by 20 then?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075364</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31084388</id>
	<title>A few pointers</title>
	<author>CHJacobsen</author>
	<datestamp>1265032020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's always an inaccurate science, but since the consulting business seems to be hopelessly dependent on it, here are my best suggestions:</p><p>1. Try to break down tasks into the smallest measurable subtask. It's easier to estimate "form for adding new users" than it is to estimate "create the admin site"<br>2. It's going to take longer than you think, so plan more time than you think you need.<br>3. If possible, try to add generic "risk hours" to each project, for unexpected issues. This isn't always possible, but it's a great help.</p><p>And, finally, the most important one:<br>4. Beware of timecreeps. This is related to the first tip. If your planning is detailed enough, you can usually say "Oh, you want the create-user form to be submitted by using ajax? Sure, no problem. That would take around 2 more hours. Any problem there?". With a less detailed specification, the customer is more likely to assume it's a part of the original estimation.</p></htmltext>
<tokenext>It 's always an inaccurate science , but since the consulting business seems to be hopelessly dependent on it , here are my best suggestions : 1 .
Try to break down tasks into the smallest measurable subtask .
It 's easier to estimate " form for adding new users " than it is to estimate " create the admin site " 2 .
It 's going to take longer than you think , so plan more time than you think you need.3 .
If possible , try to add generic " risk hours " to each project , for unexpected issues .
This is n't always possible , but it 's a great help.And , finally , the most important one : 4 .
Beware of timecreeps .
This is related to the first tip .
If your planning is detailed enough , you can usually say " Oh , you want the create-user form to be submitted by using ajax ?
Sure , no problem .
That would take around 2 more hours .
Any problem there ? " .
With a less detailed specification , the customer is more likely to assume it 's a part of the original estimation .</tokentext>
<sentencetext>It's always an inaccurate science, but since the consulting business seems to be hopelessly dependent on it, here are my best suggestions:1.
Try to break down tasks into the smallest measurable subtask.
It's easier to estimate "form for adding new users" than it is to estimate "create the admin site"2.
It's going to take longer than you think, so plan more time than you think you need.3.
If possible, try to add generic "risk hours" to each project, for unexpected issues.
This isn't always possible, but it's a great help.And, finally, the most important one:4.
Beware of timecreeps.
This is related to the first tip.
If your planning is detailed enough, you can usually say "Oh, you want the create-user form to be submitted by using ajax?
Sure, no problem.
That would take around 2 more hours.
Any problem there?".
With a less detailed specification, the customer is more likely to assume it's a part of the original estimation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077002</id>
	<title>I am often subjected to mockery by it, but COCOMO</title>
	<author>pestilence669</author>
	<datestamp>1265706300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>COCOMO II models are based upon SLOC (source lines of code) estimates. You plug in a bunch of other metrics, like the language, type of application, quality of coders, calendar, etc. What you get out is a reasonable estimate, built from the analysis of 1,000's of real-world projects.</p><p>"How many lines of code?" is often easier to answer than "how long will this take?" Is SLOC accurate? No. But, it's only a small part of the process. You can always factor out waste from guys you know are gaming the system. With a decent tool, you can even plug in actuals from previous projects for fine tuning.</p><p>It's very similar to other methods, but tends to be a bit more accurate... despite asking for lines instead of hours.</p></htmltext>
<tokenext>COCOMO II models are based upon SLOC ( source lines of code ) estimates .
You plug in a bunch of other metrics , like the language , type of application , quality of coders , calendar , etc .
What you get out is a reasonable estimate , built from the analysis of 1,000 's of real-world projects .
" How many lines of code ?
" is often easier to answer than " how long will this take ?
" Is SLOC accurate ?
No. But , it 's only a small part of the process .
You can always factor out waste from guys you know are gaming the system .
With a decent tool , you can even plug in actuals from previous projects for fine tuning.It 's very similar to other methods , but tends to be a bit more accurate... despite asking for lines instead of hours .</tokentext>
<sentencetext>COCOMO II models are based upon SLOC (source lines of code) estimates.
You plug in a bunch of other metrics, like the language, type of application, quality of coders, calendar, etc.
What you get out is a reasonable estimate, built from the analysis of 1,000's of real-world projects.
"How many lines of code?
" is often easier to answer than "how long will this take?
" Is SLOC accurate?
No. But, it's only a small part of the process.
You can always factor out waste from guys you know are gaming the system.
With a decent tool, you can even plug in actuals from previous projects for fine tuning.It's very similar to other methods, but tends to be a bit more accurate... despite asking for lines instead of hours.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076648</id>
	<title>Re:Simply, no software required.</title>
	<author>Anonymous</author>
	<datestamp>1265748180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>My equation is to take my first wild guess, double it, then add another 30\%.  That is for bare minimum code, no documentation or extensive testing.  Doubling the estimate and bumping the time unit is probably more accurate.</p></htmltext>
<tokenext>My equation is to take my first wild guess , double it , then add another 30 \ % .
That is for bare minimum code , no documentation or extensive testing .
Doubling the estimate and bumping the time unit is probably more accurate .</tokentext>
<sentencetext>My equation is to take my first wild guess, double it, then add another 30\%.
That is for bare minimum code, no documentation or extensive testing.
Doubling the estimate and bumping the time unit is probably more accurate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076080</id>
	<title>Use a team-based estimation technique</title>
	<author>\_\_roo</author>
	<datestamp>1265745960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've spent a lot of time working with many different teams and trying lots of different estimation techniques, and I've had the best success with the ones that let the team work together to come up with an estimate they all believe in. My best results came with <a href="http://www.stellman-greene.com/widebanddelphi" title="stellman-greene.com">Wideband Delphi</a> [stellman-greene.com], which I've been able to use in both Agile and non-Agile projects. I've actually got a chapter on estimation in one of my books -- you can <a href="http://www.stellman-greene.com/ch03" title="stellman-greene.com">download the PDF of it</a> [stellman-greene.com].</p><p>Also, Mike Cohn has a lot to say about planning Agile projects <a href="http://blog.mountaingoatsoftware.com/" title="mountaingoatsoftware.com">on his blog</a> [mountaingoatsoftware.com] -- definitely highly recommended reading if you're trying to plan projects.</p><p>Whenever I help teams improve the way they estimate their projects, one of the things I've really concentrated on is that planning is about more than estimation. I've got a blog post about it (<a href="http://www.stellman-greene.com/2009/08/14/the-perils-of-a-schedule/" title="stellman-greene.com">The Perils of a Schedule</a> [stellman-greene.com]) -- a big part of planning is making commitments, and estimation is the way to make those commitments easier to stick to (or less likely to break).</p></htmltext>
<tokenext>I 've spent a lot of time working with many different teams and trying lots of different estimation techniques , and I 've had the best success with the ones that let the team work together to come up with an estimate they all believe in .
My best results came with Wideband Delphi [ stellman-greene.com ] , which I 've been able to use in both Agile and non-Agile projects .
I 've actually got a chapter on estimation in one of my books -- you can download the PDF of it [ stellman-greene.com ] .Also , Mike Cohn has a lot to say about planning Agile projects on his blog [ mountaingoatsoftware.com ] -- definitely highly recommended reading if you 're trying to plan projects.Whenever I help teams improve the way they estimate their projects , one of the things I 've really concentrated on is that planning is about more than estimation .
I 've got a blog post about it ( The Perils of a Schedule [ stellman-greene.com ] ) -- a big part of planning is making commitments , and estimation is the way to make those commitments easier to stick to ( or less likely to break ) .</tokentext>
<sentencetext>I've spent a lot of time working with many different teams and trying lots of different estimation techniques, and I've had the best success with the ones that let the team work together to come up with an estimate they all believe in.
My best results came with Wideband Delphi [stellman-greene.com], which I've been able to use in both Agile and non-Agile projects.
I've actually got a chapter on estimation in one of my books -- you can download the PDF of it [stellman-greene.com].Also, Mike Cohn has a lot to say about planning Agile projects on his blog [mountaingoatsoftware.com] -- definitely highly recommended reading if you're trying to plan projects.Whenever I help teams improve the way they estimate their projects, one of the things I've really concentrated on is that planning is about more than estimation.
I've got a blog post about it (The Perils of a Schedule [stellman-greene.com]) -- a big part of planning is making commitments, and estimation is the way to make those commitments easier to stick to (or less likely to break).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075578</id>
	<title>It's all about uncertainty</title>
	<author>AardvarkCelery</author>
	<datestamp>1265744460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Agreed.  The main complicating factor is the level of <strong>uncertainty</strong>:</p><ul>
<li>Ambiguity in the <i>specification</i> </li><li>Unfamiliar <i>technology</i> </li><li> <i>Code design</i> with non-obvious solutions</li><li> <i>Interface constraints</i> that must be reconciled</li></ul><p>I list the uncertainties, make a wild guess on each one, and finally triple the result.  Historically I only successfully predict about 1/3 of the problems that are going to come up.</p><p>The hard part is justifying the inflated estimate when asked, since it's based on difficulties that I haven't actually identified yet.</p></htmltext>
<tokenext>Agreed .
The main complicating factor is the level of uncertainty : Ambiguity in the specification Unfamiliar technology Code design with non-obvious solutions Interface constraints that must be reconciledI list the uncertainties , make a wild guess on each one , and finally triple the result .
Historically I only successfully predict about 1/3 of the problems that are going to come up.The hard part is justifying the inflated estimate when asked , since it 's based on difficulties that I have n't actually identified yet .</tokentext>
<sentencetext>Agreed.
The main complicating factor is the level of uncertainty:
Ambiguity in the specification Unfamiliar technology  Code design with non-obvious solutions Interface constraints that must be reconciledI list the uncertainties, make a wild guess on each one, and finally triple the result.
Historically I only successfully predict about 1/3 of the problems that are going to come up.The hard part is justifying the inflated estimate when asked, since it's based on difficulties that I haven't actually identified yet.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078122</id>
	<title>Design time vs Programming time</title>
	<author>bug1</author>
	<datestamp>1265710860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The time it takes to designing software is way more unpredictable than the time i spend programming it.</p><p>If the design is all done then programming should be very predictable, but the problem is that design is never done well.</p><p>Imagine if you asked a builder how long it will take for him to build you a new house, but you dont provide a design, you just give him a list of features (fireplace, stairs, 2 bedrooms etc etc), the builder has as much chance of estimating time to build as a programer has of estimating time to write.</p><p>Now i want you all to repeat aloud;</p><p>DESIGN IS MORE VALUABLE THAN CODE,<br>DESIGN IS MORE VALUABLE THAN CODE,<br>DESIGN IS MORE VALUABLE THAN CODE<nobr> <wbr></nobr>;p</p></htmltext>
<tokenext>The time it takes to designing software is way more unpredictable than the time i spend programming it.If the design is all done then programming should be very predictable , but the problem is that design is never done well.Imagine if you asked a builder how long it will take for him to build you a new house , but you dont provide a design , you just give him a list of features ( fireplace , stairs , 2 bedrooms etc etc ) , the builder has as much chance of estimating time to build as a programer has of estimating time to write.Now i want you all to repeat aloud ; DESIGN IS MORE VALUABLE THAN CODE,DESIGN IS MORE VALUABLE THAN CODE,DESIGN IS MORE VALUABLE THAN CODE ; p</tokentext>
<sentencetext>The time it takes to designing software is way more unpredictable than the time i spend programming it.If the design is all done then programming should be very predictable, but the problem is that design is never done well.Imagine if you asked a builder how long it will take for him to build you a new house, but you dont provide a design, you just give him a list of features (fireplace, stairs, 2 bedrooms etc etc), the builder has as much chance of estimating time to build as a programer has of estimating time to write.Now i want you all to repeat aloud;DESIGN IS MORE VALUABLE THAN CODE,DESIGN IS MORE VALUABLE THAN CODE,DESIGN IS MORE VALUABLE THAN CODE ;p</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079208</id>
	<title>Can you?</title>
	<author>Anonymous</author>
	<datestamp>1265715300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You don't. That's why they are called estimates.</p></htmltext>
<tokenext>You do n't .
That 's why they are called estimates .</tokentext>
<sentencetext>You don't.
That's why they are called estimates.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077358</id>
	<title>Re:Simply, no software required.</title>
	<author>Darinbob</author>
	<datestamp>1265707800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm really bad at this myself.  If I think something will take a week, it will take a month.  If I think it will take a month it may only take a week.  Luckily my bosses in the past have rarely asked for strict time estimates, but sometimes they do.  The worst is giving estimates for a bug fix - how can you estimate how to fix a bug when you don't even know what the cause is and the bug isn't reproducible and the description is vague?<br><br>The next big factor hinted at elsewhere is the domain knowledge.  I can estimate better if I'm modifying my own code to do something similar.  I estimate badly when it's a section of code I'm unfamiliar with or a large framework.  This stuff, like the bug fixes, involves a lot of investigation, research, learning, etc.  You can't easily estimate that stuff.</htmltext>
<tokenext>I 'm really bad at this myself .
If I think something will take a week , it will take a month .
If I think it will take a month it may only take a week .
Luckily my bosses in the past have rarely asked for strict time estimates , but sometimes they do .
The worst is giving estimates for a bug fix - how can you estimate how to fix a bug when you do n't even know what the cause is and the bug is n't reproducible and the description is vague ? The next big factor hinted at elsewhere is the domain knowledge .
I can estimate better if I 'm modifying my own code to do something similar .
I estimate badly when it 's a section of code I 'm unfamiliar with or a large framework .
This stuff , like the bug fixes , involves a lot of investigation , research , learning , etc .
You ca n't easily estimate that stuff .</tokentext>
<sentencetext>I'm really bad at this myself.
If I think something will take a week, it will take a month.
If I think it will take a month it may only take a week.
Luckily my bosses in the past have rarely asked for strict time estimates, but sometimes they do.
The worst is giving estimates for a bug fix - how can you estimate how to fix a bug when you don't even know what the cause is and the bug isn't reproducible and the description is vague?The next big factor hinted at elsewhere is the domain knowledge.
I can estimate better if I'm modifying my own code to do something similar.
I estimate badly when it's a section of code I'm unfamiliar with or a large framework.
This stuff, like the bug fixes, involves a lot of investigation, research, learning, etc.
You can't easily estimate that stuff.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075668</id>
	<title>Re:It's Easy</title>
	<author>GNUALMAFUERTE</author>
	<datestamp>1265744700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And then just don't sleep for as many days as necessary to deliver, work on weekends, and deliver ontime, without testing, knowing that the binaries you are delivering where compiled the night before the delivery date at 5 A.M.</p><p>Yes, it's my way<nobr> <wbr></nobr>...</p></htmltext>
<tokenext>And then just do n't sleep for as many days as necessary to deliver , work on weekends , and deliver ontime , without testing , knowing that the binaries you are delivering where compiled the night before the delivery date at 5 A.M.Yes , it 's my way .. .</tokentext>
<sentencetext>And then just don't sleep for as many days as necessary to deliver, work on weekends, and deliver ontime, without testing, knowing that the binaries you are delivering where compiled the night before the delivery date at 5 A.M.Yes, it's my way ...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075778</id>
	<title>you Fail it</title>
	<author>Anonymous</author>
	<datestamp>1265745000000</datestamp>
	<modclass>Redundant</modclass>
	<modscore>-1</modscore>
	<htmltext><A HREF="http://goat.cx/" title="goat.cx" rel="nofollow">and that the fllor BSD m5achines</a> [goat.cx]</htmltext>
<tokenext>and that the fllor BSD m5achines [ goat.cx ]</tokentext>
<sentencetext>and that the fllor BSD m5achines [goat.cx]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082784</id>
	<title>Re:Simply, no software required.</title>
	<author>Kjella</author>
	<datestamp>1265056020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Estimate the worst possible case, if everything goes wrong, and there are lots of unforeseen issues - you are 99\% sure you can get it done within this amount of time. Call it T3.</p><p>The Weighted average estimate is (T1+(4*T2) + T3)/6</p></div><p>That's also the PMI method, but the problem is estimating T3 and the outcome largely depends on T3 as you saw. The 95\%, 99\% and 99.9\% T3 estimate will be way different because there's a really long tail, and then so will your weighted average. The three estimates usually map to:</p><p>T1: I got a design in mind that will in general work<br>T2: I got a design in mind that with some tweaking and fixing and reading docs it'll work<br>T3: I got a design in mind that'll turn out to be unusable or impossible to execute</p><p>T1 is fairly easy, T2 is usually just T1 multiplied by a fixed factor. But the last could push it back from "two days" to "critically depends on having an obscure bug fixed in middleware/base libraries that could take months". It's near unestimatable to say how bad it really could go.</p></div>
	</htmltext>
<tokenext>Estimate the worst possible case , if everything goes wrong , and there are lots of unforeseen issues - you are 99 \ % sure you can get it done within this amount of time .
Call it T3.The Weighted average estimate is ( T1 + ( 4 * T2 ) + T3 ) /6That 's also the PMI method , but the problem is estimating T3 and the outcome largely depends on T3 as you saw .
The 95 \ % , 99 \ % and 99.9 \ % T3 estimate will be way different because there 's a really long tail , and then so will your weighted average .
The three estimates usually map to : T1 : I got a design in mind that will in general workT2 : I got a design in mind that with some tweaking and fixing and reading docs it 'll workT3 : I got a design in mind that 'll turn out to be unusable or impossible to executeT1 is fairly easy , T2 is usually just T1 multiplied by a fixed factor .
But the last could push it back from " two days " to " critically depends on having an obscure bug fixed in middleware/base libraries that could take months " .
It 's near unestimatable to say how bad it really could go .</tokentext>
<sentencetext>Estimate the worst possible case, if everything goes wrong, and there are lots of unforeseen issues - you are 99\% sure you can get it done within this amount of time.
Call it T3.The Weighted average estimate is (T1+(4*T2) + T3)/6That's also the PMI method, but the problem is estimating T3 and the outcome largely depends on T3 as you saw.
The 95\%, 99\% and 99.9\% T3 estimate will be way different because there's a really long tail, and then so will your weighted average.
The three estimates usually map to:T1: I got a design in mind that will in general workT2: I got a design in mind that with some tweaking and fixing and reading docs it'll workT3: I got a design in mind that'll turn out to be unusable or impossible to executeT1 is fairly easy, T2 is usually just T1 multiplied by a fixed factor.
But the last could push it back from "two days" to "critically depends on having an obscure bug fixed in middleware/base libraries that could take months".
It's near unestimatable to say how bad it really could go.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081416</id>
	<title>Re:Function Point Analysis and Man Hours</title>
	<author>Canberra Bob</author>
	<datestamp>1265729340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Sounds similar to the method I used to use<br>I would make an estimate, add a 50\% buffer and double it and send it to the sales rep<br>The sales rep came from a technical background so knew how IT projects went, so he would take my estimate, double it and add a buffer to that.<br>This method actually produced estimates quite close to what turned into reality.</p><p>I think the problem with estimates are that:<br>a) developers are never as fast as they think they are,<br>b) the customer always has something hidden in there that actually means something far more complex than what it appears,<br>c) there are always unforseen things that go wrong eg a bug in some framework you use that you have to then spend time hacking around and<br>d) the human factor - some people leave the project, some people would be more useful to the project if they had nothing to do with it, etc.</p></htmltext>
<tokenext>Sounds similar to the method I used to useI would make an estimate , add a 50 \ % buffer and double it and send it to the sales repThe sales rep came from a technical background so knew how IT projects went , so he would take my estimate , double it and add a buffer to that.This method actually produced estimates quite close to what turned into reality.I think the problem with estimates are that : a ) developers are never as fast as they think they are,b ) the customer always has something hidden in there that actually means something far more complex than what it appears,c ) there are always unforseen things that go wrong eg a bug in some framework you use that you have to then spend time hacking around andd ) the human factor - some people leave the project , some people would be more useful to the project if they had nothing to do with it , etc .</tokentext>
<sentencetext>Sounds similar to the method I used to useI would make an estimate, add a 50\% buffer and double it and send it to the sales repThe sales rep came from a technical background so knew how IT projects went, so he would take my estimate, double it and add a buffer to that.This method actually produced estimates quite close to what turned into reality.I think the problem with estimates are that:a) developers are never as fast as they think they are,b) the customer always has something hidden in there that actually means something far more complex than what it appears,c) there are always unforseen things that go wrong eg a bug in some framework you use that you have to then spend time hacking around andd) the human factor - some people leave the project, some people would be more useful to the project if they had nothing to do with it, etc.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076318</id>
	<title>Re:This is what I usually do.</title>
	<author>Anonymous</author>
	<datestamp>1265746800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The law of Fives is never wrong.</p></htmltext>
<tokenext>The law of Fives is never wrong .</tokentext>
<sentencetext>The law of Fives is never wrong.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081980</id>
	<title>Re:Simply, no software required.</title>
	<author>BlackHawk-666</author>
	<datestamp>1265735940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If your estimates are out by a factor of 14 then it means you definitely are poor at estimates and most likely are poor at implementation - though that's less certain.</p><p>You either massively underestimate the amount of time it takes to bring something full life cycle, are unaware of what full life cycle encounters, or imagine your abilities to be way beyond your actual capacity. You haven't been fired yet, so you're probably not that much worse than the people around you, or your project manager is also incompetent and hasn't picked up on your low output.</p><p>Try getting some other workers on the projects to help you form an estimate, or sit with your project manager and get him to run you through estimating things like bug fixes, revision cycles, testing, documentation, and all the other myriad things you do to complete a project. Check your previous project plans to see how long previous sections of code took to produce and work out if the new one is harder or simpler and adjust accordingly.</p></htmltext>
<tokenext>If your estimates are out by a factor of 14 then it means you definitely are poor at estimates and most likely are poor at implementation - though that 's less certain.You either massively underestimate the amount of time it takes to bring something full life cycle , are unaware of what full life cycle encounters , or imagine your abilities to be way beyond your actual capacity .
You have n't been fired yet , so you 're probably not that much worse than the people around you , or your project manager is also incompetent and has n't picked up on your low output.Try getting some other workers on the projects to help you form an estimate , or sit with your project manager and get him to run you through estimating things like bug fixes , revision cycles , testing , documentation , and all the other myriad things you do to complete a project .
Check your previous project plans to see how long previous sections of code took to produce and work out if the new one is harder or simpler and adjust accordingly .</tokentext>
<sentencetext>If your estimates are out by a factor of 14 then it means you definitely are poor at estimates and most likely are poor at implementation - though that's less certain.You either massively underestimate the amount of time it takes to bring something full life cycle, are unaware of what full life cycle encounters, or imagine your abilities to be way beyond your actual capacity.
You haven't been fired yet, so you're probably not that much worse than the people around you, or your project manager is also incompetent and hasn't picked up on your low output.Try getting some other workers on the projects to help you form an estimate, or sit with your project manager and get him to run you through estimating things like bug fixes, revision cycles, testing, documentation, and all the other myriad things you do to complete a project.
Check your previous project plans to see how long previous sections of code took to produce and work out if the new one is harder or simpler and adjust accordingly.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075418</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076568</id>
	<title>Re:Uhh, Scrum is not an estimation method</title>
	<author>JohnFluxx</author>
	<datestamp>1265747820000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>In reality, by the end of the project you are creating new backlogs as fast/faster than fulfilling them.   There's always code that needs to be redone, newly found bugs to fix, performance testing that needs to be done, etc.  You can't "create and agree" on performance, debugging etc backlogs ahead of time.</p></htmltext>
<tokenext>In reality , by the end of the project you are creating new backlogs as fast/faster than fulfilling them .
There 's always code that needs to be redone , newly found bugs to fix , performance testing that needs to be done , etc .
You ca n't " create and agree " on performance , debugging etc backlogs ahead of time .</tokentext>
<sentencetext>In reality, by the end of the project you are creating new backlogs as fast/faster than fulfilling them.
There's always code that needs to be redone, newly found bugs to fix, performance testing that needs to be done, etc.
You can't "create and agree" on performance, debugging etc backlogs ahead of time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082476</id>
	<title>Re:It's Easy</title>
	<author>FlyingGuy</author>
	<datestamp>1265741940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This should have been moded insightful + 10*10^6 and then some.</p><p>The people who actually do the work are almost always the last ones to know what the damn code is supposed to do.</p><p>Back in the days when I had a boss ( that was not the client ) I would get called into the last meeting before the sales asshat told the client, oh yeah we are ready to go and I always asked, "What have you promised?" and take it from there.</p></htmltext>
<tokenext>This should have been moded insightful + 10 * 10 ^ 6 and then some.The people who actually do the work are almost always the last ones to know what the damn code is supposed to do.Back in the days when I had a boss ( that was not the client ) I would get called into the last meeting before the sales asshat told the client , oh yeah we are ready to go and I always asked , " What have you promised ?
" and take it from there .</tokentext>
<sentencetext>This should have been moded insightful + 10*10^6 and then some.The people who actually do the work are almost always the last ones to know what the damn code is supposed to do.Back in the days when I had a boss ( that was not the client ) I would get called into the last meeting before the sales asshat told the client, oh yeah we are ready to go and I always asked, "What have you promised?
" and take it from there.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075186</id>
	<title>Stop estimating a single number</title>
	<author>Anonymous</author>
	<datestamp>1265743080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Nobody can ever give you a usable number. No matter how often you ask them. Instead, ask them for 5\%, 50\% and 95\% numbers. These numbers indicate both the expected completion date, the amount of work they estimate and their feeling of worst-case, or uncertainty. When the three are far apart, that's a hint to you that it's not sufficiently clear &amp; they need more data. When they're very close together or the developer refuses to give them, there's probably some pressure on him that would disadvantage him if he did - for example, knowing your response to his actual 95\% number.</p></htmltext>
<tokenext>Nobody can ever give you a usable number .
No matter how often you ask them .
Instead , ask them for 5 \ % , 50 \ % and 95 \ % numbers .
These numbers indicate both the expected completion date , the amount of work they estimate and their feeling of worst-case , or uncertainty .
When the three are far apart , that 's a hint to you that it 's not sufficiently clear &amp; they need more data .
When they 're very close together or the developer refuses to give them , there 's probably some pressure on him that would disadvantage him if he did - for example , knowing your response to his actual 95 \ % number .</tokentext>
<sentencetext>Nobody can ever give you a usable number.
No matter how often you ask them.
Instead, ask them for 5\%, 50\% and 95\% numbers.
These numbers indicate both the expected completion date, the amount of work they estimate and their feeling of worst-case, or uncertainty.
When the three are far apart, that's a hint to you that it's not sufficiently clear &amp; they need more data.
When they're very close together or the developer refuses to give them, there's probably some pressure on him that would disadvantage him if he did - for example, knowing your response to his actual 95\% number.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077628</id>
	<title>Estimates aren't half as annoying...</title>
	<author>Kjella</author>
	<datestamp>1265708880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>...as the way people think they can manipulate the estimates. It's like I give an estimate to bake a cake, then halfway into baking it they decide we only need a cake 80\% the size, so that can be done in 80\% of the time for 80\% of the cost right? Everybody except project managers and clients would laugh at that, but it's happened in far too many planning meetings to count - particularly in response to overruns. If there had been complicated or expensive toppings that were easy to remove, they would usually already have been stripped in negotiations already so the estimates just don't work that way.</p></htmltext>
<tokenext>...as the way people think they can manipulate the estimates .
It 's like I give an estimate to bake a cake , then halfway into baking it they decide we only need a cake 80 \ % the size , so that can be done in 80 \ % of the time for 80 \ % of the cost right ?
Everybody except project managers and clients would laugh at that , but it 's happened in far too many planning meetings to count - particularly in response to overruns .
If there had been complicated or expensive toppings that were easy to remove , they would usually already have been stripped in negotiations already so the estimates just do n't work that way .</tokentext>
<sentencetext>...as the way people think they can manipulate the estimates.
It's like I give an estimate to bake a cake, then halfway into baking it they decide we only need a cake 80\% the size, so that can be done in 80\% of the time for 80\% of the cost right?
Everybody except project managers and clients would laugh at that, but it's happened in far too many planning meetings to count - particularly in response to overruns.
If there had been complicated or expensive toppings that were easy to remove, they would usually already have been stripped in negotiations already so the estimates just don't work that way.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334</id>
	<title>Well, I *used* to use the entrails of goats...</title>
	<author>gestalt\_n\_pepper</author>
	<datestamp>1265743560000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>But the folks who used the table in the lunchroom complained, so we now use the far more sophisticated system of tea leaf reading. This upsets nobody but the tea drinkers as we frequently need to user their cups before they're done, but then tea drinkers are wussies anyway.</p></htmltext>
<tokenext>But the folks who used the table in the lunchroom complained , so we now use the far more sophisticated system of tea leaf reading .
This upsets nobody but the tea drinkers as we frequently need to user their cups before they 're done , but then tea drinkers are wussies anyway .</tokentext>
<sentencetext>But the folks who used the table in the lunchroom complained, so we now use the far more sophisticated system of tea leaf reading.
This upsets nobody but the tea drinkers as we frequently need to user their cups before they're done, but then tea drinkers are wussies anyway.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31086342</id>
	<title>Re:Simply, no software required.</title>
	<author>Anonymous</author>
	<datestamp>1265042820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>This is a <a href="http://en.wikipedia.org/wiki/Program\_Evaluation\_and\_Review\_Technique" title="wikipedia.org" rel="nofollow">PERT</a> [wikipedia.org] estimation formulae. It closely relate to "average" expected time. There is PERT derivation (D=(T3-T1)/6) which cooresponds to "standard deviation" in statistics and let you predict percentile of the project completion to specified date.</htmltext>
<tokenext>This is a PERT [ wikipedia.org ] estimation formulae .
It closely relate to " average " expected time .
There is PERT derivation ( D = ( T3-T1 ) /6 ) which cooresponds to " standard deviation " in statistics and let you predict percentile of the project completion to specified date .</tokentext>
<sentencetext>This is a PERT [wikipedia.org] estimation formulae.
It closely relate to "average" expected time.
There is PERT derivation (D=(T3-T1)/6) which cooresponds to "standard deviation" in statistics and let you predict percentile of the project completion to specified date.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076190</id>
	<title>Evidence-based scheduling</title>
	<author>Krishnoid</author>
	<datestamp>1265746320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Joel Spolsky has a <a href="http://www.joelonsoftware.com/items/2007/10/26.html" title="joelonsoftware.com">method</a> [joelonsoftware.com] which ostensibly accommodates for consistent over- or under-estimating by any individual developer.  It takes a couple release cycles to collect the necessary information, then tries to use that data to provide a likelihood that a product will ship by a given date.</htmltext>
<tokenext>Joel Spolsky has a method [ joelonsoftware.com ] which ostensibly accommodates for consistent over- or under-estimating by any individual developer .
It takes a couple release cycles to collect the necessary information , then tries to use that data to provide a likelihood that a product will ship by a given date .</tokentext>
<sentencetext>Joel Spolsky has a method [joelonsoftware.com] which ostensibly accommodates for consistent over- or under-estimating by any individual developer.
It takes a couple release cycles to collect the necessary information, then tries to use that data to provide a likelihood that a product will ship by a given date.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075104</id>
	<title>Why does a dog lick his balls?</title>
	<author>Third Position</author>
	<datestamp>1265742900000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext><p><i>How Do You Accurately Estimate Programming Time?</i></p><p>I'm sure there's a great punch line that goes here, but I just can't think of one just now.</p><p>Opening the floor for suggestions!</p></htmltext>
<tokenext>How Do You Accurately Estimate Programming Time ? I 'm sure there 's a great punch line that goes here , but I just ca n't think of one just now.Opening the floor for suggestions !</tokentext>
<sentencetext>How Do You Accurately Estimate Programming Time?I'm sure there's a great punch line that goes here, but I just can't think of one just now.Opening the floor for suggestions!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078522</id>
	<title>Anonymous Hero</title>
	<author>Anonymous</author>
	<datestamp>1265712300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I have the pefect formula:</p><p>1. Estimate how much time it would take you non stop<br>2. Double that number to compensate for your ego<br>3. Divide it by the number of coffees you drink per day<br>4. Multiply it by the number of managers that talk to you per day<br>5. Multiply it by the number of meetings you have to attend per day<br>6. Double it if you have to use Microsoft software for any part of the project<br>7. Multiply it by the average number of loud conversations around you throughout the day<br>8. Add the size of your inbox in megabytes (1 meg = 1 day)<br>9.<nobr> <wbr></nobr>...<br>10. Profit!</p></htmltext>
<tokenext>I have the pefect formula : 1 .
Estimate how much time it would take you non stop2 .
Double that number to compensate for your ego3 .
Divide it by the number of coffees you drink per day4 .
Multiply it by the number of managers that talk to you per day5 .
Multiply it by the number of meetings you have to attend per day6 .
Double it if you have to use Microsoft software for any part of the project7 .
Multiply it by the average number of loud conversations around you throughout the day8 .
Add the size of your inbox in megabytes ( 1 meg = 1 day ) 9 .
...10. Profit !</tokentext>
<sentencetext>I have the pefect formula:1.
Estimate how much time it would take you non stop2.
Double that number to compensate for your ego3.
Divide it by the number of coffees you drink per day4.
Multiply it by the number of managers that talk to you per day5.
Multiply it by the number of meetings you have to attend per day6.
Double it if you have to use Microsoft software for any part of the project7.
Multiply it by the average number of loud conversations around you throughout the day8.
Add the size of your inbox in megabytes (1 meg = 1 day)9.
...10. Profit!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078078</id>
	<title>Re:W.A.G.</title>
	<author>julesh</author>
	<datestamp>1265710740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>In all seriousness, a friend of mine who's been in the business for a while goes with a refinement of W.A.G.:<br>1. Get a WAG from the developer.<br>2. Apply this formula: Real estimate = WAG * (actual time for previous features / WAG for previous features)<br>3. Tell the developer that his original WAG is what we're using, so he actually hits something pretty close to the real estimate.</i></p><p>Note that taking steps 1 &amp; 2 of this process gives you the estimating technique used by scrum, i.e. the process the guy in the article is advocating...</p></htmltext>
<tokenext>In all seriousness , a friend of mine who 's been in the business for a while goes with a refinement of W.A.G. : 1 .
Get a WAG from the developer.2 .
Apply this formula : Real estimate = WAG * ( actual time for previous features / WAG for previous features ) 3 .
Tell the developer that his original WAG is what we 're using , so he actually hits something pretty close to the real estimate.Note that taking steps 1 &amp; 2 of this process gives you the estimating technique used by scrum , i.e .
the process the guy in the article is advocating.. .</tokentext>
<sentencetext>In all seriousness, a friend of mine who's been in the business for a while goes with a refinement of W.A.G.:1.
Get a WAG from the developer.2.
Apply this formula: Real estimate = WAG * (actual time for previous features / WAG for previous features)3.
Tell the developer that his original WAG is what we're using, so he actually hits something pretty close to the real estimate.Note that taking steps 1 &amp; 2 of this process gives you the estimating technique used by scrum, i.e.
the process the guy in the article is advocating...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076392</id>
	<title>A simple estimation approach</title>
	<author>jays8088</author>
	<datestamp>1265747160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The best approach I've found is to build a domain object model consisting of only the objects that come straight from the problem domain and then multiply the number of objects by a person days to implement an object for the particular implementation technology.

There are some adjustments you can make based on complexity of the UI and developer experience but the basic premise works.

It's sounds like a simplistic approach but it's not because the process of building a good object model and that's a key point, the object model must be well done, this process is really a process of organizing the information you need to build an estimate in a very sophisticated way.

An object model is a way to organize and account for all of the data and behavior of the system and furthermore, to organize the information into reasonable units.  The rules around building a good object model will cause the objects to be of a fairly uniform size in terms of complexity.

What you end up with is a list of discrete groupings of data and behavior with well defined interfaces between them allowing for the fairly simple calculation of an average number of person days per object.</htmltext>
<tokenext>The best approach I 've found is to build a domain object model consisting of only the objects that come straight from the problem domain and then multiply the number of objects by a person days to implement an object for the particular implementation technology .
There are some adjustments you can make based on complexity of the UI and developer experience but the basic premise works .
It 's sounds like a simplistic approach but it 's not because the process of building a good object model and that 's a key point , the object model must be well done , this process is really a process of organizing the information you need to build an estimate in a very sophisticated way .
An object model is a way to organize and account for all of the data and behavior of the system and furthermore , to organize the information into reasonable units .
The rules around building a good object model will cause the objects to be of a fairly uniform size in terms of complexity .
What you end up with is a list of discrete groupings of data and behavior with well defined interfaces between them allowing for the fairly simple calculation of an average number of person days per object .</tokentext>
<sentencetext>The best approach I've found is to build a domain object model consisting of only the objects that come straight from the problem domain and then multiply the number of objects by a person days to implement an object for the particular implementation technology.
There are some adjustments you can make based on complexity of the UI and developer experience but the basic premise works.
It's sounds like a simplistic approach but it's not because the process of building a good object model and that's a key point, the object model must be well done, this process is really a process of organizing the information you need to build an estimate in a very sophisticated way.
An object model is a way to organize and account for all of the data and behavior of the system and furthermore, to organize the information into reasonable units.
The rules around building a good object model will cause the objects to be of a fairly uniform size in terms of complexity.
What you end up with is a list of discrete groupings of data and behavior with well defined interfaces between them allowing for the fairly simple calculation of an average number of person days per object.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076428</id>
	<title>Re:Simply, no software required.</title>
	<author>EatHam</author>
	<datestamp>1265747340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>All you have to do is remember that the first 90\% of the project takes the first 90\% of the time line, and the remaining 10\% of the project takes the other 90\% of time.</htmltext>
<tokenext>All you have to do is remember that the first 90 \ % of the project takes the first 90 \ % of the time line , and the remaining 10 \ % of the project takes the other 90 \ % of time .</tokentext>
<sentencetext>All you have to do is remember that the first 90\% of the project takes the first 90\% of the time line, and the remaining 10\% of the project takes the other 90\% of time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076484</id>
	<title>The expression test</title>
	<author>Anonymous</author>
	<datestamp>1265747580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>At my previous job I used the expression test. I would give the project manager a number, and if he scowled, I would give him another number. When his response was bored indifference, I knew I finally hit the right answer.</p></htmltext>
<tokenext>At my previous job I used the expression test .
I would give the project manager a number , and if he scowled , I would give him another number .
When his response was bored indifference , I knew I finally hit the right answer .</tokentext>
<sentencetext>At my previous job I used the expression test.
I would give the project manager a number, and if he scowled, I would give him another number.
When his response was bored indifference, I knew I finally hit the right answer.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075358</id>
	<title>Change the units and multiply by 2</title>
	<author>Anonymous</author>
	<datestamp>1265743560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you think something will take an hour, change the unit to a day and multiply by 2<br>So<br>1hr=2days<br>1 week=2 months<br>and so on</p></htmltext>
<tokenext>If you think something will take an hour , change the unit to a day and multiply by 2So1hr = 2days1 week = 2 monthsand so on</tokentext>
<sentencetext>If you think something will take an hour, change the unit to a day and multiply by 2So1hr=2days1 week=2 monthsand so on</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080852</id>
	<title>Re:Chop features.</title>
	<author>pnewhook</author>
	<datestamp>1265724960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it.</p></div><p>The point is that if you were able to estimate accurately in the first place, you wouldn't be ever in the situation where you have to decide between all the features that were requested and on-time.</p></div>
	</htmltext>
<tokenext>Estimating accurately is n't so much of an art of estimating accurately , as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it.The point is that if you were able to estimate accurately in the first place , you would n't be ever in the situation where you have to decide between all the features that were requested and on-time .</tokentext>
<sentencetext>Estimating accurately isn't so much of an art of estimating accurately, as it is being able to figure what to chop that still gets the product in on some semblance of being on time and in a way that people like it.The point is that if you were able to estimate accurately in the first place, you wouldn't be ever in the situation where you have to decide between all the features that were requested and on-time.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075354</id>
	<title>Beers as a temporal unit</title>
	<author>mlts</author>
	<datestamp>1265743560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I do know what not to do.  When someone estimates a programming job in number of beers, I get worried.  If someone says that a security patch to an existing application is a one beer job, then I hope for the best, and that regression testing and QA catch anything new that cropped in.</p></htmltext>
<tokenext>I do know what not to do .
When someone estimates a programming job in number of beers , I get worried .
If someone says that a security patch to an existing application is a one beer job , then I hope for the best , and that regression testing and QA catch anything new that cropped in .</tokentext>
<sentencetext>I do know what not to do.
When someone estimates a programming job in number of beers, I get worried.
If someone says that a security patch to an existing application is a one beer job, then I hope for the best, and that regression testing and QA catch anything new that cropped in.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075816</id>
	<title>Re:Simply, no software required.</title>
	<author>computational super</author>
	<datestamp>1265745180000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext>Hofstadter's law: It always takes longer than you expect, even after accounting for Hofstadter's law.</htmltext>
<tokenext>Hofstadter 's law : It always takes longer than you expect , even after accounting for Hofstadter 's law .</tokentext>
<sentencetext>Hofstadter's law: It always takes longer than you expect, even after accounting for Hofstadter's law.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078532</id>
	<title>Dr. Zen replies</title>
	<author>hey!</author>
	<datestamp>1265712360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How do you accurately estimate programming time?</p><p>Answer this question, and you will know The Way: How do you accurately measure programming accomplishment?</p></htmltext>
<tokenext>How do you accurately estimate programming time ? Answer this question , and you will know The Way : How do you accurately measure programming accomplishment ?</tokentext>
<sentencetext>How do you accurately estimate programming time?Answer this question, and you will know The Way: How do you accurately measure programming accomplishment?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898</id>
	<title>Re:W.A.G.</title>
	<author>dkleinsc</author>
	<datestamp>1265745420000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>In all seriousness, a friend of mine who's been in the business for a while goes with a refinement of W.A.G.:<br>1. Get a WAG from the developer.<br>2. Apply this formula: Real estimate = WAG * (actual time for previous features / WAG for previous features)<br>3. Tell the developer that his original WAG is what we're using, so he actually hits something pretty close to the real estimate.</p><p>As a result, management has a pretty good (although not completely perfect) idea of how long something is going to take, based on developer's WAGs.</p></htmltext>
<tokenext>In all seriousness , a friend of mine who 's been in the business for a while goes with a refinement of W.A.G. : 1 .
Get a WAG from the developer.2 .
Apply this formula : Real estimate = WAG * ( actual time for previous features / WAG for previous features ) 3 .
Tell the developer that his original WAG is what we 're using , so he actually hits something pretty close to the real estimate.As a result , management has a pretty good ( although not completely perfect ) idea of how long something is going to take , based on developer 's WAGs .</tokentext>
<sentencetext>In all seriousness, a friend of mine who's been in the business for a while goes with a refinement of W.A.G.:1.
Get a WAG from the developer.2.
Apply this formula: Real estimate = WAG * (actual time for previous features / WAG for previous features)3.
Tell the developer that his original WAG is what we're using, so he actually hits something pretty close to the real estimate.As a result, management has a pretty good (although not completely perfect) idea of how long something is going to take, based on developer's WAGs.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075422</id>
	<title>Miracle Worker!</title>
	<author>mackil</author>
	<datestamp>1265743800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Times every quote by 10! How else will they think you're a miracle worker laddie?</div>
	</htmltext>
<tokenext>Times every quote by 10 !
How else will they think you 're a miracle worker laddie ?</tokentext>
<sentencetext>Times every quote by 10!
How else will they think you're a miracle worker laddie?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075886</id>
	<title>Re:Chop features.</title>
	<author>Anonymous</author>
	<datestamp>1265745420000</datestamp>
	<modclass>Funny</modclass>
	<modscore>0</modscore>
	<htmltext><p>You can create software on time, have good quality, or cheaply. Pick one.</p></htmltext>
<tokenext>You can create software on time , have good quality , or cheaply .
Pick one .</tokentext>
<sentencetext>You can create software on time, have good quality, or cheaply.
Pick one.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076154</id>
	<title>The Formula</title>
	<author>thecabinet</author>
	<datestamp>1265746200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>A coworker provided me this formula, and it's the only thing that works.  Take your normal estimate, let's say one week.  Double the number, that gives you two weeks.  Then, increase the timescale to the next unit, that gives you two months.  That's your estimate.</p><p>1 hour -&gt; 2 weeks<br>2 weeks -&gt; 4 months<br>4 months -&gt; 8 years</p><p>Done!</p></htmltext>
<tokenext>A coworker provided me this formula , and it 's the only thing that works .
Take your normal estimate , let 's say one week .
Double the number , that gives you two weeks .
Then , increase the timescale to the next unit , that gives you two months .
That 's your estimate.1 hour - &gt; 2 weeks2 weeks - &gt; 4 months4 months - &gt; 8 yearsDone !</tokentext>
<sentencetext>A coworker provided me this formula, and it's the only thing that works.
Take your normal estimate, let's say one week.
Double the number, that gives you two weeks.
Then, increase the timescale to the next unit, that gives you two months.
That's your estimate.1 hour -&gt; 2 weeks2 weeks -&gt; 4 months4 months -&gt; 8 yearsDone!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075378</id>
	<title>Multiply by 3 or 8</title>
	<author>khendron</author>
	<datestamp>1265743680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I really don't know why this is as accurate as it always turns out to be, but it really works.</p><p>I look at the specs of what needs to get done, and I do a quick back of the envelope estimates as to how long each feature will take (e.g., feature A: 5 days, feature B: 2 weeks, etc). Then I multiply each estimate by 3 and add it all up. If some sort of hardware interfacing is required, I multiply the estimate by 8.</p><p>My supervisor for my Masters degree taught me this trick, when I was programming a sensor control system for a wind tunnel. I didn't believe him at first, but he turned out to be right.</p></htmltext>
<tokenext>I really do n't know why this is as accurate as it always turns out to be , but it really works.I look at the specs of what needs to get done , and I do a quick back of the envelope estimates as to how long each feature will take ( e.g. , feature A : 5 days , feature B : 2 weeks , etc ) .
Then I multiply each estimate by 3 and add it all up .
If some sort of hardware interfacing is required , I multiply the estimate by 8.My supervisor for my Masters degree taught me this trick , when I was programming a sensor control system for a wind tunnel .
I did n't believe him at first , but he turned out to be right .</tokentext>
<sentencetext>I really don't know why this is as accurate as it always turns out to be, but it really works.I look at the specs of what needs to get done, and I do a quick back of the envelope estimates as to how long each feature will take (e.g., feature A: 5 days, feature B: 2 weeks, etc).
Then I multiply each estimate by 3 and add it all up.
If some sort of hardware interfacing is required, I multiply the estimate by 8.My supervisor for my Masters degree taught me this trick, when I was programming a sensor control system for a wind tunnel.
I didn't believe him at first, but he turned out to be right.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077210</id>
	<title>The Halting Problem</title>
	<author>EllisDees</author>
	<datestamp>1265707140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Isn't estimating the amount of time it will take to complete any non-trivial programming task just another version of the halting problem?</p></htmltext>
<tokenext>Is n't estimating the amount of time it will take to complete any non-trivial programming task just another version of the halting problem ?</tokentext>
<sentencetext>Isn't estimating the amount of time it will take to complete any non-trivial programming task just another version of the halting problem?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075364</id>
	<title>Easy</title>
	<author>Joucifer</author>
	<datestamp>1265743620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Take my initial guess and either multiply by 2 and add a 0.</htmltext>
<tokenext>Take my initial guess and either multiply by 2 and add a 0 .</tokentext>
<sentencetext>Take my initial guess and either multiply by 2 and add a 0.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076330</id>
	<title>Selling horse that doesn't look too good</title>
	<author>micromuncher</author>
	<datestamp>1265746860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Some would recognize this as farmer speak for selling a blind horse, and after RTFM, where refactoring and work and revising guesses, the article called "Unskilled and Unaware" comes to mind.  This article's basic premise is that people who are clueless tend to overestimate their ability.</p><p>In the old days, and with most engineering disciplines, costing is a quantified, factored skill.  It is not an art.  People with a great deal of experience, or whom have access to metrics, can cost building billion dollar chemical plants with reasonable error rates.  It all comes down to experience, or metrics in another form.</p><p>First, you record how long it takes you to do something, and how complex it was, and how much risk there was.  This knowledge can be used and applied to even unrelated projects.  The biggest excuse I hear in software development is that we can't cost this because we haven't done it before.  Bullshit.  Remember design patterns?  Someone has done it before.  And it doesn't take much to figure out that something you are doing is either highly complex (and arguably requiring decomposition), or highly risky, and then cost it appropriately.</p><p>Then for those high risk items, apply a strategy like rapid prototyping, or spiral software (risk based) development practices.</p><p>Bullshit to the quality vs functionality argument too.  The triangle of cost vs quality vs time or function does not take into account any of the elements for succesful project delivery, like experienced management, experienced leads, a positive working environment (read no asshole driven development), and people that actually think management is mo betta than leadership.</p><p>Rant off.</p></htmltext>
<tokenext>Some would recognize this as farmer speak for selling a blind horse , and after RTFM , where refactoring and work and revising guesses , the article called " Unskilled and Unaware " comes to mind .
This article 's basic premise is that people who are clueless tend to overestimate their ability.In the old days , and with most engineering disciplines , costing is a quantified , factored skill .
It is not an art .
People with a great deal of experience , or whom have access to metrics , can cost building billion dollar chemical plants with reasonable error rates .
It all comes down to experience , or metrics in another form.First , you record how long it takes you to do something , and how complex it was , and how much risk there was .
This knowledge can be used and applied to even unrelated projects .
The biggest excuse I hear in software development is that we ca n't cost this because we have n't done it before .
Bullshit. Remember design patterns ?
Someone has done it before .
And it does n't take much to figure out that something you are doing is either highly complex ( and arguably requiring decomposition ) , or highly risky , and then cost it appropriately.Then for those high risk items , apply a strategy like rapid prototyping , or spiral software ( risk based ) development practices.Bullshit to the quality vs functionality argument too .
The triangle of cost vs quality vs time or function does not take into account any of the elements for succesful project delivery , like experienced management , experienced leads , a positive working environment ( read no asshole driven development ) , and people that actually think management is mo betta than leadership.Rant off .</tokentext>
<sentencetext>Some would recognize this as farmer speak for selling a blind horse, and after RTFM, where refactoring and work and revising guesses, the article called "Unskilled and Unaware" comes to mind.
This article's basic premise is that people who are clueless tend to overestimate their ability.In the old days, and with most engineering disciplines, costing is a quantified, factored skill.
It is not an art.
People with a great deal of experience, or whom have access to metrics, can cost building billion dollar chemical plants with reasonable error rates.
It all comes down to experience, or metrics in another form.First, you record how long it takes you to do something, and how complex it was, and how much risk there was.
This knowledge can be used and applied to even unrelated projects.
The biggest excuse I hear in software development is that we can't cost this because we haven't done it before.
Bullshit.  Remember design patterns?
Someone has done it before.
And it doesn't take much to figure out that something you are doing is either highly complex (and arguably requiring decomposition), or highly risky, and then cost it appropriately.Then for those high risk items, apply a strategy like rapid prototyping, or spiral software (risk based) development practices.Bullshit to the quality vs functionality argument too.
The triangle of cost vs quality vs time or function does not take into account any of the elements for succesful project delivery, like experienced management, experienced leads, a positive working environment (read no asshole driven development), and people that actually think management is mo betta than leadership.Rant off.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081340</id>
	<title>Dice and lots of them</title>
	<author>Anonymous</author>
	<datestamp>1265728800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>When ever I am asked for an estimate I pick up some dice and roll them, it does not matter what they say<nobr> <wbr></nobr>... add up the numbers and appends weeks<nobr> <wbr></nobr>... I will have something working by then. It may or may not be what they wanted.</p></htmltext>
<tokenext>When ever I am asked for an estimate I pick up some dice and roll them , it does not matter what they say ... add up the numbers and appends weeks ... I will have something working by then .
It may or may not be what they wanted .</tokentext>
<sentencetext>When ever I am asked for an estimate I pick up some dice and roll them, it does not matter what they say ... add up the numbers and appends weeks ... I will have something working by then.
It may or may not be what they wanted.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075870</id>
	<title>Re:Function Point Analysis and Man Hours</title>
	<author>Anonymous</author>
	<datestamp>1265745300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>So my team has just spent about 6 man years making one very complicated system into a an HA pair of very complicated systems. From a user functional analysis that's one extra function with one big bang. There is no way that we could have gotten from that to 6 man years.</p><p>Scrum all the way baby.</p></htmltext>
<tokenext>So my team has just spent about 6 man years making one very complicated system into a an HA pair of very complicated systems .
From a user functional analysis that 's one extra function with one big bang .
There is no way that we could have gotten from that to 6 man years.Scrum all the way baby .</tokentext>
<sentencetext>So my team has just spent about 6 man years making one very complicated system into a an HA pair of very complicated systems.
From a user functional analysis that's one extra function with one big bang.
There is no way that we could have gotten from that to 6 man years.Scrum all the way baby.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080986</id>
	<title>Accurate is easy...</title>
	<author>Anonymous</author>
	<datestamp>1265725860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Accurate is easy.  Precise is hard.  Accurate AND precise is very hard.  Accurate, precise and completely within expectations is nigh on unheard of...</p></htmltext>
<tokenext>Accurate is easy .
Precise is hard .
Accurate AND precise is very hard .
Accurate , precise and completely within expectations is nigh on unheard of.. .</tokentext>
<sentencetext>Accurate is easy.
Precise is hard.
Accurate AND precise is very hard.
Accurate, precise and completely within expectations is nigh on unheard of...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702</id>
	<title>Re:Simply, no software required.</title>
	<author>Chapter80</author>
	<datestamp>1265744820000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>The method I was taught in school, back in the days when Arthur Andersen existed, and prior to Andersen Consulting or AssVenture (or whatever they're called now), the method that was taught to me was credited to them, and looked like this:</p><p>Estimate how long it will take, if everything goes right.  Call it T1.<br>Estimate the expected time it will take, knowing how some things usually go wrong.  Call it T2.<br>Estimate the worst possible case, if everything goes wrong, and there are lots of unforeseen issues - you are 99\% sure you can get it done within this amount of time.  Call it T3.</p><p>The Weighted average estimate is (T1+(4*T2) + T3)/6</p><p>This yields some very odd T values, but often works out to be a reasonable estimate.  The developers may tell me "If all goes well, it'll take 2 days.  I expect it to be 4 days.  But worst case, it might be 40 days."  And you end up with a 9.6 day estimate.  (which is SIGNIFICANTLY different than the "I expect it to be 4 days".)</p><p>----</p><p>The part I learned from working for a major computer manufacturer was this:</p><p>Take whatever estimate the developers tells you, and tell the client to expect it in double that time (from today).  If the lab tells you they'll have a fix by tomorrow, tell the client it'll be there the next day.  If the lab tells you it'll be ready in three months, tell the customer 6 months.   That way, as time goes by, the estimates become more real, and the variation from the estimate becomes more refined.  And it accounts for the unavoidable time between when the lab releases the work, and when it gets installed at the customer's site.</p><p>If, in January, I was told by the developers that it'd be ready in 2 months, I will tell the customer to expect it in 4 months (May).  If in February, I haven't gotten a revised time-frame, then we still expect it in four months (June).</p><p>Manage expectations, and don't let the customer down (particularly when things are outside my control).</p></htmltext>
<tokenext>The method I was taught in school , back in the days when Arthur Andersen existed , and prior to Andersen Consulting or AssVenture ( or whatever they 're called now ) , the method that was taught to me was credited to them , and looked like this : Estimate how long it will take , if everything goes right .
Call it T1.Estimate the expected time it will take , knowing how some things usually go wrong .
Call it T2.Estimate the worst possible case , if everything goes wrong , and there are lots of unforeseen issues - you are 99 \ % sure you can get it done within this amount of time .
Call it T3.The Weighted average estimate is ( T1 + ( 4 * T2 ) + T3 ) /6This yields some very odd T values , but often works out to be a reasonable estimate .
The developers may tell me " If all goes well , it 'll take 2 days .
I expect it to be 4 days .
But worst case , it might be 40 days .
" And you end up with a 9.6 day estimate .
( which is SIGNIFICANTLY different than the " I expect it to be 4 days " .
) ----The part I learned from working for a major computer manufacturer was this : Take whatever estimate the developers tells you , and tell the client to expect it in double that time ( from today ) .
If the lab tells you they 'll have a fix by tomorrow , tell the client it 'll be there the next day .
If the lab tells you it 'll be ready in three months , tell the customer 6 months .
That way , as time goes by , the estimates become more real , and the variation from the estimate becomes more refined .
And it accounts for the unavoidable time between when the lab releases the work , and when it gets installed at the customer 's site.If , in January , I was told by the developers that it 'd be ready in 2 months , I will tell the customer to expect it in 4 months ( May ) .
If in February , I have n't gotten a revised time-frame , then we still expect it in four months ( June ) .Manage expectations , and do n't let the customer down ( particularly when things are outside my control ) .</tokentext>
<sentencetext>The method I was taught in school, back in the days when Arthur Andersen existed, and prior to Andersen Consulting or AssVenture (or whatever they're called now), the method that was taught to me was credited to them, and looked like this:Estimate how long it will take, if everything goes right.
Call it T1.Estimate the expected time it will take, knowing how some things usually go wrong.
Call it T2.Estimate the worst possible case, if everything goes wrong, and there are lots of unforeseen issues - you are 99\% sure you can get it done within this amount of time.
Call it T3.The Weighted average estimate is (T1+(4*T2) + T3)/6This yields some very odd T values, but often works out to be a reasonable estimate.
The developers may tell me "If all goes well, it'll take 2 days.
I expect it to be 4 days.
But worst case, it might be 40 days.
"  And you end up with a 9.6 day estimate.
(which is SIGNIFICANTLY different than the "I expect it to be 4 days".
)----The part I learned from working for a major computer manufacturer was this:Take whatever estimate the developers tells you, and tell the client to expect it in double that time (from today).
If the lab tells you they'll have a fix by tomorrow, tell the client it'll be there the next day.
If the lab tells you it'll be ready in three months, tell the customer 6 months.
That way, as time goes by, the estimates become more real, and the variation from the estimate becomes more refined.
And it accounts for the unavoidable time between when the lab releases the work, and when it gets installed at the customer's site.If, in January, I was told by the developers that it'd be ready in 2 months, I will tell the customer to expect it in 4 months (May).
If in February, I haven't gotten a revised time-frame, then we still expect it in four months (June).Manage expectations, and don't let the customer down (particularly when things are outside my control).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075928</id>
	<title>Re:It's Easy</title>
	<author>Skapare</author>
	<datestamp>1265745480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>... and double it.</p><p>There, finished it for ya.</p></htmltext>
<tokenext>... and double it.There , finished it for ya .</tokentext>
<sentencetext>... and double it.There, finished it for ya.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076670</id>
	<title>Re:Simply, no software required.</title>
	<author>jellomizer</author>
	<datestamp>1265748300000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>We do it backwards. The boss gives us the timeframe and we make the specs to match it.</p></htmltext>
<tokenext>We do it backwards .
The boss gives us the timeframe and we make the specs to match it .</tokentext>
<sentencetext>We do it backwards.
The boss gives us the timeframe and we make the specs to match it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144</id>
	<title>My Ass</title>
	<author>i\_ate\_god</author>
	<datestamp>1265742960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>I pull numbers out of my ass.</p><p>If I am ahead of schedule, rock on<br>If I am directly on schedule, rock on<br>If I am behind schedule, creatively blame something that is out of my control to begin with, rock on</p></htmltext>
<tokenext>I pull numbers out of my ass.If I am ahead of schedule , rock onIf I am directly on schedule , rock onIf I am behind schedule , creatively blame something that is out of my control to begin with , rock on</tokentext>
<sentencetext>I pull numbers out of my ass.If I am ahead of schedule, rock onIf I am directly on schedule, rock onIf I am behind schedule, creatively blame something that is out of my control to begin with, rock on</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076922</id>
	<title>Re:It's Easy</title>
	<author>Anonymous</author>
	<datestamp>1265706060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>I just ask my manager how long he's already told the client it's going to take.</p></div><p>You forgot the part where you then laugh all the way out of his office.</p></div>
	</htmltext>
<tokenext>I just ask my manager how long he 's already told the client it 's going to take.You forgot the part where you then laugh all the way out of his office .</tokentext>
<sentencetext>I just ask my manager how long he's already told the client it's going to take.You forgot the part where you then laugh all the way out of his office.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075292</id>
	<title>Why bother?</title>
	<author>lwriemen</author>
	<datestamp>1265743440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>... if management is just going to come back and say, "Well, I told the customer it would be done by "</p><p>Seriously though, you might want to read, Software Engineering Economics by Barry Boehm. Some of the examples of work products might be outdated, but the concepts are still valid and useful.</p></htmltext>
<tokenext>... if management is just going to come back and say , " Well , I told the customer it would be done by " Seriously though , you might want to read , Software Engineering Economics by Barry Boehm .
Some of the examples of work products might be outdated , but the concepts are still valid and useful .</tokentext>
<sentencetext>... if management is just going to come back and say, "Well, I told the customer it would be done by "Seriously though, you might want to read, Software Engineering Economics by Barry Boehm.
Some of the examples of work products might be outdated, but the concepts are still valid and useful.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080480</id>
	<title>The Canadian way...</title>
	<author>Anonymous</author>
	<datestamp>1265722380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Double it and add thirty.</p></htmltext>
<tokenext>Double it and add thirty .</tokentext>
<sentencetext>Double it and add thirty.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075726</id>
	<title>Easy...</title>
	<author>ArcadeNut</author>
	<datestamp>1265744880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I do the project first, then give them the estimate of how long it will take.   For some reason, projects still take longer then estimated...</p></htmltext>
<tokenext>I do the project first , then give them the estimate of how long it will take .
For some reason , projects still take longer then estimated.. .</tokentext>
<sentencetext>I do the project first, then give them the estimate of how long it will take.
For some reason, projects still take longer then estimated...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076350</id>
	<title>We need good cost estimation books in software</title>
	<author>dacut</author>
	<datestamp>1265746920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The differences in the quality and content of cost estimation handbooks for software and civil engineering disciplines are astounding.  It's possible to take a detailed description of a building and come up with an accurate cost estimate; the books describe how much the material costs and the labor and equipment required to install it.  Software engineering cost estimation books, on the other hand, can be distilled down to: "Using a process for cost estimation is good!" and "Use the result from the last time you built it".</p><p>For instance, compare the descriptions between these books.  Look at the specifics given in the construction estimator vs. the fluff in the software estimator -- and keep in mind the latter was written by Steve McConnell, a well respected author in this field:
</p><ul> <li> <a href="http://www.amazon.com/Estimation-Structures-Commercial-Buildings-Surveying/dp/033358225X" title="amazon.com"> <i>Cost Estimation of Structures in Commercial Buildings</i> </a> [amazon.com]: "A broad range of commercial building types is considered, from five to 50 storeys in height, and the effects on quantities of the varying design parameters, such as column grid size, number of storeys, location of structural components, arrangement of beams, grades of concrete, and so on, are described and illustrated by charts."</li><li> <a href="http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351" title="amazon.com"> <i>Software Estimation: Demystifying the Black Art</i> </a> [amazon.com]: "Software Estimation focuses on the art of software estimation and provides a proven set of procedures and heuristics that software developers, technical leads, and project managers can apply to their projects. Instead of arcane treatises and rigid modeling techniques, award-winning author Steve McConnell gives practical guidance to help organizations achieve basic estimation proficiency and lay the groundwork to continue improving project cost estimates."</li></ul><p>
Granted, a handful of software is sufficiently bleeding edge that it's not possible to find and document past experience.  But surely we've deployed database schemas, created servlets, written session handling code, etc., often enough to start documenting the typical tasks involved and how long they took.</p></htmltext>
<tokenext>The differences in the quality and content of cost estimation handbooks for software and civil engineering disciplines are astounding .
It 's possible to take a detailed description of a building and come up with an accurate cost estimate ; the books describe how much the material costs and the labor and equipment required to install it .
Software engineering cost estimation books , on the other hand , can be distilled down to : " Using a process for cost estimation is good !
" and " Use the result from the last time you built it " .For instance , compare the descriptions between these books .
Look at the specifics given in the construction estimator vs. the fluff in the software estimator -- and keep in mind the latter was written by Steve McConnell , a well respected author in this field : Cost Estimation of Structures in Commercial Buildings [ amazon.com ] : " A broad range of commercial building types is considered , from five to 50 storeys in height , and the effects on quantities of the varying design parameters , such as column grid size , number of storeys , location of structural components , arrangement of beams , grades of concrete , and so on , are described and illustrated by charts .
" Software Estimation : Demystifying the Black Art [ amazon.com ] : " Software Estimation focuses on the art of software estimation and provides a proven set of procedures and heuristics that software developers , technical leads , and project managers can apply to their projects .
Instead of arcane treatises and rigid modeling techniques , award-winning author Steve McConnell gives practical guidance to help organizations achieve basic estimation proficiency and lay the groundwork to continue improving project cost estimates .
" Granted , a handful of software is sufficiently bleeding edge that it 's not possible to find and document past experience .
But surely we 've deployed database schemas , created servlets , written session handling code , etc. , often enough to start documenting the typical tasks involved and how long they took .</tokentext>
<sentencetext>The differences in the quality and content of cost estimation handbooks for software and civil engineering disciplines are astounding.
It's possible to take a detailed description of a building and come up with an accurate cost estimate; the books describe how much the material costs and the labor and equipment required to install it.
Software engineering cost estimation books, on the other hand, can be distilled down to: "Using a process for cost estimation is good!
" and "Use the result from the last time you built it".For instance, compare the descriptions between these books.
Look at the specifics given in the construction estimator vs. the fluff in the software estimator -- and keep in mind the latter was written by Steve McConnell, a well respected author in this field:
   Cost Estimation of Structures in Commercial Buildings  [amazon.com]: "A broad range of commercial building types is considered, from five to 50 storeys in height, and the effects on quantities of the varying design parameters, such as column grid size, number of storeys, location of structural components, arrangement of beams, grades of concrete, and so on, are described and illustrated by charts.
"  Software Estimation: Demystifying the Black Art  [amazon.com]: "Software Estimation focuses on the art of software estimation and provides a proven set of procedures and heuristics that software developers, technical leads, and project managers can apply to their projects.
Instead of arcane treatises and rigid modeling techniques, award-winning author Steve McConnell gives practical guidance to help organizations achieve basic estimation proficiency and lay the groundwork to continue improving project cost estimates.
"
Granted, a handful of software is sufficiently bleeding edge that it's not possible to find and document past experience.
But surely we've deployed database schemas, created servlets, written session handling code, etc., often enough to start documenting the typical tasks involved and how long they took.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076600</id>
	<title>Use Historical Data</title>
	<author>mcshicks</author>
	<datestamp>1265748000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you just keep track of how long features take and who's working on them (like a bug/feature tracking system), a seat of the pants estimate based on complexity (i.e. this feature is 1/2 as complex, twice as complex) times the previous baseline data is surprisingly accurate and in general much better than if people actually try and figure out based on first principles.  Basically people just ignore the base rate historical data for how long sw development tasks take, or don't know it.  The other thing to avoid is telling someone a deadline because you will immediately induce an error based on the anchoring effect.  Once you have a historical performance based estimate, then use that baseline (or anchor) to figure out what is practical for the project in question.

Note: You have to keep track of things for 2-3 years to start before this works, which is why I suspect most people don't do it.</htmltext>
<tokenext>If you just keep track of how long features take and who 's working on them ( like a bug/feature tracking system ) , a seat of the pants estimate based on complexity ( i.e .
this feature is 1/2 as complex , twice as complex ) times the previous baseline data is surprisingly accurate and in general much better than if people actually try and figure out based on first principles .
Basically people just ignore the base rate historical data for how long sw development tasks take , or do n't know it .
The other thing to avoid is telling someone a deadline because you will immediately induce an error based on the anchoring effect .
Once you have a historical performance based estimate , then use that baseline ( or anchor ) to figure out what is practical for the project in question .
Note : You have to keep track of things for 2-3 years to start before this works , which is why I suspect most people do n't do it .</tokentext>
<sentencetext>If you just keep track of how long features take and who's working on them (like a bug/feature tracking system), a seat of the pants estimate based on complexity (i.e.
this feature is 1/2 as complex, twice as complex) times the previous baseline data is surprisingly accurate and in general much better than if people actually try and figure out based on first principles.
Basically people just ignore the base rate historical data for how long sw development tasks take, or don't know it.
The other thing to avoid is telling someone a deadline because you will immediately induce an error based on the anchoring effect.
Once you have a historical performance based estimate, then use that baseline (or anchor) to figure out what is practical for the project in question.
Note: You have to keep track of things for 2-3 years to start before this works, which is why I suspect most people don't do it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080254</id>
	<title>Re:Well, I *used* to use the entrails of goats...</title>
	<author>Anonymous</author>
	<datestamp>1265720880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You won't say that when we throw boiling hot tea at you.<br>Make mine Yerba Mate.</p></htmltext>
<tokenext>You wo n't say that when we throw boiling hot tea at you.Make mine Yerba Mate .</tokentext>
<sentencetext>You won't say that when we throw boiling hot tea at you.Make mine Yerba Mate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076680</id>
	<title>Re:Uhh, Scrum is not an estimation method</title>
	<author>Anonymous</author>
	<datestamp>1265748360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This isn't entirely accurate.  While Scrum doesn't mandate any one type of estimation process, a fairly common methodology used by Scrum (and other Agile processes) is to use Story Points to estimate how long it takes to complete a feature/story (as described in the tiny blurb by Suvro Upadhyaya that started this thread).  Once you add up all of the Story Points that make up your project, and know how many average Story Points are completed per Scrum iteration, you come up with a surprisingly accurate estimate for time to complete a project.  After a few iterations, you can also factor in the rate of scope creep to get even more on target (i.e., if I notice the product owner adding an average of 10 more story points of feature per iteration, and I can complete and average of 40 story points per Scrum iteration, I know that my project will take 25\% longer than currently specified by total feature story points).  Scrum is a framework that is fairly well suited for adding on other Agile methods to get estimates that often correlate well with actual time to delivery.  Arguably more accurate than most BDUF Waterfall projects.</p></htmltext>
<tokenext>This is n't entirely accurate .
While Scrum does n't mandate any one type of estimation process , a fairly common methodology used by Scrum ( and other Agile processes ) is to use Story Points to estimate how long it takes to complete a feature/story ( as described in the tiny blurb by Suvro Upadhyaya that started this thread ) .
Once you add up all of the Story Points that make up your project , and know how many average Story Points are completed per Scrum iteration , you come up with a surprisingly accurate estimate for time to complete a project .
After a few iterations , you can also factor in the rate of scope creep to get even more on target ( i.e. , if I notice the product owner adding an average of 10 more story points of feature per iteration , and I can complete and average of 40 story points per Scrum iteration , I know that my project will take 25 \ % longer than currently specified by total feature story points ) .
Scrum is a framework that is fairly well suited for adding on other Agile methods to get estimates that often correlate well with actual time to delivery .
Arguably more accurate than most BDUF Waterfall projects .</tokentext>
<sentencetext>This isn't entirely accurate.
While Scrum doesn't mandate any one type of estimation process, a fairly common methodology used by Scrum (and other Agile processes) is to use Story Points to estimate how long it takes to complete a feature/story (as described in the tiny blurb by Suvro Upadhyaya that started this thread).
Once you add up all of the Story Points that make up your project, and know how many average Story Points are completed per Scrum iteration, you come up with a surprisingly accurate estimate for time to complete a project.
After a few iterations, you can also factor in the rate of scope creep to get even more on target (i.e., if I notice the product owner adding an average of 10 more story points of feature per iteration, and I can complete and average of 40 story points per Scrum iteration, I know that my project will take 25\% longer than currently specified by total feature story points).
Scrum is a framework that is fairly well suited for adding on other Agile methods to get estimates that often correlate well with actual time to delivery.
Arguably more accurate than most BDUF Waterfall projects.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075220</id>
	<title>.NET</title>
	<author>cosm</author>
	<datestamp>1265743200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>( [Average copypasta time] x [Desired Lines of Code] / [Averages Lines Per Chunk] ) x K

K = Constant of Desired Inneficiency</htmltext>
<tokenext>( [ Average copypasta time ] x [ Desired Lines of Code ] / [ Averages Lines Per Chunk ] ) x K K = Constant of Desired Inneficiency</tokentext>
<sentencetext>( [Average copypasta time] x [Desired Lines of Code] / [Averages Lines Per Chunk] ) x K

K = Constant of Desired Inneficiency</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076932</id>
	<title>use statistical analysis</title>
	<author>anomalous cohort</author>
	<datestamp>1265706060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Estimating requirements is very important and software engineers should attempt to improve their estimating skills. Overly optimistic estimates is the <a href="http://www.dynamicalsoftware.com/news/?p=9" title="dynamicalsoftware.com">second highest cause</a> [dynamicalsoftware.com] for runaway projects. Consider a statistical approach such as <a href="http://www.qpmg.com/fp-intro.htm" title="qpmg.com">FPA</a> [qpmg.com] whose accuracy improves over time. Having to double your estimate is just a symptom of poor change management and other <a href="http://www.dynamicalsoftware.com/cr/prod/faq.html#cmm" title="dynamicalsoftware.com">process immaturities</a> [dynamicalsoftware.com]. If you get push back on FPA because of its complexity, then consider rolling your own more simplified approach.</htmltext>
<tokenext>Estimating requirements is very important and software engineers should attempt to improve their estimating skills .
Overly optimistic estimates is the second highest cause [ dynamicalsoftware.com ] for runaway projects .
Consider a statistical approach such as FPA [ qpmg.com ] whose accuracy improves over time .
Having to double your estimate is just a symptom of poor change management and other process immaturities [ dynamicalsoftware.com ] .
If you get push back on FPA because of its complexity , then consider rolling your own more simplified approach .</tokentext>
<sentencetext>Estimating requirements is very important and software engineers should attempt to improve their estimating skills.
Overly optimistic estimates is the second highest cause [dynamicalsoftware.com] for runaway projects.
Consider a statistical approach such as FPA [qpmg.com] whose accuracy improves over time.
Having to double your estimate is just a symptom of poor change management and other process immaturities [dynamicalsoftware.com].
If you get push back on FPA because of its complexity, then consider rolling your own more simplified approach.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083088</id>
	<title>At least it's official.</title>
	<author>cavebison</author>
	<datestamp>1265015760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><a href="http://en.wikipedia.org/wiki/Hofstadter's\_law" title="wikipedia.org" rel="nofollow">Hofstadter's Law</a> [wikipedia.org]</htmltext>
<tokenext>Hofstadter 's Law [ wikipedia.org ]</tokentext>
<sentencetext>Hofstadter's Law [wikipedia.org]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076762</id>
	<title>Re:Uhh, Scrum is not an estimation method</title>
	<author>azgard</author>
	<datestamp>1265748660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I see - so you write it first, and then use the amount it took as an estimate! How clever!</p></htmltext>
<tokenext>I see - so you write it first , and then use the amount it took as an estimate !
How clever !</tokentext>
<sentencetext>I see - so you write it first, and then use the amount it took as an estimate!
How clever!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083542</id>
	<title>Re:Simply, no software required.</title>
	<author>Anonymous</author>
	<datestamp>1265021700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you think of the last time you worked on a project that came in on time, with the features envisaged and without pulling crazy hours and your hair out near the end of the cycle, then raise your hand. Please tell me how you estimate your programming time!</p><p>In the end it is *always* guesswork. You are being asked to predict the future, and that is impossible, unless of course you can be given a flawless environment in a bubble to avoid any broken builds, forced code merges, network issues, so that you can only have 1 risk, yourself.</p><p>I would follow the aforementioned Scotty principle, but that in effect is saying "I have no idea, but hey, it could never take that long could it!?"</p><p>Writing software is a creative process in a often fluctuating chaotic environment, so maybe saying "I have no idea boss, but I will commit to giving you 4 solid hours of programming time each day over the term of the project, if you will commit to managing the risks to my development effort over the same period. If we both live up to it, it will be done as fast as humanly possible"<br>
&nbsp;</p></htmltext>
<tokenext>If you think of the last time you worked on a project that came in on time , with the features envisaged and without pulling crazy hours and your hair out near the end of the cycle , then raise your hand .
Please tell me how you estimate your programming time ! In the end it is * always * guesswork .
You are being asked to predict the future , and that is impossible , unless of course you can be given a flawless environment in a bubble to avoid any broken builds , forced code merges , network issues , so that you can only have 1 risk , yourself.I would follow the aforementioned Scotty principle , but that in effect is saying " I have no idea , but hey , it could never take that long could it ! ?
" Writing software is a creative process in a often fluctuating chaotic environment , so maybe saying " I have no idea boss , but I will commit to giving you 4 solid hours of programming time each day over the term of the project , if you will commit to managing the risks to my development effort over the same period .
If we both live up to it , it will be done as fast as humanly possible "  </tokentext>
<sentencetext>If you think of the last time you worked on a project that came in on time, with the features envisaged and without pulling crazy hours and your hair out near the end of the cycle, then raise your hand.
Please tell me how you estimate your programming time!In the end it is *always* guesswork.
You are being asked to predict the future, and that is impossible, unless of course you can be given a flawless environment in a bubble to avoid any broken builds, forced code merges, network issues, so that you can only have 1 risk, yourself.I would follow the aforementioned Scotty principle, but that in effect is saying "I have no idea, but hey, it could never take that long could it!?
"Writing software is a creative process in a often fluctuating chaotic environment, so maybe saying "I have no idea boss, but I will commit to giving you 4 solid hours of programming time each day over the term of the project, if you will commit to managing the risks to my development effort over the same period.
If we both live up to it, it will be done as fast as humanly possible"
 </sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31087420</id>
	<title>Easy formula for great success!</title>
	<author>soccerisgod</author>
	<datestamp>1265047500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My formula:</p><p>Te * 2 + n</p><p>Where Te is the time I think it  takes after reading the specifications, and n is the "nose factor". Usually works pretty well.</p></htmltext>
<tokenext>My formula : Te * 2 + nWhere Te is the time I think it takes after reading the specifications , and n is the " nose factor " .
Usually works pretty well .</tokentext>
<sentencetext>My formula:Te * 2 + nWhere Te is the time I think it  takes after reading the specifications, and n is the "nose factor".
Usually works pretty well.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077584</id>
	<title>COCOMO II</title>
	<author>lonelytrail</author>
	<datestamp>1265708700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>NASA recommends (almost requires) the COCOMO model.
<a href="http://en.wikipedia.org/wiki/COCOMO" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/COCOMO</a> [wikipedia.org]

I think the COCOMO model is used by the Software Engineering Institute (SEI) at Carnegie Mellon University as part of the Capability Maturity Model (CMM).

As said in MANY of these posts, proper specifications/requirements are needed to estimate anything.

My company uses it exclusively and we have been proven quite accurate over the course of many projects.

<a href="http://sunset.usc.edu/csse/research/COCOMOII/cocomo\_main.html" title="usc.edu" rel="nofollow">http://sunset.usc.edu/csse/research/COCOMOII/cocomo\_main.html</a> [usc.edu]</htmltext>
<tokenext>NASA recommends ( almost requires ) the COCOMO model .
http : //en.wikipedia.org/wiki/COCOMO [ wikipedia.org ] I think the COCOMO model is used by the Software Engineering Institute ( SEI ) at Carnegie Mellon University as part of the Capability Maturity Model ( CMM ) .
As said in MANY of these posts , proper specifications/requirements are needed to estimate anything .
My company uses it exclusively and we have been proven quite accurate over the course of many projects .
http : //sunset.usc.edu/csse/research/COCOMOII/cocomo \ _main.html [ usc.edu ]</tokentext>
<sentencetext>NASA recommends (almost requires) the COCOMO model.
http://en.wikipedia.org/wiki/COCOMO [wikipedia.org]

I think the COCOMO model is used by the Software Engineering Institute (SEI) at Carnegie Mellon University as part of the Capability Maturity Model (CMM).
As said in MANY of these posts, proper specifications/requirements are needed to estimate anything.
My company uses it exclusively and we have been proven quite accurate over the course of many projects.
http://sunset.usc.edu/csse/research/COCOMOII/cocomo\_main.html [usc.edu]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081292</id>
	<title>Re:And puts a two week horizon on your creativity</title>
	<author>lewiscr</author>
	<datestamp>1265728320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't think that an hour of planning dampens my creativity.  I find it helps.  The 2 week deadlines aren't deadlines, they're a scheduling convience.  I don't have complete the whole task, or even develop a whole vision of the task, in a single 2 week chunk.  But you should be able to point to some progress that you have made in that time.</p><p>I like to start out big vague projects with a sprint just to write a proof on concept.  That gives me an idea where to start, then I take it 2 weeks at a time, making ideas concrete.</p><p>The reason Scrum works is that it makes you break down big (and hard to estimate) tasks into small tasks that can be reliably estimated.  Scrum does not say you must use a 2 week sprint, they just recommend it as a place to start.  If you need a longer sprint, use a longer sprint.  Just make sure you don't make the sprint so long that you're tempted to write big stories that cannot be reliably estimated.</p></htmltext>
<tokenext>I do n't think that an hour of planning dampens my creativity .
I find it helps .
The 2 week deadlines are n't deadlines , they 're a scheduling convience .
I do n't have complete the whole task , or even develop a whole vision of the task , in a single 2 week chunk .
But you should be able to point to some progress that you have made in that time.I like to start out big vague projects with a sprint just to write a proof on concept .
That gives me an idea where to start , then I take it 2 weeks at a time , making ideas concrete.The reason Scrum works is that it makes you break down big ( and hard to estimate ) tasks into small tasks that can be reliably estimated .
Scrum does not say you must use a 2 week sprint , they just recommend it as a place to start .
If you need a longer sprint , use a longer sprint .
Just make sure you do n't make the sprint so long that you 're tempted to write big stories that can not be reliably estimated .</tokentext>
<sentencetext>I don't think that an hour of planning dampens my creativity.
I find it helps.
The 2 week deadlines aren't deadlines, they're a scheduling convience.
I don't have complete the whole task, or even develop a whole vision of the task, in a single 2 week chunk.
But you should be able to point to some progress that you have made in that time.I like to start out big vague projects with a sprint just to write a proof on concept.
That gives me an idea where to start, then I take it 2 weeks at a time, making ideas concrete.The reason Scrum works is that it makes you break down big (and hard to estimate) tasks into small tasks that can be reliably estimated.
Scrum does not say you must use a 2 week sprint, they just recommend it as a place to start.
If you need a longer sprint, use a longer sprint.
Just make sure you don't make the sprint so long that you're tempted to write big stories that cannot be reliably estimated.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077954</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075062</id>
	<title>Programming time?</title>
	<author>Spyware23</author>
	<datestamp>1265742780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"when it's done"</p></htmltext>
<tokenext>" when it 's done "</tokentext>
<sentencetext>"when it's done"</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075868</id>
	<title>Bill per hour</title>
	<author>Anonymous</author>
	<datestamp>1265745300000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>I almost always bill per hour.  Most of the time my clients give me an email or verbal idea of what they want over the phone.  I try to get as many questions answered as I can without wasting time.
<br> <br>
I then take the task and break it down into as many bite-sized subtasks as I can.  This does a couple things:
<br> <br>
1. It shows where I have unanswered questions<br>
2. It's easier to estimate "add 3 new roles to management interface" and "add cart admin role to admin interface" than it is to estimate "make admin area more secure".
<br> <br>
Once that's complete (for this round), I put all those line items into a spreadsheet.  I then estimate the number of hours it takes in a reasonable best, and worst, case scenario.  So "add cart admin rold to admin interface" might be 3-4.5 hours.
<br> <br>
I then add all those up, and add about 33\% for planning, and 33\% for testing/deployment.  Sometimes it can be more or less depending on my experience with the client.  I then give that spreadsheet to the client and say, I'm pretty confident your price will be within this range.  The areas that have high variability are the areas we need to work on nailing down further.  I will bill you actual time taken, but I'll let you know if the range is nearing the top number so we can re-evaluate.  That almost never happens, or I should say that when it does, it's almost always because the client has asked for more work, and they understand this.
<br> <br>
Customers almost always appreciate this approach and find it helpful.  Most of the time I only do this for the first project for a client, and then they just ask me to give them a verbal idea of how hard the project will be since they trust me.
<br> <br>
For the very occasional fixed bid work I do, I just take the high number, pad it a bit, and double my hourly rate.  I tell customers ahead of time though that they are better off hiring me hourly in almost every circumstance.  I usually don't spend a lot of time on fixed bid work because, frankly, I usually don't want it.</htmltext>
<tokenext>I almost always bill per hour .
Most of the time my clients give me an email or verbal idea of what they want over the phone .
I try to get as many questions answered as I can without wasting time .
I then take the task and break it down into as many bite-sized subtasks as I can .
This does a couple things : 1 .
It shows where I have unanswered questions 2 .
It 's easier to estimate " add 3 new roles to management interface " and " add cart admin role to admin interface " than it is to estimate " make admin area more secure " .
Once that 's complete ( for this round ) , I put all those line items into a spreadsheet .
I then estimate the number of hours it takes in a reasonable best , and worst , case scenario .
So " add cart admin rold to admin interface " might be 3-4.5 hours .
I then add all those up , and add about 33 \ % for planning , and 33 \ % for testing/deployment .
Sometimes it can be more or less depending on my experience with the client .
I then give that spreadsheet to the client and say , I 'm pretty confident your price will be within this range .
The areas that have high variability are the areas we need to work on nailing down further .
I will bill you actual time taken , but I 'll let you know if the range is nearing the top number so we can re-evaluate .
That almost never happens , or I should say that when it does , it 's almost always because the client has asked for more work , and they understand this .
Customers almost always appreciate this approach and find it helpful .
Most of the time I only do this for the first project for a client , and then they just ask me to give them a verbal idea of how hard the project will be since they trust me .
For the very occasional fixed bid work I do , I just take the high number , pad it a bit , and double my hourly rate .
I tell customers ahead of time though that they are better off hiring me hourly in almost every circumstance .
I usually do n't spend a lot of time on fixed bid work because , frankly , I usually do n't want it .</tokentext>
<sentencetext>I almost always bill per hour.
Most of the time my clients give me an email or verbal idea of what they want over the phone.
I try to get as many questions answered as I can without wasting time.
I then take the task and break it down into as many bite-sized subtasks as I can.
This does a couple things:
 
1.
It shows where I have unanswered questions
2.
It's easier to estimate "add 3 new roles to management interface" and "add cart admin role to admin interface" than it is to estimate "make admin area more secure".
Once that's complete (for this round), I put all those line items into a spreadsheet.
I then estimate the number of hours it takes in a reasonable best, and worst, case scenario.
So "add cart admin rold to admin interface" might be 3-4.5 hours.
I then add all those up, and add about 33\% for planning, and 33\% for testing/deployment.
Sometimes it can be more or less depending on my experience with the client.
I then give that spreadsheet to the client and say, I'm pretty confident your price will be within this range.
The areas that have high variability are the areas we need to work on nailing down further.
I will bill you actual time taken, but I'll let you know if the range is nearing the top number so we can re-evaluate.
That almost never happens, or I should say that when it does, it's almost always because the client has asked for more work, and they understand this.
Customers almost always appreciate this approach and find it helpful.
Most of the time I only do this for the first project for a client, and then they just ask me to give them a verbal idea of how hard the project will be since they trust me.
For the very occasional fixed bid work I do, I just take the high number, pad it a bit, and double my hourly rate.
I tell customers ahead of time though that they are better off hiring me hourly in almost every circumstance.
I usually don't spend a lot of time on fixed bid work because, frankly, I usually don't want it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078892</id>
	<title>Re:Simply, no software required.</title>
	<author>Anonymous</author>
	<datestamp>1265713920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I multiply by three. Guesstimating 1 time period, I'll announce 3 time periods.</p></htmltext>
<tokenext>I multiply by three .
Guesstimating 1 time period , I 'll announce 3 time periods .</tokentext>
<sentencetext>I multiply by three.
Guesstimating 1 time period, I'll announce 3 time periods.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075086</id>
	<title>The WAG Methodology</title>
	<author>Anonymous</author>
	<datestamp>1265742840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><nobr> <wbr></nobr>... aka "Wild Ass Guess."<nobr> <wbr></nobr>:-)</p></htmltext>
<tokenext>... aka " Wild Ass Guess .
" : - )</tokentext>
<sentencetext> ... aka "Wild Ass Guess.
" :-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076260</id>
	<title>Average + fudge \%</title>
	<author>pacoder</author>
	<datestamp>1265746620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I take the average of my 'best case' and 'worst case' estimates then add 30\%. Work out very well typically, what I'm really shooting for is to come in at a bit under the final estimate. Making sure that business understands that scope changes affect the estimate and documenting / communicating scope changes when they come up is critical.</htmltext>
<tokenext>I take the average of my 'best case ' and 'worst case ' estimates then add 30 \ % .
Work out very well typically , what I 'm really shooting for is to come in at a bit under the final estimate .
Making sure that business understands that scope changes affect the estimate and documenting / communicating scope changes when they come up is critical .</tokentext>
<sentencetext>I take the average of my 'best case' and 'worst case' estimates then add 30\%.
Work out very well typically, what I'm really shooting for is to come in at a bit under the final estimate.
Making sure that business understands that scope changes affect the estimate and documenting / communicating scope changes when they come up is critical.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075484</id>
	<title>The Mythical Man Month may provide some insight</title>
	<author>ma11achy</author>
	<datestamp>1265744040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I would advise reading "The Mythical Man Month" by Frederick P. Brooks. It is considered "The Bible" of the human elements of Software Engineering by many. By "human elements" I mean to include your request for information on estimating project time.</p><p>Here is a quote from page 20 of the book based on one portion of a software engineering project:</p><p>"In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose. Many of these were on schedule until and except in system testing." (Brooks, 1995)</p><p>Citation:</p><p>Brooks, Frederick P. (1995) The Mythical Man-Month: Essays on Software Engineering: Addison-Wesley Professional, p. 20</p></div>
	</htmltext>
<tokenext>I would advise reading " The Mythical Man Month " by Frederick P. Brooks. It is considered " The Bible " of the human elements of Software Engineering by many .
By " human elements " I mean to include your request for information on estimating project time.Here is a quote from page 20 of the book based on one portion of a software engineering project : " In examining conventionally scheduled projects , I have found that few allowed one-half of the projected schedule for testing , but that most did indeed spend half of the actual schedule for that purpose .
Many of these were on schedule until and except in system testing .
" ( Brooks , 1995 ) Citation : Brooks , Frederick P. ( 1995 ) The Mythical Man-Month : Essays on Software Engineering : Addison-Wesley Professional , p. 20</tokentext>
<sentencetext>I would advise reading "The Mythical Man Month" by Frederick P. Brooks. It is considered "The Bible" of the human elements of Software Engineering by many.
By "human elements" I mean to include your request for information on estimating project time.Here is a quote from page 20 of the book based on one portion of a software engineering project:"In examining conventionally scheduled projects, I have found that few allowed one-half of the projected schedule for testing, but that most did indeed spend half of the actual schedule for that purpose.
Many of these were on schedule until and except in system testing.
" (Brooks, 1995)Citation:Brooks, Frederick P. (1995) The Mythical Man-Month: Essays on Software Engineering: Addison-Wesley Professional, p. 20
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079894</id>
	<title>Re:It's Easy</title>
	<author>Anonymous</author>
	<datestamp>1265718480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>I just ask my manager how long he's already told the client it's going to take.</p></div><p>And they said "It's simple! All you have to do is..."</p><p>At which point, it's time to start sending out resume's.</p></div>
	</htmltext>
<tokenext>I just ask my manager how long he 's already told the client it 's going to take.And they said " It 's simple !
All you have to do is... " At which point , it 's time to start sending out resume 's .</tokentext>
<sentencetext>I just ask my manager how long he's already told the client it's going to take.And they said "It's simple!
All you have to do is..."At which point, it's time to start sending out resume's.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075470</id>
	<title>My usual approach</title>
	<author>jockeys</author>
	<datestamp>1265743980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>is to sit down and figure out how long it should take under ideal circumstances (no scope creep, no major fuckups, no outside holdups) and triple it.

<br> <br>That sounds awful, but it's almost always pretty close.  Something always goes wrong, there is always some amount of re-work and there is always some scope creep.</htmltext>
<tokenext>is to sit down and figure out how long it should take under ideal circumstances ( no scope creep , no major fuckups , no outside holdups ) and triple it .
That sounds awful , but it 's almost always pretty close .
Something always goes wrong , there is always some amount of re-work and there is always some scope creep .</tokentext>
<sentencetext>is to sit down and figure out how long it should take under ideal circumstances (no scope creep, no major fuckups, no outside holdups) and triple it.
That sounds awful, but it's almost always pretty close.
Something always goes wrong, there is always some amount of re-work and there is always some scope creep.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076136</id>
	<title>FogBugz</title>
	<author>Anonymous</author>
	<datestamp>1265746140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Anyone used FogBugz' "Evidence Based Scheduling"?</p></htmltext>
<tokenext>Anyone used FogBugz ' " Evidence Based Scheduling " ?</tokentext>
<sentencetext>Anyone used FogBugz' "Evidence Based Scheduling"?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075338</id>
	<title>Quid pro quo</title>
	<author>HangingChad</author>
	<datestamp>1265743560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p> <i>The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization.</i>
</p><p>My time estimates will be as accurate as your specs.  You stick to the specs, I'll stick to the estimate.</p></htmltext>
<tokenext>The programmers ' experience , domain knowledge , and speed vs. quality all come into play , and it is highly dependent upon the culture of the team/organization .
My time estimates will be as accurate as your specs .
You stick to the specs , I 'll stick to the estimate .</tokentext>
<sentencetext> The programmers' experience, domain knowledge, and speed vs. quality all come into play, and it is highly dependent upon the culture of the team/organization.
My time estimates will be as accurate as your specs.
You stick to the specs, I'll stick to the estimate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080430</id>
	<title>Double original estimate and add 30</title>
	<author>presidenteloco</author>
	<datestamp>1265722080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>(Or more precisely multiply by 9/5 and add 32).</p><p>This is often enough contingency to handle the curve ball requirements changes that<br>management and customers will inevitably throw at you throughout the development period.</p><p>It may not be enough to cover the gratuitous mid-stream demos that need a week of<br>diverted-from-productive effort to prepare each time.</p><p>And if you have the kind of management that wants to interrupt you for a crisis meeting<br>or a re-installation of software/OS on their virus infested laptop, or the latest<br>FAD scrummish trendy management thing at least 3 times per day,<br>fuggedaboutit. You're completely screwed with any estimate you come up with.</p></htmltext>
<tokenext>( Or more precisely multiply by 9/5 and add 32 ) .This is often enough contingency to handle the curve ball requirements changes thatmanagement and customers will inevitably throw at you throughout the development period.It may not be enough to cover the gratuitous mid-stream demos that need a week ofdiverted-from-productive effort to prepare each time.And if you have the kind of management that wants to interrupt you for a crisis meetingor a re-installation of software/OS on their virus infested laptop , or the latestFAD scrummish trendy management thing at least 3 times per day,fuggedaboutit .
You 're completely screwed with any estimate you come up with .</tokentext>
<sentencetext>(Or more precisely multiply by 9/5 and add 32).This is often enough contingency to handle the curve ball requirements changes thatmanagement and customers will inevitably throw at you throughout the development period.It may not be enough to cover the gratuitous mid-stream demos that need a week ofdiverted-from-productive effort to prepare each time.And if you have the kind of management that wants to interrupt you for a crisis meetingor a re-installation of software/OS on their virus infested laptop, or the latestFAD scrummish trendy management thing at least 3 times per day,fuggedaboutit.
You're completely screwed with any estimate you come up with.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076950</id>
	<title>It's simple</title>
	<author>zmooc</author>
	<datestamp>1265706120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I use scrum too. But that's not a way of estimating programming time, it is merely a way to manage a software project. And it works. Use it. It's good for your heart and blood pressure:P</p><p>Anyway. Estimating programming time is actually really simple. You take your time to plan, up to 10\% of the duration of the project, and discuss the result with your peers. Make a work breakdown and make sure there's nothing in there that you estimate takes more than about a day. Preferably much shorter. Also, use fixed ranges. I use less than 1 hour, 1-4 hours, 4-8 hours, 1-3 days and  more than 3 days. The latter two are to be avoided. The result of all this is obviously a range you expect your project to take, not a fixed number of hours. Note that according to pretty ancient research, engineers often need 2.18 times their estimate to complete a task; this is sort-of built-in in the fixed ranges I mentioned.</p><p>Also, it is very important to keep a log of what you've done, how long it took and why. That's part of the reason it takes some time to get it right. Find entries in your log that look a bit like the entries on your work breakdown and compare them; that way you can learn from mistakes you made in previous plans.</p><p>So far for estimating. But that's only a third of the job. It is very important to acknowledge that what you've just calculated is just an estimate and to be open about it. So you need safeguards. I use the following:<br>1. Plan for overhead. 20\% is usually fine.<br>2. Talk to your stakeholders and prioritize your project from a functional POV. Scrum uses <a href="http://en.wikipedia.org/wiki/MoSCoW\_Method" title="wikipedia.org">http://en.wikipedia.org/wiki/MoSCoW\_Method</a> [wikipedia.org] for that. Commit only to the requirements with the highest priority (and if that's all of them, just make up optional requirements:P).<br>3. Make sure your maximum estimate plus the overhead is enough time to fix those requirements.</p><p>The last thing you need to make your estimates turn out to be correct, is some form of project management. Make sure you discuss the state of the project (as compared to the original plan!) daily. Let all team members have their say and if something does not go according to plan, act on it early, don't safe the problems for release day. Make sure everybody has the right focus and works on the requirements with the highest priorities. Nobody should work on prio 1 requirements when prio 2 requirements are still not finished. Ever.</p><p>Obviously you're guaranteed to fail if you don't commit, integrate, test, build and package early and often. Use a continuous integration build-server, use version control, write unit-tests (yes, they safe time), use a proper issue-tracker (with workflow and support for estimates, actual time, priority etc) and make sure you have a quality assurance person on board that tests EVERYTHING (yes, that'll safe time too). Just the usual common sense stuff.</p><p>Of course some of us work on projects at companies that are run by douchebags; they won't give you enough time to plan, they do not want to prioritize, they don't understand why they need to pay for servers, issue-trackers, meetings, continuous integration servers, quality assurance ppl and all that "bullshit". Always share your concerns with them; never ever give them the chance to blame you. Blame them instead. And look for a better job that does not remind you of Dilbert; such jobs do exist;-)</p><p>Now if you stick to all that and evaluate early and often, you'll probably get it completely wrong the first few times, but you'll quite often get it spot on eventually. 99\% of correctly estimating programming time is to get to know yourself and to stick to your plan. And those two things are incredibly hard;-P</p></htmltext>
<tokenext>I use scrum too .
But that 's not a way of estimating programming time , it is merely a way to manage a software project .
And it works .
Use it .
It 's good for your heart and blood pressure : PAnyway .
Estimating programming time is actually really simple .
You take your time to plan , up to 10 \ % of the duration of the project , and discuss the result with your peers .
Make a work breakdown and make sure there 's nothing in there that you estimate takes more than about a day .
Preferably much shorter .
Also , use fixed ranges .
I use less than 1 hour , 1-4 hours , 4-8 hours , 1-3 days and more than 3 days .
The latter two are to be avoided .
The result of all this is obviously a range you expect your project to take , not a fixed number of hours .
Note that according to pretty ancient research , engineers often need 2.18 times their estimate to complete a task ; this is sort-of built-in in the fixed ranges I mentioned.Also , it is very important to keep a log of what you 've done , how long it took and why .
That 's part of the reason it takes some time to get it right .
Find entries in your log that look a bit like the entries on your work breakdown and compare them ; that way you can learn from mistakes you made in previous plans.So far for estimating .
But that 's only a third of the job .
It is very important to acknowledge that what you 've just calculated is just an estimate and to be open about it .
So you need safeguards .
I use the following : 1 .
Plan for overhead .
20 \ % is usually fine.2 .
Talk to your stakeholders and prioritize your project from a functional POV .
Scrum uses http : //en.wikipedia.org/wiki/MoSCoW \ _Method [ wikipedia.org ] for that .
Commit only to the requirements with the highest priority ( and if that 's all of them , just make up optional requirements : P ) .3 .
Make sure your maximum estimate plus the overhead is enough time to fix those requirements.The last thing you need to make your estimates turn out to be correct , is some form of project management .
Make sure you discuss the state of the project ( as compared to the original plan !
) daily .
Let all team members have their say and if something does not go according to plan , act on it early , do n't safe the problems for release day .
Make sure everybody has the right focus and works on the requirements with the highest priorities .
Nobody should work on prio 1 requirements when prio 2 requirements are still not finished .
Ever.Obviously you 're guaranteed to fail if you do n't commit , integrate , test , build and package early and often .
Use a continuous integration build-server , use version control , write unit-tests ( yes , they safe time ) , use a proper issue-tracker ( with workflow and support for estimates , actual time , priority etc ) and make sure you have a quality assurance person on board that tests EVERYTHING ( yes , that 'll safe time too ) .
Just the usual common sense stuff.Of course some of us work on projects at companies that are run by douchebags ; they wo n't give you enough time to plan , they do not want to prioritize , they do n't understand why they need to pay for servers , issue-trackers , meetings , continuous integration servers , quality assurance ppl and all that " bullshit " .
Always share your concerns with them ; never ever give them the chance to blame you .
Blame them instead .
And look for a better job that does not remind you of Dilbert ; such jobs do exist ; - ) Now if you stick to all that and evaluate early and often , you 'll probably get it completely wrong the first few times , but you 'll quite often get it spot on eventually .
99 \ % of correctly estimating programming time is to get to know yourself and to stick to your plan .
And those two things are incredibly hard ; -P</tokentext>
<sentencetext>I use scrum too.
But that's not a way of estimating programming time, it is merely a way to manage a software project.
And it works.
Use it.
It's good for your heart and blood pressure:PAnyway.
Estimating programming time is actually really simple.
You take your time to plan, up to 10\% of the duration of the project, and discuss the result with your peers.
Make a work breakdown and make sure there's nothing in there that you estimate takes more than about a day.
Preferably much shorter.
Also, use fixed ranges.
I use less than 1 hour, 1-4 hours, 4-8 hours, 1-3 days and  more than 3 days.
The latter two are to be avoided.
The result of all this is obviously a range you expect your project to take, not a fixed number of hours.
Note that according to pretty ancient research, engineers often need 2.18 times their estimate to complete a task; this is sort-of built-in in the fixed ranges I mentioned.Also, it is very important to keep a log of what you've done, how long it took and why.
That's part of the reason it takes some time to get it right.
Find entries in your log that look a bit like the entries on your work breakdown and compare them; that way you can learn from mistakes you made in previous plans.So far for estimating.
But that's only a third of the job.
It is very important to acknowledge that what you've just calculated is just an estimate and to be open about it.
So you need safeguards.
I use the following:1.
Plan for overhead.
20\% is usually fine.2.
Talk to your stakeholders and prioritize your project from a functional POV.
Scrum uses http://en.wikipedia.org/wiki/MoSCoW\_Method [wikipedia.org] for that.
Commit only to the requirements with the highest priority (and if that's all of them, just make up optional requirements:P).3.
Make sure your maximum estimate plus the overhead is enough time to fix those requirements.The last thing you need to make your estimates turn out to be correct, is some form of project management.
Make sure you discuss the state of the project (as compared to the original plan!
) daily.
Let all team members have their say and if something does not go according to plan, act on it early, don't safe the problems for release day.
Make sure everybody has the right focus and works on the requirements with the highest priorities.
Nobody should work on prio 1 requirements when prio 2 requirements are still not finished.
Ever.Obviously you're guaranteed to fail if you don't commit, integrate, test, build and package early and often.
Use a continuous integration build-server, use version control, write unit-tests (yes, they safe time), use a proper issue-tracker (with workflow and support for estimates, actual time, priority etc) and make sure you have a quality assurance person on board that tests EVERYTHING (yes, that'll safe time too).
Just the usual common sense stuff.Of course some of us work on projects at companies that are run by douchebags; they won't give you enough time to plan, they do not want to prioritize, they don't understand why they need to pay for servers, issue-trackers, meetings, continuous integration servers, quality assurance ppl and all that "bullshit".
Always share your concerns with them; never ever give them the chance to blame you.
Blame them instead.
And look for a better job that does not remind you of Dilbert; such jobs do exist;-)Now if you stick to all that and evaluate early and often, you'll probably get it completely wrong the first few times, but you'll quite often get it spot on eventually.
99\% of correctly estimating programming time is to get to know yourself and to stick to your plan.
And those two things are incredibly hard;-P</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079902</id>
	<title>Works only if you have all ingredients upfront</title>
	<author>Mask</author>
	<datestamp>1265718540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You can estimate time only if you know all required components upfront. You should know all the related technology, which probably been used by you  in prior projects. Once you try that no one managed to complete before you can't estimate what can be done in a single sprint.</p><p>Let's you have an NP-hard problem which is, e.g., a variant of set-cover or bin-packing. You write a prototype that maps the problem into SAT and invokes a state-of-the-art SAT solver, all is well. Next week you try to solve a set-cover instance, after running for a couple of hours you terminate the run. After tweaking the set-cover to SAT converter for the rest of the week you manage to get a trivial use-case pass. Now, how the hell can you estimate the number of weeks and experiments it will take you to get a realistic problem to run reasonably well? NP-hard problem solving sometimes behaves exponentially but sometimes linearly, you don't always know in advance as it depends on the micro structure of the inputs.</p><p>The process of writing software that solves real-world NP-hard problems looks completely stochastic. You can read dozens of papers, try hundreds of different algorithms, approximations, heuristics, technologies and new ideas before you find how to solve the problem at hand, assuming you do. How can you estimate this time - upfront?</p><p>On the bright side, NP-hard, decidability and other tough algorithmic problems are only a niche in the world of programming. Most of the time software development is "only" a matter of engineering, planning and experience -- where Scrum could well be the right answer.</p></htmltext>
<tokenext>You can estimate time only if you know all required components upfront .
You should know all the related technology , which probably been used by you in prior projects .
Once you try that no one managed to complete before you ca n't estimate what can be done in a single sprint.Let 's you have an NP-hard problem which is , e.g. , a variant of set-cover or bin-packing .
You write a prototype that maps the problem into SAT and invokes a state-of-the-art SAT solver , all is well .
Next week you try to solve a set-cover instance , after running for a couple of hours you terminate the run .
After tweaking the set-cover to SAT converter for the rest of the week you manage to get a trivial use-case pass .
Now , how the hell can you estimate the number of weeks and experiments it will take you to get a realistic problem to run reasonably well ?
NP-hard problem solving sometimes behaves exponentially but sometimes linearly , you do n't always know in advance as it depends on the micro structure of the inputs.The process of writing software that solves real-world NP-hard problems looks completely stochastic .
You can read dozens of papers , try hundreds of different algorithms , approximations , heuristics , technologies and new ideas before you find how to solve the problem at hand , assuming you do .
How can you estimate this time - upfront ? On the bright side , NP-hard , decidability and other tough algorithmic problems are only a niche in the world of programming .
Most of the time software development is " only " a matter of engineering , planning and experience -- where Scrum could well be the right answer .</tokentext>
<sentencetext>You can estimate time only if you know all required components upfront.
You should know all the related technology, which probably been used by you  in prior projects.
Once you try that no one managed to complete before you can't estimate what can be done in a single sprint.Let's you have an NP-hard problem which is, e.g., a variant of set-cover or bin-packing.
You write a prototype that maps the problem into SAT and invokes a state-of-the-art SAT solver, all is well.
Next week you try to solve a set-cover instance, after running for a couple of hours you terminate the run.
After tweaking the set-cover to SAT converter for the rest of the week you manage to get a trivial use-case pass.
Now, how the hell can you estimate the number of weeks and experiments it will take you to get a realistic problem to run reasonably well?
NP-hard problem solving sometimes behaves exponentially but sometimes linearly, you don't always know in advance as it depends on the micro structure of the inputs.The process of writing software that solves real-world NP-hard problems looks completely stochastic.
You can read dozens of papers, try hundreds of different algorithms, approximations, heuristics, technologies and new ideas before you find how to solve the problem at hand, assuming you do.
How can you estimate this time - upfront?On the bright side, NP-hard, decidability and other tough algorithmic problems are only a niche in the world of programming.
Most of the time software development is "only" a matter of engineering, planning and experience -- where Scrum could well be the right answer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075786</id>
	<title>The usual way...</title>
	<author>garg0yle</author>
	<datestamp>1265745060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Double it, and add thirty!</p></htmltext>
<tokenext>Double it , and add thirty !</tokentext>
<sentencetext>Double it, and add thirty!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075742</id>
	<title>It's very easy</title>
	<author>BenSchuarmer</author>
	<datestamp>1265744940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Just say "It will take between ${minimum\_estimate} and 40 years".  Chances are pretty good that this estimate will be <em>accurate</em> (and if it's not accurate you'll be retired by then).</p><p>Making an estimate both accurate and <em>precise</em> is harder.</p></htmltext>
<tokenext>Just say " It will take between $ { minimum \ _estimate } and 40 years " .
Chances are pretty good that this estimate will be accurate ( and if it 's not accurate you 'll be retired by then ) .Making an estimate both accurate and precise is harder .</tokentext>
<sentencetext>Just say "It will take between ${minimum\_estimate} and 40 years".
Chances are pretty good that this estimate will be accurate (and if it's not accurate you'll be retired by then).Making an estimate both accurate and precise is harder.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076460</id>
	<title>How hard is the task</title>
	<author>Anonymous</author>
	<datestamp>1265747460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Take each task and ask or determine at a team meeting the difficulty of the task...</p><p>Start with a base line for level if task difficultly (For example)...<br>easy task - one day<br>Medium Task - two to three days<br>hard task - 5 days<br>never done task - 1 to 2 weeks.</p><p>No task should ever been more complicated than a week and if it is then I try to break it down in to smaller parts.  The only exception is the new task.  I typically hand that to the guru and a week typically covers his research and implementation plan.  But due to surprises I schedule an extra week.  Some easy tasks turn into hard tasks and some hard tasks turn into easy tasks.  The work week task is a nice policy as at the end of the week the individual task is typically done and if they get sick or something happens their work is caught up and someone else can pick their next task.</p><p>Then factor in the skill level of the developer - triple the times for a green guy, keep the same for a veteran, and cut 25\% off for the mind blowing guru, etc.</p><p>Depending on the business culture add on a percentage for Testing.  Then add on the typical roll out time.  Good tester and fixing take about as long as the development.</p><p>In total I have about 5 levels of difficult and 4 levels of skills.  Add on a bit of time for sickness, family issues, etc.</p><p>Most times we have time lines given to us.  After the planning is done and if we can not achieve it I ask for more members or a reduction in scope or functionality.  If they push and say it all has to be done then I ask for more money due to over time.  If they still push I say it is impossible given the money, time and scope and demand they formally tell which corner should be cut.</p><p>I get it bang on or done slightly earlier at least 90\% of the time.  The remaining 10\% of the time an easy task turned into a hard task or there was a dramatic scope change approved via a Change request with insufficient time to implement or unforeseen repercussions.</p><p>The big thing is to work with your team.  In a group meeting lasting a few hours to a day you can determine what each task needs to be and determine the level of difficulty associated with it.  Then you just need give ownership of each task to developer - this is good when some guy brags that he can accomplish a hard task in a day and the rest of the team disagrees (he may have insight or he is making a mistake).  One of best examples I saw of this in action was the own project broken up in to major phases and under each phase it was broken up to more general tasks and under each task was a open box of the individual tasks required to accomplish it.  The team then used sticky notes to put all the task in and a related difficulty level.  The PM just facilitated the team and then recorded it all as the official plan.  Every member felt included and felt like they had some ownership in the project.</p></htmltext>
<tokenext>Take each task and ask or determine at a team meeting the difficulty of the task...Start with a base line for level if task difficultly ( For example ) ...easy task - one dayMedium Task - two to three dayshard task - 5 daysnever done task - 1 to 2 weeks.No task should ever been more complicated than a week and if it is then I try to break it down in to smaller parts .
The only exception is the new task .
I typically hand that to the guru and a week typically covers his research and implementation plan .
But due to surprises I schedule an extra week .
Some easy tasks turn into hard tasks and some hard tasks turn into easy tasks .
The work week task is a nice policy as at the end of the week the individual task is typically done and if they get sick or something happens their work is caught up and someone else can pick their next task.Then factor in the skill level of the developer - triple the times for a green guy , keep the same for a veteran , and cut 25 \ % off for the mind blowing guru , etc.Depending on the business culture add on a percentage for Testing .
Then add on the typical roll out time .
Good tester and fixing take about as long as the development.In total I have about 5 levels of difficult and 4 levels of skills .
Add on a bit of time for sickness , family issues , etc.Most times we have time lines given to us .
After the planning is done and if we can not achieve it I ask for more members or a reduction in scope or functionality .
If they push and say it all has to be done then I ask for more money due to over time .
If they still push I say it is impossible given the money , time and scope and demand they formally tell which corner should be cut.I get it bang on or done slightly earlier at least 90 \ % of the time .
The remaining 10 \ % of the time an easy task turned into a hard task or there was a dramatic scope change approved via a Change request with insufficient time to implement or unforeseen repercussions.The big thing is to work with your team .
In a group meeting lasting a few hours to a day you can determine what each task needs to be and determine the level of difficulty associated with it .
Then you just need give ownership of each task to developer - this is good when some guy brags that he can accomplish a hard task in a day and the rest of the team disagrees ( he may have insight or he is making a mistake ) .
One of best examples I saw of this in action was the own project broken up in to major phases and under each phase it was broken up to more general tasks and under each task was a open box of the individual tasks required to accomplish it .
The team then used sticky notes to put all the task in and a related difficulty level .
The PM just facilitated the team and then recorded it all as the official plan .
Every member felt included and felt like they had some ownership in the project .</tokentext>
<sentencetext>Take each task and ask or determine at a team meeting the difficulty of the task...Start with a base line for level if task difficultly (For example)...easy task - one dayMedium Task - two to three dayshard task - 5 daysnever done task - 1 to 2 weeks.No task should ever been more complicated than a week and if it is then I try to break it down in to smaller parts.
The only exception is the new task.
I typically hand that to the guru and a week typically covers his research and implementation plan.
But due to surprises I schedule an extra week.
Some easy tasks turn into hard tasks and some hard tasks turn into easy tasks.
The work week task is a nice policy as at the end of the week the individual task is typically done and if they get sick or something happens their work is caught up and someone else can pick their next task.Then factor in the skill level of the developer - triple the times for a green guy, keep the same for a veteran, and cut 25\% off for the mind blowing guru, etc.Depending on the business culture add on a percentage for Testing.
Then add on the typical roll out time.
Good tester and fixing take about as long as the development.In total I have about 5 levels of difficult and 4 levels of skills.
Add on a bit of time for sickness, family issues, etc.Most times we have time lines given to us.
After the planning is done and if we can not achieve it I ask for more members or a reduction in scope or functionality.
If they push and say it all has to be done then I ask for more money due to over time.
If they still push I say it is impossible given the money, time and scope and demand they formally tell which corner should be cut.I get it bang on or done slightly earlier at least 90\% of the time.
The remaining 10\% of the time an easy task turned into a hard task or there was a dramatic scope change approved via a Change request with insufficient time to implement or unforeseen repercussions.The big thing is to work with your team.
In a group meeting lasting a few hours to a day you can determine what each task needs to be and determine the level of difficulty associated with it.
Then you just need give ownership of each task to developer - this is good when some guy brags that he can accomplish a hard task in a day and the rest of the team disagrees (he may have insight or he is making a mistake).
One of best examples I saw of this in action was the own project broken up in to major phases and under each phase it was broken up to more general tasks and under each task was a open box of the individual tasks required to accomplish it.
The team then used sticky notes to put all the task in and a related difficulty level.
The PM just facilitated the team and then recorded it all as the official plan.
Every member felt included and felt like they had some ownership in the project.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31114656</id>
	<title>Re:Function Point Analysis and Man Hours</title>
	<author>benhattman</author>
	<datestamp>1265996760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not sure why this was modded funny.  It's actually a pretty reasonable way to make a good estimate.  If it takes X time to crank out a working prototype feature, then it usually takes 3X to rigorously test and fix it, and it also takes 3X to take it from working to truly usable.  If you want something well tested and easy to use, that's 9X total.</p><p>The parent's math is a little generous (12.5X), but pretty much spot on.  The real challenge people seem to have when making estimates is that when management asks "how long will it take to make X", they mean the final product X, while engineers think they are talking about the functional prototype because that's the part that's interesting to them.  The rest is just "polishing" it up, which even though that polish part is 90\% of the work, most engineers consider it trivial.</p></htmltext>
<tokenext>Not sure why this was modded funny .
It 's actually a pretty reasonable way to make a good estimate .
If it takes X time to crank out a working prototype feature , then it usually takes 3X to rigorously test and fix it , and it also takes 3X to take it from working to truly usable .
If you want something well tested and easy to use , that 's 9X total.The parent 's math is a little generous ( 12.5X ) , but pretty much spot on .
The real challenge people seem to have when making estimates is that when management asks " how long will it take to make X " , they mean the final product X , while engineers think they are talking about the functional prototype because that 's the part that 's interesting to them .
The rest is just " polishing " it up , which even though that polish part is 90 \ % of the work , most engineers consider it trivial .</tokentext>
<sentencetext>Not sure why this was modded funny.
It's actually a pretty reasonable way to make a good estimate.
If it takes X time to crank out a working prototype feature, then it usually takes 3X to rigorously test and fix it, and it also takes 3X to take it from working to truly usable.
If you want something well tested and easy to use, that's 9X total.The parent's math is a little generous (12.5X), but pretty much spot on.
The real challenge people seem to have when making estimates is that when management asks "how long will it take to make X", they mean the final product X, while engineers think they are talking about the functional prototype because that's the part that's interesting to them.
The rest is just "polishing" it up, which even though that polish part is 90\% of the work, most engineers consider it trivial.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081932</id>
	<title>Double it</title>
	<author>BlackHawk-666</author>
	<datestamp>1265735220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I take however long I think it will take based on previous similar work, and then I double it. If there's free time in the estimate I get to use it to sleep or walk to a coke machine, or do some of the other projects I am getting pushed onto me at the same time.</p></htmltext>
<tokenext>I take however long I think it will take based on previous similar work , and then I double it .
If there 's free time in the estimate I get to use it to sleep or walk to a coke machine , or do some of the other projects I am getting pushed onto me at the same time .</tokentext>
<sentencetext>I take however long I think it will take based on previous similar work, and then I double it.
If there's free time in the estimate I get to use it to sleep or walk to a coke machine, or do some of the other projects I am getting pushed onto me at the same time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075580</id>
	<title>Re:W.A.G.</title>
	<author>Anonymous</author>
	<datestamp>1265744460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Pretty much.  Even when you're coding to a completely laid out specification, the time it takes to understand the specification and determine how many lines of code you'll need to write to meet each point of that specification is basically equal to the time it takes to code the specification less a factor based on your typing speed.</p><p>You could guess on a (# of bullets x avg. time per bullet) basis, but then you run into specifications like the one I'm dealing with where I've got</p><p>I.3.ii.A) Alerts indicating that data was not saved due to user error shall be red text on a white background.</p><p>and</p><p>IV.4.i.B) All data entered into any field in the software shall be retained, even if "superseded" with new data or "removed" by the user, until such time that an administrative user reviews the retained data and decides to "purge" the data from the system.</p><p>One of those is one line of code and will take about 30 seconds.  The other... well, it's a good thing we read the entire spec before we began.</p></htmltext>
<tokenext>Pretty much .
Even when you 're coding to a completely laid out specification , the time it takes to understand the specification and determine how many lines of code you 'll need to write to meet each point of that specification is basically equal to the time it takes to code the specification less a factor based on your typing speed.You could guess on a ( # of bullets x avg .
time per bullet ) basis , but then you run into specifications like the one I 'm dealing with where I 've gotI.3.ii.A ) Alerts indicating that data was not saved due to user error shall be red text on a white background.andIV.4.i.B ) All data entered into any field in the software shall be retained , even if " superseded " with new data or " removed " by the user , until such time that an administrative user reviews the retained data and decides to " purge " the data from the system.One of those is one line of code and will take about 30 seconds .
The other... well , it 's a good thing we read the entire spec before we began .</tokentext>
<sentencetext>Pretty much.
Even when you're coding to a completely laid out specification, the time it takes to understand the specification and determine how many lines of code you'll need to write to meet each point of that specification is basically equal to the time it takes to code the specification less a factor based on your typing speed.You could guess on a (# of bullets x avg.
time per bullet) basis, but then you run into specifications like the one I'm dealing with where I've gotI.3.ii.A) Alerts indicating that data was not saved due to user error shall be red text on a white background.andIV.4.i.B) All data entered into any field in the software shall be retained, even if "superseded" with new data or "removed" by the user, until such time that an administrative user reviews the retained data and decides to "purge" the data from the system.One of those is one line of code and will take about 30 seconds.
The other... well, it's a good thing we read the entire spec before we began.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075616</id>
	<title>Exact approximation.</title>
	<author>Anonymous</author>
	<datestamp>1265744580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Precise guess.</p><p>Accurate estimate.</p><p>In just one word: oxymoron.</p></htmltext>
<tokenext>Precise guess.Accurate estimate.In just one word : oxymoron .</tokentext>
<sentencetext>Precise guess.Accurate estimate.In just one word: oxymoron.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076720</id>
	<title>Re:Simply, no software required.</title>
	<author>Anonymous</author>
	<datestamp>1265748480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>And never believe a programmer who claims the simple change will take only 5 minutes.  Nothing can be accomplished in 5 minutes.  The minimum is 20 minutes, even for a one character change.</p><p>Anything worth doing takes 9 months plus a week, so your best bet is to figure out how much you can fit into that schedule.  Plan out the essentials as being first, make that core a working demo that is debugged, presentable, and deliverable in the first month, then keep adding features until you run out of time.</p></htmltext>
<tokenext>And never believe a programmer who claims the simple change will take only 5 minutes .
Nothing can be accomplished in 5 minutes .
The minimum is 20 minutes , even for a one character change.Anything worth doing takes 9 months plus a week , so your best bet is to figure out how much you can fit into that schedule .
Plan out the essentials as being first , make that core a working demo that is debugged , presentable , and deliverable in the first month , then keep adding features until you run out of time .</tokentext>
<sentencetext>And never believe a programmer who claims the simple change will take only 5 minutes.
Nothing can be accomplished in 5 minutes.
The minimum is 20 minutes, even for a one character change.Anything worth doing takes 9 months plus a week, so your best bet is to figure out how much you can fit into that schedule.
Plan out the essentials as being first, make that core a working demo that is debugged, presentable, and deliverable in the first month, then keep adding features until you run out of time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075816</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076676</id>
	<title>Re:Simply, no software required.</title>
	<author>DeadCatX2</author>
	<datestamp>1265748300000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>I multiply all time estimates by pi, to account for running around in circles.</p></htmltext>
<tokenext>I multiply all time estimates by pi , to account for running around in circles .</tokentext>
<sentencetext>I multiply all time estimates by pi, to account for running around in circles.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077648</id>
	<title>Re:W.A.G.</title>
	<author>Darinbob</author>
	<datestamp>1265708940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yep, the estimate is basically to take the date of delivery and subtract today's date, then add a week.  If you're done early, then that's great as you have more time to fix the bugs that crop up in the meantime or whatever other maintenance is needed.  If you're late then you trim down your own deliverables, fix fewer bugs, spend some later nights, or if desperate work on the weekend.<br><br>Often I find that the marketing aspect is what's important here.  Ie, the company wants to say "version 3.0 now cures cancer".  They'd love to say it cures all cancer but will be happy if it only cures one type of cancer.  Even if it cures one type of cancer while increasing the risk of a different cancer, at least marketing will be able to use the "cures cancer" bullet point.  If you can't implement it all in version 3.0, well you will just be given the job to finish more of it in version 3.1.  Which means that as long as you get some significant part of it completed, you can trim down on your deliverables quite a lot.<br><br>I implemented one feature that was not as fast as I wanted so some people seemed concerned that it wasn't as fast as Windows.  I knew how to make it much faster and said I'd work on it in a later release and that it wouldn't be that much work.  But no one ever assigned me the task to finish it up.  The slow feature was enough to get the bullet point, and some customers were happy that it existed, but there were more important things to work on in the future rather than go back and polish things.</htmltext>
<tokenext>Yep , the estimate is basically to take the date of delivery and subtract today 's date , then add a week .
If you 're done early , then that 's great as you have more time to fix the bugs that crop up in the meantime or whatever other maintenance is needed .
If you 're late then you trim down your own deliverables , fix fewer bugs , spend some later nights , or if desperate work on the weekend.Often I find that the marketing aspect is what 's important here .
Ie , the company wants to say " version 3.0 now cures cancer " .
They 'd love to say it cures all cancer but will be happy if it only cures one type of cancer .
Even if it cures one type of cancer while increasing the risk of a different cancer , at least marketing will be able to use the " cures cancer " bullet point .
If you ca n't implement it all in version 3.0 , well you will just be given the job to finish more of it in version 3.1 .
Which means that as long as you get some significant part of it completed , you can trim down on your deliverables quite a lot.I implemented one feature that was not as fast as I wanted so some people seemed concerned that it was n't as fast as Windows .
I knew how to make it much faster and said I 'd work on it in a later release and that it would n't be that much work .
But no one ever assigned me the task to finish it up .
The slow feature was enough to get the bullet point , and some customers were happy that it existed , but there were more important things to work on in the future rather than go back and polish things .</tokentext>
<sentencetext>Yep, the estimate is basically to take the date of delivery and subtract today's date, then add a week.
If you're done early, then that's great as you have more time to fix the bugs that crop up in the meantime or whatever other maintenance is needed.
If you're late then you trim down your own deliverables, fix fewer bugs, spend some later nights, or if desperate work on the weekend.Often I find that the marketing aspect is what's important here.
Ie, the company wants to say "version 3.0 now cures cancer".
They'd love to say it cures all cancer but will be happy if it only cures one type of cancer.
Even if it cures one type of cancer while increasing the risk of a different cancer, at least marketing will be able to use the "cures cancer" bullet point.
If you can't implement it all in version 3.0, well you will just be given the job to finish more of it in version 3.1.
Which means that as long as you get some significant part of it completed, you can trim down on your deliverables quite a lot.I implemented one feature that was not as fast as I wanted so some people seemed concerned that it wasn't as fast as Windows.
I knew how to make it much faster and said I'd work on it in a later release and that it wouldn't be that much work.
But no one ever assigned me the task to finish it up.
The slow feature was enough to get the bullet point, and some customers were happy that it existed, but there were more important things to work on in the future rather than go back and polish things.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075458</id>
	<title>Make Estimate, Track Overrun</title>
	<author>Kostya</author>
	<datestamp>1265743980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I make the initial best-guess estimates based on past projects and past developer performance.  I track the initial estimate, and then I track all effort spent as it is logged.  I.e. each checkin gets an "effort spent" number.  I then track "actual vs. estimate" and come up with a total amount of overrun <i>so far</i>.  I take that overrun, get a percentage (e.g. "over by 15\%") and then add that back to the total estimate.</p><p>So, if the total estimate is 100 man hours, and we are currently over by 15\%, I then say it will actually take us 115 hours total to finish the project.</p><p>This is based on the sage wisdom of Mythical Man Month: if you first estimate is off, so are <b>all</b> your estimates, usually by the same amount.  As depressing as that might initially sound, it's actually accurate and it gives you a great tool for getting a real estimate once the project is underway.</p><p>So I mark my first estimates as "estimates" and then I consider the adjusted estimate once we are 2-4 weeks in to be more accurate.  It has usually put us one to two weeks within the actual delivery date--which based on my experience with software development over the past 15 years is really good estimating<nobr> <wbr></nobr>:-)  The norm on the projects I was a developer on was that overrun was closer to 90-100\%.  My last project I managed was 25\% with new developers--I considered that a victory<nobr> <wbr></nobr>:-)</p></htmltext>
<tokenext>I make the initial best-guess estimates based on past projects and past developer performance .
I track the initial estimate , and then I track all effort spent as it is logged .
I.e. each checkin gets an " effort spent " number .
I then track " actual vs. estimate " and come up with a total amount of overrun so far .
I take that overrun , get a percentage ( e.g .
" over by 15 \ % " ) and then add that back to the total estimate.So , if the total estimate is 100 man hours , and we are currently over by 15 \ % , I then say it will actually take us 115 hours total to finish the project.This is based on the sage wisdom of Mythical Man Month : if you first estimate is off , so are all your estimates , usually by the same amount .
As depressing as that might initially sound , it 's actually accurate and it gives you a great tool for getting a real estimate once the project is underway.So I mark my first estimates as " estimates " and then I consider the adjusted estimate once we are 2-4 weeks in to be more accurate .
It has usually put us one to two weeks within the actual delivery date--which based on my experience with software development over the past 15 years is really good estimating : - ) The norm on the projects I was a developer on was that overrun was closer to 90-100 \ % .
My last project I managed was 25 \ % with new developers--I considered that a victory : - )</tokentext>
<sentencetext>I make the initial best-guess estimates based on past projects and past developer performance.
I track the initial estimate, and then I track all effort spent as it is logged.
I.e. each checkin gets an "effort spent" number.
I then track "actual vs. estimate" and come up with a total amount of overrun so far.
I take that overrun, get a percentage (e.g.
"over by 15\%") and then add that back to the total estimate.So, if the total estimate is 100 man hours, and we are currently over by 15\%, I then say it will actually take us 115 hours total to finish the project.This is based on the sage wisdom of Mythical Man Month: if you first estimate is off, so are all your estimates, usually by the same amount.
As depressing as that might initially sound, it's actually accurate and it gives you a great tool for getting a real estimate once the project is underway.So I mark my first estimates as "estimates" and then I consider the adjusted estimate once we are 2-4 weeks in to be more accurate.
It has usually put us one to two weeks within the actual delivery date--which based on my experience with software development over the past 15 years is really good estimating :-)  The norm on the projects I was a developer on was that overrun was closer to 90-100\%.
My last project I managed was 25\% with new developers--I considered that a victory :-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081034</id>
	<title>Four Levels, Train Customers, Change Control</title>
	<author>Guido69</author>
	<datestamp>1265726220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Most important step is to train your "customer" about the 4 levels and gain acceptance.
<br> <br>
L1 is pre-initiation with virtually no project details.  Estimating is done solely by managers using experience, actuals from prior similar work, and their gut feel.  We call it the SWAG level, and customer is trained to expect +/- 100\%.  We also occasionally have to give ROM estimates for our customers to gain funding prior to a project being accepted as real.  In this case we use three high-level estimates (worst case, most likely, and best case) and then show three levels of std. deviation to the customer.
<br> <br>
L2 is during initiation, when a few more details are known but usually no hard specs.  SDLC area leads do the estimates, but still at a high level.  Customer is trained to expect +/- 50\%
<br> <br>
L3 is after business requirements are documented and accepted.  SDLC area leads and key staff do the estimates, and chunk work into no more than 80 hour tasks.  Customer is trained to expect +/- 25\%.
<br> <br>
L4 is after technical design is documented and accepted.  SDLC area leads and key staff do the estimates, again chunked into &gt;=80 hour tasks.  Customer is trained to expect +/- 10\%.
<br> <br>
Managing requirements changes after L3 is crucial.  You have to ensure the customer understands the impact of any changes to scope.

Works for us on $15M of project work every year for a happy customer.  Side note:  after about a year, it's scary how close L1 estimates can be.  Managers aren't all bad.<nobr> <wbr></nobr>:)</htmltext>
<tokenext>Most important step is to train your " customer " about the 4 levels and gain acceptance .
L1 is pre-initiation with virtually no project details .
Estimating is done solely by managers using experience , actuals from prior similar work , and their gut feel .
We call it the SWAG level , and customer is trained to expect + /- 100 \ % .
We also occasionally have to give ROM estimates for our customers to gain funding prior to a project being accepted as real .
In this case we use three high-level estimates ( worst case , most likely , and best case ) and then show three levels of std .
deviation to the customer .
L2 is during initiation , when a few more details are known but usually no hard specs .
SDLC area leads do the estimates , but still at a high level .
Customer is trained to expect + /- 50 \ % L3 is after business requirements are documented and accepted .
SDLC area leads and key staff do the estimates , and chunk work into no more than 80 hour tasks .
Customer is trained to expect + /- 25 \ % .
L4 is after technical design is documented and accepted .
SDLC area leads and key staff do the estimates , again chunked into &gt; = 80 hour tasks .
Customer is trained to expect + /- 10 \ % .
Managing requirements changes after L3 is crucial .
You have to ensure the customer understands the impact of any changes to scope .
Works for us on $ 15M of project work every year for a happy customer .
Side note : after about a year , it 's scary how close L1 estimates can be .
Managers are n't all bad .
: )</tokentext>
<sentencetext>Most important step is to train your "customer" about the 4 levels and gain acceptance.
L1 is pre-initiation with virtually no project details.
Estimating is done solely by managers using experience, actuals from prior similar work, and their gut feel.
We call it the SWAG level, and customer is trained to expect +/- 100\%.
We also occasionally have to give ROM estimates for our customers to gain funding prior to a project being accepted as real.
In this case we use three high-level estimates (worst case, most likely, and best case) and then show three levels of std.
deviation to the customer.
L2 is during initiation, when a few more details are known but usually no hard specs.
SDLC area leads do the estimates, but still at a high level.
Customer is trained to expect +/- 50\%
 
L3 is after business requirements are documented and accepted.
SDLC area leads and key staff do the estimates, and chunk work into no more than 80 hour tasks.
Customer is trained to expect +/- 25\%.
L4 is after technical design is documented and accepted.
SDLC area leads and key staff do the estimates, again chunked into &gt;=80 hour tasks.
Customer is trained to expect +/- 10\%.
Managing requirements changes after L3 is crucial.
You have to ensure the customer understands the impact of any changes to scope.
Works for us on $15M of project work every year for a happy customer.
Side note:  after about a year, it's scary how close L1 estimates can be.
Managers aren't all bad.
:)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076914</id>
	<title>Re:Well, I *used* to use the entrails of goats...</title>
	<author>Ma8thew</author>
	<datestamp>1265706000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Tea drinkers wussies? Tea drinkers conquered <a href="http://en.wikipedia.org/wiki/British\_Empire#World\_wars\_.281914.E2.80.931945.29" title="wikipedia.org">half the world</a> [wikipedia.org] forming the largest empire in history <i>in pursuit of more tea</i>.</htmltext>
<tokenext>Tea drinkers wussies ?
Tea drinkers conquered half the world [ wikipedia.org ] forming the largest empire in history in pursuit of more tea .</tokentext>
<sentencetext>Tea drinkers wussies?
Tea drinkers conquered half the world [wikipedia.org] forming the largest empire in history in pursuit of more tea.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078634</id>
	<title>Pick Two</title>
	<author>gv250</author>
	<datestamp>1265712840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Accurate. Time. Estimate. Pick Two.

</p><p>Seriously, I can't do it. I can give you any of these:

  </p><ul> <li> Accurate Task Estimate.</li>
   <li> Wildly inaccurate Time Estimate.</li>
   <li> Accurate Time Post-mortem.</li>
</ul><p>But, I have never, in 25 years of programming and project management, found a way to tell you accurately, in advance, how long a non-trivial task would take.

</p><p>Writing computer programs (at least in my experience) is not like building a house. Every new project is a voyage of discovery in which we invent a brand new thing. You may as well ask Edison how long it will take to invent the light bulb.</p></htmltext>
<tokenext>Accurate .
Time. Estimate .
Pick Two .
Seriously , I ca n't do it .
I can give you any of these : Accurate Task Estimate .
Wildly inaccurate Time Estimate .
Accurate Time Post-mortem .
But , I have never , in 25 years of programming and project management , found a way to tell you accurately , in advance , how long a non-trivial task would take .
Writing computer programs ( at least in my experience ) is not like building a house .
Every new project is a voyage of discovery in which we invent a brand new thing .
You may as well ask Edison how long it will take to invent the light bulb .</tokentext>
<sentencetext>Accurate.
Time. Estimate.
Pick Two.
Seriously, I can't do it.
I can give you any of these:

    Accurate Task Estimate.
Wildly inaccurate Time Estimate.
Accurate Time Post-mortem.
But, I have never, in 25 years of programming and project management, found a way to tell you accurately, in advance, how long a non-trivial task would take.
Writing computer programs (at least in my experience) is not like building a house.
Every new project is a voyage of discovery in which we invent a brand new thing.
You may as well ask Edison how long it will take to invent the light bulb.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077566</id>
	<title>Just...</title>
	<author>Anonymous</author>
	<datestamp>1265708640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>have a <a href="http://www.youtube.com/watch?v=3f5k\_3jiZII" title="youtube.com" rel="nofollow">guess!</a> [youtube.com]</p></htmltext>
<tokenext>have a guess !
[ youtube.com ]</tokentext>
<sentencetext>have a guess!
[youtube.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080336</id>
	<title>Re:Simply, no software required.</title>
	<author>Philip\_the\_physicist</author>
	<datestamp>1265721480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Unfortunately, that last 10\% is similarly divided. That's why one just ships it, and fixes it  whenever. (Well, that's what certain big vendors do, anyway<nobr> <wbr></nobr>:( ).</p></htmltext>
<tokenext>Unfortunately , that last 10 \ % is similarly divided .
That 's why one just ships it , and fixes it whenever .
( Well , that 's what certain big vendors do , anyway : ( ) .</tokentext>
<sentencetext>Unfortunately, that last 10\% is similarly divided.
That's why one just ships it, and fixes it  whenever.
(Well, that's what certain big vendors do, anyway :( ).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076682</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080394</id>
	<title>Re:Simply, no software required.</title>
	<author>Sperbels</author>
	<datestamp>1265721840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>The worst is giving estimates for a bug fix - how can you estimate how to fix a bug when you don't even know what the cause is and the bug isn't reproducible and the description is vague?</p></div><p>I hate this.  And when you say you can't estimate something like that, they say: "oh just give us your best guess, we won't hold you to it."  Then six months down the line you get called into someone's office and interrogated for an hour because you can't deliver "on time"...and by this time you forgot that they said they wouldn't hold you to the estimate so you end up trying to defend it...trying desperately to think of all the little things that went wrong and blow them up into bigger issues.</p></div>
	</htmltext>
<tokenext>The worst is giving estimates for a bug fix - how can you estimate how to fix a bug when you do n't even know what the cause is and the bug is n't reproducible and the description is vague ? I hate this .
And when you say you ca n't estimate something like that , they say : " oh just give us your best guess , we wo n't hold you to it .
" Then six months down the line you get called into someone 's office and interrogated for an hour because you ca n't deliver " on time " ...and by this time you forgot that they said they would n't hold you to the estimate so you end up trying to defend it...trying desperately to think of all the little things that went wrong and blow them up into bigger issues .</tokentext>
<sentencetext>The worst is giving estimates for a bug fix - how can you estimate how to fix a bug when you don't even know what the cause is and the bug isn't reproducible and the description is vague?I hate this.
And when you say you can't estimate something like that, they say: "oh just give us your best guess, we won't hold you to it.
"  Then six months down the line you get called into someone's office and interrogated for an hour because you can't deliver "on time"...and by this time you forgot that they said they wouldn't hold you to the estimate so you end up trying to defend it...trying desperately to think of all the little things that went wrong and blow them up into bigger issues.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077358</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077658</id>
	<title>Re:W.A.G.</title>
	<author>Dumnezeu</author>
	<datestamp>1265709000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The value of that fraction for me is 8 (found by experience). So if I think it takes one hour, it will take the whole day. That's actually normal, because half of the time I'll be reading Slashdot, half of the time left I'll be debugging, half of the time left I'll be thinking about the implementation and the hour I have left will be used for writing and tweaking the code. Seriously. So I come up with a WAG in a few seconds, I multiply it by 8 and management knows they can always count on my estimates, because they very rarely fail. Luckily, they know a lot about software development, so one day for adding a minor feature is no surprise to them (TDD, mercurial patches, merges, builds that take 10 minutes, installing virtual machines, etc).</p></htmltext>
<tokenext>The value of that fraction for me is 8 ( found by experience ) .
So if I think it takes one hour , it will take the whole day .
That 's actually normal , because half of the time I 'll be reading Slashdot , half of the time left I 'll be debugging , half of the time left I 'll be thinking about the implementation and the hour I have left will be used for writing and tweaking the code .
Seriously. So I come up with a WAG in a few seconds , I multiply it by 8 and management knows they can always count on my estimates , because they very rarely fail .
Luckily , they know a lot about software development , so one day for adding a minor feature is no surprise to them ( TDD , mercurial patches , merges , builds that take 10 minutes , installing virtual machines , etc ) .</tokentext>
<sentencetext>The value of that fraction for me is 8 (found by experience).
So if I think it takes one hour, it will take the whole day.
That's actually normal, because half of the time I'll be reading Slashdot, half of the time left I'll be debugging, half of the time left I'll be thinking about the implementation and the hour I have left will be used for writing and tweaking the code.
Seriously. So I come up with a WAG in a few seconds, I multiply it by 8 and management knows they can always count on my estimates, because they very rarely fail.
Luckily, they know a lot about software development, so one day for adding a minor feature is no surprise to them (TDD, mercurial patches, merges, builds that take 10 minutes, installing virtual machines, etc).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075692</id>
	<title>estimation</title>
	<author>God of Lemmings</author>
	<datestamp>1265744760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've found its only realistic to base a time estimate on how long it took to make a component (or something similar) the first time around.</htmltext>
<tokenext>I 've found its only realistic to base a time estimate on how long it took to make a component ( or something similar ) the first time around .</tokentext>
<sentencetext>I've found its only realistic to base a time estimate on how long it took to make a component (or something similar) the first time around.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080132</id>
	<title>Make sure the programmers are invested...</title>
	<author>Kazoo the Clown</author>
	<datestamp>1265720040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>1.  Ask the programmers involved how long it will take them to complete their parts.   Don't argue with them about the rationale, unless it's clear they're being overly optimistic (in which case, argue for them to increase their estimate).<br> <br>

2.  Double or triple their answers (depending on the complexity of the project), because they're undoubtedly still too optimistic about their abilities, lady luck, and the inevitable unforseen.<br> <br>
What you definately DON'T want to do, is to ignore what they say and tell them when you need it.   Otherwise, you'll get something like this:  Programmers say it'll take 6 months, you want it in three and come up with "rational" arguments about how "it won't take as long as you think" or how it might be done "smarter."   If you're lucky, you'll still get it in 6 months and the programmers will feel vindicated instead of guilty.</htmltext>
<tokenext>1 .
Ask the programmers involved how long it will take them to complete their parts .
Do n't argue with them about the rationale , unless it 's clear they 're being overly optimistic ( in which case , argue for them to increase their estimate ) .
2. Double or triple their answers ( depending on the complexity of the project ) , because they 're undoubtedly still too optimistic about their abilities , lady luck , and the inevitable unforseen .
What you definately DO N'T want to do , is to ignore what they say and tell them when you need it .
Otherwise , you 'll get something like this : Programmers say it 'll take 6 months , you want it in three and come up with " rational " arguments about how " it wo n't take as long as you think " or how it might be done " smarter .
" If you 're lucky , you 'll still get it in 6 months and the programmers will feel vindicated instead of guilty .</tokentext>
<sentencetext>1.
Ask the programmers involved how long it will take them to complete their parts.
Don't argue with them about the rationale, unless it's clear they're being overly optimistic (in which case, argue for them to increase their estimate).
2.  Double or triple their answers (depending on the complexity of the project), because they're undoubtedly still too optimistic about their abilities, lady luck, and the inevitable unforseen.
What you definately DON'T want to do, is to ignore what they say and tell them when you need it.
Otherwise, you'll get something like this:  Programmers say it'll take 6 months, you want it in three and come up with "rational" arguments about how "it won't take as long as you think" or how it might be done "smarter.
"   If you're lucky, you'll still get it in 6 months and the programmers will feel vindicated instead of guilty.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075546</id>
	<title>Use the "double-up" method:</title>
	<author>bittmann</author>
	<datestamp>1265744220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Do a best-case estimate of the time required, assuming everything goes perfectly and that there are no surprises.  Next, double your estimate.  And finally, switch to the next highest unit of time measure.<p>

A quarter-hour change will take half of a day.  2 hours becomes 4 days.  3 days becomes 6 weeks.  A 6-month project will take 12 quarters, or 4 years.</p><p>

It's eerie how often that rule of thumb seems to accurately depict the actual calendar time required -- eerily enough that when a so-called "realistic" estimate DOESN'T approach this metric, I find it's usually worth a second look.</p><p>

Thankfully, at least at my place of work, this rule of thumb seems to break down once the unit of measure hits a year...</p></htmltext>
<tokenext>Do a best-case estimate of the time required , assuming everything goes perfectly and that there are no surprises .
Next , double your estimate .
And finally , switch to the next highest unit of time measure .
A quarter-hour change will take half of a day .
2 hours becomes 4 days .
3 days becomes 6 weeks .
A 6-month project will take 12 quarters , or 4 years .
It 's eerie how often that rule of thumb seems to accurately depict the actual calendar time required -- eerily enough that when a so-called " realistic " estimate DOES N'T approach this metric , I find it 's usually worth a second look .
Thankfully , at least at my place of work , this rule of thumb seems to break down once the unit of measure hits a year.. .</tokentext>
<sentencetext>Do a best-case estimate of the time required, assuming everything goes perfectly and that there are no surprises.
Next, double your estimate.
And finally, switch to the next highest unit of time measure.
A quarter-hour change will take half of a day.
2 hours becomes 4 days.
3 days becomes 6 weeks.
A 6-month project will take 12 quarters, or 4 years.
It's eerie how often that rule of thumb seems to accurately depict the actual calendar time required -- eerily enough that when a so-called "realistic" estimate DOESN'T approach this metric, I find it's usually worth a second look.
Thankfully, at least at my place of work, this rule of thumb seems to break down once the unit of measure hits a year...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31084854</id>
	<title>I use Woorky</title>
	<author>BooBooGotU</author>
	<datestamp>1265035740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Check it out: <a href="http://www.gosu.pl/woorky/" title="www.gosu.pl" rel="nofollow">http://www.gosu.pl/woorky/</a> [www.gosu.pl]</htmltext>
<tokenext>Check it out : http : //www.gosu.pl/woorky/ [ www.gosu.pl ]</tokentext>
<sentencetext>Check it out: http://www.gosu.pl/woorky/ [www.gosu.pl]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075068</id>
	<title>The formula</title>
	<author>Anonymous</author>
	<datestamp>1265742780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>6 x wild\_guess + 2 weeks</p></htmltext>
<tokenext>6 x wild \ _guess + 2 weeks</tokentext>
<sentencetext>6 x wild\_guess + 2 weeks</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083768</id>
	<title>Re:Simply, no software required.</title>
	<author>etwills</author>
	<datestamp>1265024820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I take the amount of time I think it will take, double it and move it up a time unit.

So, if I think it will take two days, I estimate 4 weeks. If I think it will take a week, I estimate two months and so on.</p></div><p>
Mod parent insightful. I actually worked somewhere this
was reasonably sensible; okay, the granularity of what
we <em>actually</em> had was "hours", "mornings",
"days", "weeks", "fortnights", "months" - (pretty much
doubling again, looking back at it written down), but
there really were so many meetings and other overheads
that it made sense (that's probably what killed us, but
I digress).
</p><p><nobr> <wbr></nobr>...and then sometimes management did the same again,
which was nice. One demo I delivered in the predicted
"few days tops" (including several additional features I
anticipated followup requests for) which "we told [the
customer] we'd need three months". The graphics design
guy got plenty of time to beautify it and everyone was
*very* happy<nobr> <wbr></nobr>:)
</p></div>
	</htmltext>
<tokenext>I take the amount of time I think it will take , double it and move it up a time unit .
So , if I think it will take two days , I estimate 4 weeks .
If I think it will take a week , I estimate two months and so on .
Mod parent insightful .
I actually worked somewhere this was reasonably sensible ; okay , the granularity of what we actually had was " hours " , " mornings " , " days " , " weeks " , " fortnights " , " months " - ( pretty much doubling again , looking back at it written down ) , but there really were so many meetings and other overheads that it made sense ( that 's probably what killed us , but I digress ) .
...and then sometimes management did the same again , which was nice .
One demo I delivered in the predicted " few days tops " ( including several additional features I anticipated followup requests for ) which " we told [ the customer ] we 'd need three months " .
The graphics design guy got plenty of time to beautify it and everyone was * very * happy : )</tokentext>
<sentencetext>I take the amount of time I think it will take, double it and move it up a time unit.
So, if I think it will take two days, I estimate 4 weeks.
If I think it will take a week, I estimate two months and so on.
Mod parent insightful.
I actually worked somewhere this
was reasonably sensible; okay, the granularity of what
we actually had was "hours", "mornings",
"days", "weeks", "fortnights", "months" - (pretty much
doubling again, looking back at it written down), but
there really were so many meetings and other overheads
that it made sense (that's probably what killed us, but
I digress).
...and then sometimes management did the same again,
which was nice.
One demo I delivered in the predicted
"few days tops" (including several additional features I
anticipated followup requests for) which "we told [the
customer] we'd need three months".
The graphics design
guy got plenty of time to beautify it and everyone was
*very* happy :)

	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054</id>
	<title>Function Point Analysis and Man Hours</title>
	<author>Anonymous</author>
	<datestamp>1265742780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><a href="http://en.wikipedia.org/wiki/Function\_point" title="wikipedia.org">http://en.wikipedia.org/wiki/Function\_point</a> [wikipedia.org]
<a href="http://devdaily.com/FunctionPoints/" title="devdaily.com">http://devdaily.com/FunctionPoints/</a> [devdaily.com]</htmltext>
<tokenext>http : //en.wikipedia.org/wiki/Function \ _point [ wikipedia.org ] http : //devdaily.com/FunctionPoints/ [ devdaily.com ]</tokentext>
<sentencetext>http://en.wikipedia.org/wiki/Function\_point [wikipedia.org]
http://devdaily.com/FunctionPoints/ [devdaily.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075892</id>
	<title>we use scrum/invest stories</title>
	<author>Surt</author>
	<datestamp>1265745420000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>And probably more importantly than estimating accurately, we aim to estimate consistently. Then we compare actual rate of feature completion against the estimated size of remaining features. We've landed within a single sprint of estimates over a year long release with 20+ developers.</p></htmltext>
<tokenext>And probably more importantly than estimating accurately , we aim to estimate consistently .
Then we compare actual rate of feature completion against the estimated size of remaining features .
We 've landed within a single sprint of estimates over a year long release with 20 + developers .</tokentext>
<sentencetext>And probably more importantly than estimating accurately, we aim to estimate consistently.
Then we compare actual rate of feature completion against the estimated size of remaining features.
We've landed within a single sprint of estimates over a year long release with 20+ developers.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076096</id>
	<title>Oxymoron</title>
	<author>fredrated</author>
	<datestamp>1265745960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>'Accurate' and 'estimate' do not go together well, an estimate is not accurate.</htmltext>
<tokenext>'Accurate ' and 'estimate ' do not go together well , an estimate is not accurate .</tokentext>
<sentencetext>'Accurate' and 'estimate' do not go together well, an estimate is not accurate.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079266</id>
	<title>From at least 30 years ago - I have the coffee mug</title>
	<author>rawkstar</author>
	<datestamp>1265715540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"GOLUB'S LAW OF COMPUTERDOM: A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long."

Seriously, I was once told a project absolutely had to be done on time, within 8 months, and to do what ever I needed to get it done. the previous project had been three times the scheduled completion time. When it was done on time I was slagged for being 10\% over a "budget" I had never seen. Fzck the suits! No wonder 80\% of "business" is nose to butt.</htmltext>
<tokenext>" GOLUB 'S LAW OF COMPUTERDOM : A carelessly planned project takes three times longer to complete than expected ; a carefully planned project takes only twice as long .
" Seriously , I was once told a project absolutely had to be done on time , within 8 months , and to do what ever I needed to get it done .
the previous project had been three times the scheduled completion time .
When it was done on time I was slagged for being 10 \ % over a " budget " I had never seen .
Fzck the suits !
No wonder 80 \ % of " business " is nose to butt .</tokentext>
<sentencetext>"GOLUB'S LAW OF COMPUTERDOM: A carelessly planned project takes three times longer to complete than expected; a carefully planned project takes only twice as long.
"

Seriously, I was once told a project absolutely had to be done on time, within 8 months, and to do what ever I needed to get it done.
the previous project had been three times the scheduled completion time.
When it was done on time I was slagged for being 10\% over a "budget" I had never seen.
Fzck the suits!
No wonder 80\% of "business" is nose to butt.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076542</id>
	<title>We don't.</title>
	<author>sproketboy</author>
	<datestamp>1265747700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>mea culpa</p></htmltext>
<tokenext>mea culpa</tokentext>
<sentencetext>mea culpa</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077954
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079568
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_95</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076190
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079828
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31089880
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076648
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075510
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_86</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075434
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076084
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_59</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075916
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31089262
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_62</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31114656
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_90</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075870
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076914
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082008
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_76</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075916
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078072
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075868
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080154
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075338
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_83</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082784
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075068
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075880
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078106
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079894
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076358
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075338
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076014
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083980
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076428
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077902
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_68</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075816
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078380
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078036
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_84</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075668
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_75</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080852
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078646
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_74</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075838
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_65</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077648
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076922
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083768
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_81</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076152
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083364
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081550
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076306
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076428
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080978
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076650
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076818
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080172
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075866
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079444
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_66</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082476
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_94</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075866
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082658
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083372
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078964
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_73</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076428
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076682
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075418
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081980
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_87</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077358
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080240
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_58</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079902
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_63</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075486
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079592
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075928
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076670
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075816
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076720
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075338
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077544
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075886
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_93</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080254
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31084744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_88</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083542
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078078
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_79</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080528
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_92</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075916
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080880
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076762
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_78</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31085026
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_69</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082256
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_60</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077658
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_85</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077002
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083270
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076318
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31086342
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075378
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078462
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076310
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075364
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081902
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081416
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075816
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076210
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076428
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076682
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078068
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_91</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075610
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076444
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_77</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075616
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077388
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_82</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076088
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_67</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075104
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075266
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077926
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_72</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079948
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075580
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31086818
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076534
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_97</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076726
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075396
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076734
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077358
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080394
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082080
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_96</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076676
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080366
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077954
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081292
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080960
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_64</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075418
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076716
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_89</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082702
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_80</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083628
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_71</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075062
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076376
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075418
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077406
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076568
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31095578
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076680
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_70</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076782
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076316
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_61</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076036
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_02_09_1654200_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076624
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075334
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076914
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082008
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080254
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076534
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080528
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076096
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077002
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083270
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075338
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076014
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076214
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077544
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075054
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31089880
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075870
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075510
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077016
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31085026
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081416
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080960
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31114656
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075378
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078462
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075082
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078036
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075396
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075234
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083628
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075668
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076306
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076922
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079894
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075928
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082476
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080986
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075258
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078122
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075068
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075880
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078106
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075546
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075692
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075070
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075418
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081980
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077406
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076716
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076088
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076316
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083542
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076676
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080366
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075816
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076210
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078380
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076720
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076648
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076428
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076682
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080336
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078068
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077902
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080978
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075702
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082702
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076726
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082784
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31084744
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31086342
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076670
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078892
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083980
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075486
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076358
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076734
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077358
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080394
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082080
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080240
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083768
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075186
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075694
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075050
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075610
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075866
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079444
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082658
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076444
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080852
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076818
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080172
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31082256
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079948
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075886
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075916
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078072
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080880
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31089262
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077324
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076104
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079266
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075062
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076376
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075364
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081902
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075458
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076600
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076276
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075204
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075438
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076624
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076762
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077954
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081292
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079568
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076680
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079902
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077926
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076310
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078964
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076568
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31095578
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075484
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079402
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075150
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075170
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078646
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075580
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31086818
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077648
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079592
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075898
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076650
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31078078
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083372
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077658
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075470
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075868
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31080154
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076330
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075144
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076036
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31081550
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075838
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076190
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31079828
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076378
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076350
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075122
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076782
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076318
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076152
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31083364
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075104
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075266
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075616
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31077388
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_02_09_1654200.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31075434
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_02_09_1654200.31076084
</commentlist>
</conversation>
