<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_03_28_167251</id>
	<title>The Economics of Perfect Software</title>
	<author>Soulskill</author>
	<datestamp>1269798000000</datestamp>
	<htmltext>An anonymous reader writes <i>"This article takes the interesting perspective that <a href="http://www.sigpwned.com/content/economics-perfect-software">leaving bugs in software is good &mdash; little ones, at least</a>. This quote is particularly insightful: 'How do you know whether a bug is big or little? Think about who's going to hit it, and how mad they'll be when they do. If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug. It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way. If your program crashes on launch for a common setup, though, that's a big bug. Lots of people will hit it, and they will all be pissed. ... The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about."</i></htmltext>
<tokenext>An anonymous reader writes " This article takes the interesting perspective that leaving bugs in software is good    little ones , at least .
This quote is particularly insightful : 'How do you know whether a bug is big or little ?
Think about who 's going to hit it , and how mad they 'll be when they do .
If a user who goes through three levels of menus , opens an advanced configuration window , checks three checkboxes , and hits the 'A ' key gets a weird error message for his trouble , that 's a little bug .
It 's buried deep , and when the user hits it , he says 'huh, ' clicks a button , and then goes on his merry way .
If your program crashes on launch for a common setup , though , that 's a big bug .
Lots of people will hit it , and they will all be pissed .
... The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they wo n't care about .
"</tokentext>
<sentencetext>An anonymous reader writes "This article takes the interesting perspective that leaving bugs in software is good — little ones, at least.
This quote is particularly insightful: 'How do you know whether a bug is big or little?
Think about who's going to hit it, and how mad they'll be when they do.
If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.
It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way.
If your program crashes on launch for a common setup, though, that's a big bug.
Lots of people will hit it, and they will all be pissed.
... The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649316</id>
	<title>Re:Well, sure, if you have precognition</title>
	<author>Bigjeff5</author>
	<datestamp>1269806280000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's not hard.</p><p>Bug Report:</p><p>"If I do X, Y, then Z, and sometime in the next 5 seconds do A, B,C, followed by ctrl-shift-A, I get an error message."</p><p>If you've got a million customers, there are maybe 50 who are going to hit that sequence, and all it does is give them an error message without stopping their work in any way.  The effect on the user is practically nill.</p><p>Now, same bug, but for some reason you've buried significant functionality in this sequence that 10\% of your users are going to want to use, it's more important but still a minor bug that doesn't really affect the user's ability to use your software.  It does make your software seem less professional, so maybe you fix it at the next major update.</p><p>One more time, same basic bug, but this time instead of just throwing an error message and continuing like nothing bad happened, it throws an error and then crashes your program.  Worse if it corrupts any saved data.  That's a <i>serious</i> bug, and you want to fix that ASAP and push out a free patch to all your customers as soon as you possibly can.  That's like, work-around-the-clock-to-fix it important, because there is a very good chance you will lose 10\% or more of your customers over it.</p><p><div class="quote"><p>Well, sure, except that this assumes that you are PERFECT in your ability to predict the effect of a bug.</p> </div><p>For 99\% of bugs that you come across before the release, you know exactly how it will affect your customers and exactly how important it is to fix.  Those 1\% are the ones that come out of the blue, they are rare, and they usually don't affect a lot of people.  But sometimes they do.</p><p>However, once you know about a bug (what it is and what it does) it's very easy to determine how it impacts your customers.  What you are thinking of are bugs that you <i>think</i> you understand, but really don't.  That's different, and falls into that rare 1\%.  It's almost like you've found Bug 1, it's common enough that it is something to be a little concerned about, but it doesn't actually do anything so you ship anyway.  What you did not know is that there is a subset of Bug 1, called Bug 1a, which with additional conditions (making it even rarer than Bug 1 itself) is absolutely devastating to your program.</p><p>You missed Bug 1a going out the door, even though you caught Bug 1 but decided it wasn't worth fixing at this time.  Now you have to determine how many people Bug 1a affects, if it is just a handful you can put it off - it isn't worth fixing.  If it's a significant number of people then you'd better think about fixing it soon.</p><p>It's not a difficult process to figure out how much a bug affects your users, but you are definitely not going to catch all the bugs, and that's true for serious bugs that are subsets of minor bugs.</p></div>
	</htmltext>
<tokenext>It 's not hard.Bug Report : " If I do X , Y , then Z , and sometime in the next 5 seconds do A , B,C , followed by ctrl-shift-A , I get an error message .
" If you 've got a million customers , there are maybe 50 who are going to hit that sequence , and all it does is give them an error message without stopping their work in any way .
The effect on the user is practically nill.Now , same bug , but for some reason you 've buried significant functionality in this sequence that 10 \ % of your users are going to want to use , it 's more important but still a minor bug that does n't really affect the user 's ability to use your software .
It does make your software seem less professional , so maybe you fix it at the next major update.One more time , same basic bug , but this time instead of just throwing an error message and continuing like nothing bad happened , it throws an error and then crashes your program .
Worse if it corrupts any saved data .
That 's a serious bug , and you want to fix that ASAP and push out a free patch to all your customers as soon as you possibly can .
That 's like , work-around-the-clock-to-fix it important , because there is a very good chance you will lose 10 \ % or more of your customers over it.Well , sure , except that this assumes that you are PERFECT in your ability to predict the effect of a bug .
For 99 \ % of bugs that you come across before the release , you know exactly how it will affect your customers and exactly how important it is to fix .
Those 1 \ % are the ones that come out of the blue , they are rare , and they usually do n't affect a lot of people .
But sometimes they do.However , once you know about a bug ( what it is and what it does ) it 's very easy to determine how it impacts your customers .
What you are thinking of are bugs that you think you understand , but really do n't .
That 's different , and falls into that rare 1 \ % .
It 's almost like you 've found Bug 1 , it 's common enough that it is something to be a little concerned about , but it does n't actually do anything so you ship anyway .
What you did not know is that there is a subset of Bug 1 , called Bug 1a , which with additional conditions ( making it even rarer than Bug 1 itself ) is absolutely devastating to your program.You missed Bug 1a going out the door , even though you caught Bug 1 but decided it was n't worth fixing at this time .
Now you have to determine how many people Bug 1a affects , if it is just a handful you can put it off - it is n't worth fixing .
If it 's a significant number of people then you 'd better think about fixing it soon.It 's not a difficult process to figure out how much a bug affects your users , but you are definitely not going to catch all the bugs , and that 's true for serious bugs that are subsets of minor bugs .</tokentext>
<sentencetext>It's not hard.Bug Report:"If I do X, Y, then Z, and sometime in the next 5 seconds do A, B,C, followed by ctrl-shift-A, I get an error message.
"If you've got a million customers, there are maybe 50 who are going to hit that sequence, and all it does is give them an error message without stopping their work in any way.
The effect on the user is practically nill.Now, same bug, but for some reason you've buried significant functionality in this sequence that 10\% of your users are going to want to use, it's more important but still a minor bug that doesn't really affect the user's ability to use your software.
It does make your software seem less professional, so maybe you fix it at the next major update.One more time, same basic bug, but this time instead of just throwing an error message and continuing like nothing bad happened, it throws an error and then crashes your program.
Worse if it corrupts any saved data.
That's a serious bug, and you want to fix that ASAP and push out a free patch to all your customers as soon as you possibly can.
That's like, work-around-the-clock-to-fix it important, because there is a very good chance you will lose 10\% or more of your customers over it.Well, sure, except that this assumes that you are PERFECT in your ability to predict the effect of a bug.
For 99\% of bugs that you come across before the release, you know exactly how it will affect your customers and exactly how important it is to fix.
Those 1\% are the ones that come out of the blue, they are rare, and they usually don't affect a lot of people.
But sometimes they do.However, once you know about a bug (what it is and what it does) it's very easy to determine how it impacts your customers.
What you are thinking of are bugs that you think you understand, but really don't.
That's different, and falls into that rare 1\%.
It's almost like you've found Bug 1, it's common enough that it is something to be a little concerned about, but it doesn't actually do anything so you ship anyway.
What you did not know is that there is a subset of Bug 1, called Bug 1a, which with additional conditions (making it even rarer than Bug 1 itself) is absolutely devastating to your program.You missed Bug 1a going out the door, even though you caught Bug 1 but decided it wasn't worth fixing at this time.
Now you have to determine how many people Bug 1a affects, if it is just a handful you can put it off - it isn't worth fixing.
If it's a significant number of people then you'd better think about fixing it soon.It's not a difficult process to figure out how much a bug affects your users, but you are definitely not going to catch all the bugs, and that's true for serious bugs that are subsets of minor bugs.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648698</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649694</id>
	<title>Another reason</title>
	<author>Anonymous</author>
	<datestamp>1269809340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Large corporations often like to buy "Enterprise" software with support contracts.   If the software works perfectly, nobody is happy:  the IT staff responsible for supporting the software have less to do and worry about their job security; IT management does not get anything demonstrable from the support payment; the vendor's support staff do not get a chance to learn how the software is being deployed in the field; the vendor's management have a high cost-per-ticket on their support line.   Nobody builds relationships.  If bugs cause small or medium problems, but the problems are handled well, corporate customers actually like this:  rationally, it's a successful test of the support model giving reassurance that a big problem might be handled well too; irrationally, people feel better about a company after it handles a problem extremely well - e.g. quick resolution and apologies - than they would if the problem never arose in the first place.</p></htmltext>
<tokenext>Large corporations often like to buy " Enterprise " software with support contracts .
If the software works perfectly , nobody is happy : the IT staff responsible for supporting the software have less to do and worry about their job security ; IT management does not get anything demonstrable from the support payment ; the vendor 's support staff do not get a chance to learn how the software is being deployed in the field ; the vendor 's management have a high cost-per-ticket on their support line .
Nobody builds relationships .
If bugs cause small or medium problems , but the problems are handled well , corporate customers actually like this : rationally , it 's a successful test of the support model giving reassurance that a big problem might be handled well too ; irrationally , people feel better about a company after it handles a problem extremely well - e.g .
quick resolution and apologies - than they would if the problem never arose in the first place .</tokentext>
<sentencetext>Large corporations often like to buy "Enterprise" software with support contracts.
If the software works perfectly, nobody is happy:  the IT staff responsible for supporting the software have less to do and worry about their job security; IT management does not get anything demonstrable from the support payment; the vendor's support staff do not get a chance to learn how the software is being deployed in the field; the vendor's management have a high cost-per-ticket on their support line.
Nobody builds relationships.
If bugs cause small or medium problems, but the problems are handled well, corporate customers actually like this:  rationally, it's a successful test of the support model giving reassurance that a big problem might be handled well too; irrationally, people feel better about a company after it handles a problem extremely well - e.g.
quick resolution and apologies - than they would if the problem never arose in the first place.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649138</id>
	<title>insight on.</title>
	<author>eexaa</author>
	<datestamp>1269805080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I might misunderstand the actual message, but still, I see a small benefit for leaving minor bugs around:</p><p>Imagine a long-running project (just like cobol+finances). Several core programmers go away, and you have a big heap of code that no one can maintain, therefore you will need to rewrite all your software "as soon as possible" and spend huge amount of money on migration.</p><p>If you leave a tiny annoying thingy there, it will inevitably attract hackers that:</p><p>a] formulate the real nature of a bug (gaining insight on how it really works)</p><p>b] eventually hack through all the code and apply the oneliner (slowly becoming experts on the topic. Happens only if source is available to users/admins)</p><p>In short, 'annoying non-critical bugs produce maintainers'.</p><p>(well, maybe I am a development lunatic)</p></htmltext>
<tokenext>I might misunderstand the actual message , but still , I see a small benefit for leaving minor bugs around : Imagine a long-running project ( just like cobol + finances ) .
Several core programmers go away , and you have a big heap of code that no one can maintain , therefore you will need to rewrite all your software " as soon as possible " and spend huge amount of money on migration.If you leave a tiny annoying thingy there , it will inevitably attract hackers that : a ] formulate the real nature of a bug ( gaining insight on how it really works ) b ] eventually hack through all the code and apply the oneliner ( slowly becoming experts on the topic .
Happens only if source is available to users/admins ) In short , 'annoying non-critical bugs produce maintainers' .
( well , maybe I am a development lunatic )</tokentext>
<sentencetext>I might misunderstand the actual message, but still, I see a small benefit for leaving minor bugs around:Imagine a long-running project (just like cobol+finances).
Several core programmers go away, and you have a big heap of code that no one can maintain, therefore you will need to rewrite all your software "as soon as possible" and spend huge amount of money on migration.If you leave a tiny annoying thingy there, it will inevitably attract hackers that:a] formulate the real nature of a bug (gaining insight on how it really works)b] eventually hack through all the code and apply the oneliner (slowly becoming experts on the topic.
Happens only if source is available to users/admins)In short, 'annoying non-critical bugs produce maintainers'.
(well, maybe I am a development lunatic)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650750</id>
	<title>How do you know which is which, though?</title>
	<author>Moraelin</author>
	<datestamp>1269773880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My question, though, would be how do you know which is which?</p><p>And before I even start, a thing I learned pretty early is that if you aim low, you'll hit even lower. If you aim for a B or C in school, 'cause, well, no point in fretting over not being exactly perfect, you start getting D's and lower. I should know, I actually tried that philosophy for half a year or so, before realizing that lesson. Partially because life doesn't throw you exactly the curve you were expecting, and partially because once you started making excuses and rationalizations, well, stretching the excuse just a little more or rationalizing a little further kinda comes naturally.</p><p>Same here.</p><p>But really, how do you know what you've \_missed\_? Because half the trouble with bugs is finding them in the first place. Something you didn't find (because finding the last little bug isn't worth it, right?) how do you know if it's a big one or a small one?</p><p>And if you found it and decided to ignore it, how do you know if that small bug isn't a symptom of something bigger? How do you know if that spurious failure to save the settings on the third page of a dialog buried 6 ft deep in menus, isn't symptomatic of a problem in a library function that is also called somewhere else too? How do you know if the same clever function -- or a version of the same clever hack from the same programmer -- isn't also used, say, when saving that 30 page form that the user has been editing? That's a big bug, especially when you deal with contracts worth hundreds of millions.</p><p>I mean, after all, the whole point is that you don't know exactly what line or method is causing it, or you'd have fixed it. So how do you know in which category to file the \_unknown\_?</p></htmltext>
<tokenext>My question , though , would be how do you know which is which ? And before I even start , a thing I learned pretty early is that if you aim low , you 'll hit even lower .
If you aim for a B or C in school , 'cause , well , no point in fretting over not being exactly perfect , you start getting D 's and lower .
I should know , I actually tried that philosophy for half a year or so , before realizing that lesson .
Partially because life does n't throw you exactly the curve you were expecting , and partially because once you started making excuses and rationalizations , well , stretching the excuse just a little more or rationalizing a little further kinda comes naturally.Same here.But really , how do you know what you 've \ _missed \ _ ?
Because half the trouble with bugs is finding them in the first place .
Something you did n't find ( because finding the last little bug is n't worth it , right ?
) how do you know if it 's a big one or a small one ? And if you found it and decided to ignore it , how do you know if that small bug is n't a symptom of something bigger ?
How do you know if that spurious failure to save the settings on the third page of a dialog buried 6 ft deep in menus , is n't symptomatic of a problem in a library function that is also called somewhere else too ?
How do you know if the same clever function -- or a version of the same clever hack from the same programmer -- is n't also used , say , when saving that 30 page form that the user has been editing ?
That 's a big bug , especially when you deal with contracts worth hundreds of millions.I mean , after all , the whole point is that you do n't know exactly what line or method is causing it , or you 'd have fixed it .
So how do you know in which category to file the \ _unknown \ _ ?</tokentext>
<sentencetext>My question, though, would be how do you know which is which?And before I even start, a thing I learned pretty early is that if you aim low, you'll hit even lower.
If you aim for a B or C in school, 'cause, well, no point in fretting over not being exactly perfect, you start getting D's and lower.
I should know, I actually tried that philosophy for half a year or so, before realizing that lesson.
Partially because life doesn't throw you exactly the curve you were expecting, and partially because once you started making excuses and rationalizations, well, stretching the excuse just a little more or rationalizing a little further kinda comes naturally.Same here.But really, how do you know what you've \_missed\_?
Because half the trouble with bugs is finding them in the first place.
Something you didn't find (because finding the last little bug isn't worth it, right?
) how do you know if it's a big one or a small one?And if you found it and decided to ignore it, how do you know if that small bug isn't a symptom of something bigger?
How do you know if that spurious failure to save the settings on the third page of a dialog buried 6 ft deep in menus, isn't symptomatic of a problem in a library function that is also called somewhere else too?
How do you know if the same clever function -- or a version of the same clever hack from the same programmer -- isn't also used, say, when saving that 30 page form that the user has been editing?
That's a big bug, especially when you deal with contracts worth hundreds of millions.I mean, after all, the whole point is that you don't know exactly what line or method is causing it, or you'd have fixed it.
So how do you know in which category to file the \_unknown\_?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648958</id>
	<title>Re:How is this news?</title>
	<author>Anonymous</author>
	<datestamp>1269803820000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>I leave in all kinds of weird bugs that only I can fix, just to guarantee my future job. I'm betting big software companies relying on people buying the new versions of their products do the same. After all, there's no reason for upgrading perfect software, is there?</p></htmltext>
<tokenext>I leave in all kinds of weird bugs that only I can fix , just to guarantee my future job .
I 'm betting big software companies relying on people buying the new versions of their products do the same .
After all , there 's no reason for upgrading perfect software , is there ?</tokentext>
<sentencetext>I leave in all kinds of weird bugs that only I can fix, just to guarantee my future job.
I'm betting big software companies relying on people buying the new versions of their products do the same.
After all, there's no reason for upgrading perfect software, is there?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649628</id>
	<title>Re:Maybe.</title>
	<author>Bigjeff5</author>
	<datestamp>1269808800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>When the cost of fixing the bug is very low, it should be a no-brainer to do it.</p></div><p>For large programs especially, but with any program really, there is a minimum cost to fix any bug.  Most of them involve time, but there are other costs as well.  Because of this, there are bugs that are small enough that never make sense fixing, unless you are already fixing a larger bug and fixing the small bug at the same time adds minimal extra cost.  If there are no more large bugs to defray the cost of fixing the small bugs, it may never make sense to fix the small bugs if they are small enough.</p></div>
	</htmltext>
<tokenext>When the cost of fixing the bug is very low , it should be a no-brainer to do it.For large programs especially , but with any program really , there is a minimum cost to fix any bug .
Most of them involve time , but there are other costs as well .
Because of this , there are bugs that are small enough that never make sense fixing , unless you are already fixing a larger bug and fixing the small bug at the same time adds minimal extra cost .
If there are no more large bugs to defray the cost of fixing the small bugs , it may never make sense to fix the small bugs if they are small enough .</tokentext>
<sentencetext>When the cost of fixing the bug is very low, it should be a no-brainer to do it.For large programs especially, but with any program really, there is a minimum cost to fix any bug.
Most of them involve time, but there are other costs as well.
Because of this, there are bugs that are small enough that never make sense fixing, unless you are already fixing a larger bug and fixing the small bug at the same time adds minimal extra cost.
If there are no more large bugs to defray the cost of fixing the small bugs, it may never make sense to fix the small bugs if they are small enough.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648750</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648700</id>
	<title>probably good idea; definitely bad example</title>
	<author>pem</author>
	<datestamp>1269802200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p>If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.</p></div>
</blockquote><p>
When I'm trying very hard to make a program do what I want it to, the more hoops I have to jump through for every iteration of trying to make it work, the madder I get.  So, the fact that the software has dark corners that you can get to like this is already a major strike against it...</p></div>
	</htmltext>
<tokenext>If a user who goes through three levels of menus , opens an advanced configuration window , checks three checkboxes , and hits the 'A ' key gets a weird error message for his trouble , that 's a little bug .
When I 'm trying very hard to make a program do what I want it to , the more hoops I have to jump through for every iteration of trying to make it work , the madder I get .
So , the fact that the software has dark corners that you can get to like this is already a major strike against it.. .</tokentext>
<sentencetext>If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.
When I'm trying very hard to make a program do what I want it to, the more hoops I have to jump through for every iteration of trying to make it work, the madder I get.
So, the fact that the software has dark corners that you can get to like this is already a major strike against it...
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</id>
	<title>How is this news?</title>
	<author>Dragoniz3r</author>
	<datestamp>1269801660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>Diminishing returns applies to programming too... big surprise...</htmltext>
<tokenext>Diminishing returns applies to programming too... big surprise.. .</tokentext>
<sentencetext>Diminishing returns applies to programming too... big surprise...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649874</id>
	<title>Says who?</title>
	<author>Chris Newton</author>
	<datestamp>1269767400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>You cant afford perfect software.</p></div><p>The problem with that argument is that there is little evidence that it is actually true.</p><p>Let&rsquo;s assume that by &ldquo;perfect&rdquo; what we really mean is &ldquo;much better than most software today&rdquo;, since no-one has yet worked out how to write literally perfect software. In that case, the difference in cost (by the time you take into account the full lifetime, including maintenance costs) seems to be rather small: it's not that great even during initial development, and the lower maintenance costs make it rather efficient to put more up-front effort into making less buggy code.</p></div>
	</htmltext>
<tokenext>You cant afford perfect software.The problem with that argument is that there is little evidence that it is actually true.Let    s assume that by    perfect    what we really mean is    much better than most software today    , since no-one has yet worked out how to write literally perfect software .
In that case , the difference in cost ( by the time you take into account the full lifetime , including maintenance costs ) seems to be rather small : it 's not that great even during initial development , and the lower maintenance costs make it rather efficient to put more up-front effort into making less buggy code .</tokentext>
<sentencetext>You cant afford perfect software.The problem with that argument is that there is little evidence that it is actually true.Let’s assume that by “perfect” what we really mean is “much better than most software today”, since no-one has yet worked out how to write literally perfect software.
In that case, the difference in cost (by the time you take into account the full lifetime, including maintenance costs) seems to be rather small: it's not that great even during initial development, and the lower maintenance costs make it rather efficient to put more up-front effort into making less buggy code.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648626</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651068</id>
	<title>Re:How is this news?</title>
	<author>Anonymous</author>
	<datestamp>1269775680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>My experience is that serious errors in software are not coding problems but are incorrect, inconsistent or unspecified requirements. Computer programming is in some sense a trivial mechanical task that will eventually be entirely done by the computers themselves.</p></htmltext>
<tokenext>My experience is that serious errors in software are not coding problems but are incorrect , inconsistent or unspecified requirements .
Computer programming is in some sense a trivial mechanical task that will eventually be entirely done by the computers themselves .</tokentext>
<sentencetext>My experience is that serious errors in software are not coding problems but are incorrect, inconsistent or unspecified requirements.
Computer programming is in some sense a trivial mechanical task that will eventually be entirely done by the computers themselves.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648864</id>
	<title>Clear cut?</title>
	<author>Anonymous</author>
	<datestamp>1269803160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I agree with what you are saying, but will the economic v. code perfection decision always be clear cut? Could lead to a slippery slope...</p></htmltext>
<tokenext>I agree with what you are saying , but will the economic v. code perfection decision always be clear cut ?
Could lead to a slippery slope.. .</tokentext>
<sentencetext>I agree with what you are saying, but will the economic v. code perfection decision always be clear cut?
Could lead to a slippery slope...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31653010</id>
	<title>Re:How is this news?</title>
	<author>dudpixel</author>
	<datestamp>1269794700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I find its far easier not to put the bugs in in the first place.  If I dont put them in, then I dont have to waste time looking for where I put them later...</p><p>seriously though, I do find that testing each feature as I add it in goes a long way towards bug-free code.</p></htmltext>
<tokenext>I find its far easier not to put the bugs in in the first place .
If I dont put them in , then I dont have to waste time looking for where I put them later...seriously though , I do find that testing each feature as I add it in goes a long way towards bug-free code .</tokentext>
<sentencetext>I find its far easier not to put the bugs in in the first place.
If I dont put them in, then I dont have to waste time looking for where I put them later...seriously though, I do find that testing each feature as I add it in goes a long way towards bug-free code.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648958</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649450</id>
	<title>Doesn't sound like a little bug...</title>
	<author>argent</author>
	<datestamp>1269807360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i> If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.</i></p><p>1. If that error message refers to "H-Tilt", then that's a big bug no matter how many levels of menus you go through.</p><p>2. If a user can provide a reliably reproducible test case like that for the bug, then it's one you should have caught in testing.</p></htmltext>
<tokenext>If a user who goes through three levels of menus , opens an advanced configuration window , checks three checkboxes , and hits the 'A ' key gets a weird error message for his trouble , that 's a little bug.1 .
If that error message refers to " H-Tilt " , then that 's a big bug no matter how many levels of menus you go through.2 .
If a user can provide a reliably reproducible test case like that for the bug , then it 's one you should have caught in testing .</tokentext>
<sentencetext> If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.1.
If that error message refers to "H-Tilt", then that's a big bug no matter how many levels of menus you go through.2.
If a user can provide a reliably reproducible test case like that for the bug, then it's one you should have caught in testing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648910</id>
	<title>The core argument does make sense.</title>
	<author>Max Romantschuk</author>
	<datestamp>1269803460000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Sometimes it's better to ship a product and deliver it to 95\% of the user base instead of having everyone wait because 5\% wants feature X which is broken.</p><p>But there is the option to disable feature X, so rather than knowingly ship with bugs you can often have the program show a notice that this feature is disabled or something like that.</p><p>Generally when building software you'll have "Quickly", "Lots of features" and "Bug free". Depending on the software and project stage you'll want to strike a different balance. Releasing an alpha which has lots of features quickly with loads of bugs is OK. Releasing a final release of a program handling financial transactions with loads of bugs is never OK.</p><p>But yes, it's a question of economics, and what makes sense for a given project at a given time.</p></htmltext>
<tokenext>Sometimes it 's better to ship a product and deliver it to 95 \ % of the user base instead of having everyone wait because 5 \ % wants feature X which is broken.But there is the option to disable feature X , so rather than knowingly ship with bugs you can often have the program show a notice that this feature is disabled or something like that.Generally when building software you 'll have " Quickly " , " Lots of features " and " Bug free " .
Depending on the software and project stage you 'll want to strike a different balance .
Releasing an alpha which has lots of features quickly with loads of bugs is OK. Releasing a final release of a program handling financial transactions with loads of bugs is never OK.But yes , it 's a question of economics , and what makes sense for a given project at a given time .</tokentext>
<sentencetext>Sometimes it's better to ship a product and deliver it to 95\% of the user base instead of having everyone wait because 5\% wants feature X which is broken.But there is the option to disable feature X, so rather than knowingly ship with bugs you can often have the program show a notice that this feature is disabled or something like that.Generally when building software you'll have "Quickly", "Lots of features" and "Bug free".
Depending on the software and project stage you'll want to strike a different balance.
Releasing an alpha which has lots of features quickly with loads of bugs is OK. Releasing a final release of a program handling financial transactions with loads of bugs is never OK.But yes, it's a question of economics, and what makes sense for a given project at a given time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649790</id>
	<title>The bugs you are not aware of are the worst ones</title>
	<author>Anonymous</author>
	<datestamp>1269766800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Ask Toyota. But there is no need to despair. Toyota software researchers or anybody else who writes safety-critical applications should read this: <a href="http://rebelscience.blogspot.com/2010/03/how-to-construct-100-bug-free-software.html" title="blogspot.com" rel="nofollow">How to Construct 100\% Bug-Free Software</a> [blogspot.com]. It can be done but we will need to change to a synchronous and reactive software model.</p></htmltext>
<tokenext>Ask Toyota .
But there is no need to despair .
Toyota software researchers or anybody else who writes safety-critical applications should read this : How to Construct 100 \ % Bug-Free Software [ blogspot.com ] .
It can be done but we will need to change to a synchronous and reactive software model .</tokentext>
<sentencetext>Ask Toyota.
But there is no need to despair.
Toyota software researchers or anybody else who writes safety-critical applications should read this: How to Construct 100\% Bug-Free Software [blogspot.com].
It can be done but we will need to change to a synchronous and reactive software model.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650494</id>
	<title>Re:How is this news?</title>
	<author>Anonymous</author>
	<datestamp>1269772200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Oft times fixing the little bug cures the big mysterious one, though.</p></htmltext>
<tokenext>Oft times fixing the little bug cures the big mysterious one , though .</tokentext>
<sentencetext>Oft times fixing the little bug cures the big mysterious one, though.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649066</id>
	<title>Duh.</title>
	<author>Vellmont</author>
	<datestamp>1269804600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Isn't this how people ACTUALLY write software already?  Resources aren't infinite, and unless you're NASA writing code for the space shuttle, all bugs don't have to be fixed.  I learned about triage and fixing the "big bugs" 15 years ago in school and it was certainly common practice in the industry then.</p><p>I was going to say "what a stupid article, everyone already knows this".  But judging from the responses I guess everyone doesn't.</p></htmltext>
<tokenext>Is n't this how people ACTUALLY write software already ?
Resources are n't infinite , and unless you 're NASA writing code for the space shuttle , all bugs do n't have to be fixed .
I learned about triage and fixing the " big bugs " 15 years ago in school and it was certainly common practice in the industry then.I was going to say " what a stupid article , everyone already knows this " .
But judging from the responses I guess everyone does n't .</tokentext>
<sentencetext>Isn't this how people ACTUALLY write software already?
Resources aren't infinite, and unless you're NASA writing code for the space shuttle, all bugs don't have to be fixed.
I learned about triage and fixing the "big bugs" 15 years ago in school and it was certainly common practice in the industry then.I was going to say "what a stupid article, everyone already knows this".
But judging from the responses I guess everyone doesn't.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649334</id>
	<title>Re:probably good idea; definitely bad example</title>
	<author>Bigjeff5</author>
	<datestamp>1269806400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not if it is some obscure functionality that hardly anybody is going to need.  If you have a lot of features, that's the only way to do it.</p><p>Sure, you could make your program do less, but why the hell would you want to do that?</p></htmltext>
<tokenext>Not if it is some obscure functionality that hardly anybody is going to need .
If you have a lot of features , that 's the only way to do it.Sure , you could make your program do less , but why the hell would you want to do that ?</tokentext>
<sentencetext>Not if it is some obscure functionality that hardly anybody is going to need.
If you have a lot of features, that's the only way to do it.Sure, you could make your program do less, but why the hell would you want to do that?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648700</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655778</id>
	<title>Summary</title>
	<author>fulldecent</author>
	<datestamp>1269871020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt;&gt; "This article takes the interesting perspective that leaving bugs in software is good &mdash; little ones, at least. This quote is particularly insightful: 'How do you know whether a bug is big or little? Think about who's going to hit it, and how mad they'll be when they do. If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug. It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way. If your program crashes on launch for a common setup, though, that's a big bug. Lots of people will hit it, and they will all be pissed.<nobr> <wbr></nobr>... The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about."</p><p>So... in other words, meh</p></div>
	</htmltext>
<tokenext>&gt; &gt; " This article takes the interesting perspective that leaving bugs in software is good    little ones , at least .
This quote is particularly insightful : 'How do you know whether a bug is big or little ?
Think about who 's going to hit it , and how mad they 'll be when they do .
If a user who goes through three levels of menus , opens an advanced configuration window , checks three checkboxes , and hits the 'A ' key gets a weird error message for his trouble , that 's a little bug .
It 's buried deep , and when the user hits it , he says 'huh, ' clicks a button , and then goes on his merry way .
If your program crashes on launch for a common setup , though , that 's a big bug .
Lots of people will hit it , and they will all be pissed .
... The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they wo n't care about. " So.. .
in other words , meh</tokentext>
<sentencetext>&gt;&gt; "This article takes the interesting perspective that leaving bugs in software is good — little ones, at least.
This quote is particularly insightful: 'How do you know whether a bug is big or little?
Think about who's going to hit it, and how mad they'll be when they do.
If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.
It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way.
If your program crashes on launch for a common setup, though, that's a big bug.
Lots of people will hit it, and they will all be pissed.
... The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about."So...
in other words, meh
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649042</id>
	<title>This applies to everything really...</title>
	<author>Anonymous</author>
	<datestamp>1269804420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Creating a 100\% perfect product is just a terrible idea for business.</p><p>Of course, in software, creating a perfect product is hardly an achievable thing to do, especially if you are actively working on it.<br>Whether it is adding new features, releasing optimizations for functionality X, or just some bug fixes, you shouldn't really ever be able to create anything "perfect".<br>If you somehow managed to create something perfect, then you already never had much scope for the product in question.</p><p>I use a simple example, PowerMenu for Windows adds 4 new menu items on all windows context menus to change priority and transparency, set it Always On Top or Minimize to the system tray.<br>It was built with Windows XP and below in mind. It worked and it worked well.  You can't really do much else with it.  (well personally i think it would be nice to have had the ability to minimize to the powermenu tray icon rather than clog up the system tray)<br>Okay, my example wasn't good, sue me.<br>But you get the idea... right..?</p></htmltext>
<tokenext>Creating a 100 \ % perfect product is just a terrible idea for business.Of course , in software , creating a perfect product is hardly an achievable thing to do , especially if you are actively working on it.Whether it is adding new features , releasing optimizations for functionality X , or just some bug fixes , you should n't really ever be able to create anything " perfect " .If you somehow managed to create something perfect , then you already never had much scope for the product in question.I use a simple example , PowerMenu for Windows adds 4 new menu items on all windows context menus to change priority and transparency , set it Always On Top or Minimize to the system tray.It was built with Windows XP and below in mind .
It worked and it worked well .
You ca n't really do much else with it .
( well personally i think it would be nice to have had the ability to minimize to the powermenu tray icon rather than clog up the system tray ) Okay , my example was n't good , sue me.But you get the idea... right.. ?</tokentext>
<sentencetext>Creating a 100\% perfect product is just a terrible idea for business.Of course, in software, creating a perfect product is hardly an achievable thing to do, especially if you are actively working on it.Whether it is adding new features, releasing optimizations for functionality X, or just some bug fixes, you shouldn't really ever be able to create anything "perfect".If you somehow managed to create something perfect, then you already never had much scope for the product in question.I use a simple example, PowerMenu for Windows adds 4 new menu items on all windows context menus to change priority and transparency, set it Always On Top or Minimize to the system tray.It was built with Windows XP and below in mind.
It worked and it worked well.
You can't really do much else with it.
(well personally i think it would be nice to have had the ability to minimize to the powermenu tray icon rather than clog up the system tray)Okay, my example wasn't good, sue me.But you get the idea... right..?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648748</id>
	<title>Hitchhiker's Guide to the Galaxy</title>
	<author>Anonymous</author>
	<datestamp>1269802440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The Economics of Prefect Software.</p></htmltext>
<tokenext>The Economics of Prefect Software .</tokentext>
<sentencetext>The Economics of Prefect Software.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651716</id>
	<title>craftsmanship in code</title>
	<author>cdn-programmer</author>
	<datestamp>1269781020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>When I first started programming they liked to compare programming to building a house.  I had to point out that its not like building a house.  With programming you can start from the top and go down and you can start at the bottom and go up and you can start at the east, west, north and south too.  You can build the parts in any order.</p><p>However there is an aspect of programming which is akin to house building and this is the idea of the framing carpenters and the finishing carpenters.</p><p>Who here wants to use a framing carpenter and his techniques of chopping off a 2x4 with a hand help skill saw to the techniques of a finishing carpenter laying a hardwood floor who uses a $1000 sliding compound miter saw?</p><p>You see every one of those cracks and bad cuts cannot be fixed later.  The whole floor has to be torn out and done right.</p><p>In house building the miss-cuts behind the drywall often won't be seen unless the job is so badly done that main support beams are left out - and I've actually seen this done!</p><p>In programming the cracks will become apparent.  These will be things like error codes not checked and code to handle unlikely cases not being tested.  In windows 95 for instance we found that one could shut a SCSI disc drive off while the operating system was accessing it and there were no errors or warnings... it just went to normal end of job!  Now that is crappy coding if anyone asks me!</p><p>It is much cheaper to write software to do the job right the first time.  This makes later debugging much easier to do because the rest of the system can be trusted.</p></htmltext>
<tokenext>When I first started programming they liked to compare programming to building a house .
I had to point out that its not like building a house .
With programming you can start from the top and go down and you can start at the bottom and go up and you can start at the east , west , north and south too .
You can build the parts in any order.However there is an aspect of programming which is akin to house building and this is the idea of the framing carpenters and the finishing carpenters.Who here wants to use a framing carpenter and his techniques of chopping off a 2x4 with a hand help skill saw to the techniques of a finishing carpenter laying a hardwood floor who uses a $ 1000 sliding compound miter saw ? You see every one of those cracks and bad cuts can not be fixed later .
The whole floor has to be torn out and done right.In house building the miss-cuts behind the drywall often wo n't be seen unless the job is so badly done that main support beams are left out - and I 've actually seen this done ! In programming the cracks will become apparent .
These will be things like error codes not checked and code to handle unlikely cases not being tested .
In windows 95 for instance we found that one could shut a SCSI disc drive off while the operating system was accessing it and there were no errors or warnings... it just went to normal end of job !
Now that is crappy coding if anyone asks me ! It is much cheaper to write software to do the job right the first time .
This makes later debugging much easier to do because the rest of the system can be trusted .</tokentext>
<sentencetext>When I first started programming they liked to compare programming to building a house.
I had to point out that its not like building a house.
With programming you can start from the top and go down and you can start at the bottom and go up and you can start at the east, west, north and south too.
You can build the parts in any order.However there is an aspect of programming which is akin to house building and this is the idea of the framing carpenters and the finishing carpenters.Who here wants to use a framing carpenter and his techniques of chopping off a 2x4 with a hand help skill saw to the techniques of a finishing carpenter laying a hardwood floor who uses a $1000 sliding compound miter saw?You see every one of those cracks and bad cuts cannot be fixed later.
The whole floor has to be torn out and done right.In house building the miss-cuts behind the drywall often won't be seen unless the job is so badly done that main support beams are left out - and I've actually seen this done!In programming the cracks will become apparent.
These will be things like error codes not checked and code to handle unlikely cases not being tested.
In windows 95 for instance we found that one could shut a SCSI disc drive off while the operating system was accessing it and there were no errors or warnings... it just went to normal end of job!
Now that is crappy coding if anyone asks me!It is much cheaper to write software to do the job right the first time.
This makes later debugging much easier to do because the rest of the system can be trusted.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31652300</id>
	<title>The same economics as being a unicorn rancher</title>
	<author>ClosedSource</author>
	<datestamp>1269786960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>After all, they're both mythical beasts.</p></htmltext>
<tokenext>After all , they 're both mythical beasts .</tokentext>
<sentencetext>After all, they're both mythical beasts.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648966</id>
	<title>The Economics of the Perfect Square</title>
	<author>Dunderflute</author>
	<datestamp>1269803880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Did anyone misread the title as "The Economics of the Perfect Square"?</p></htmltext>
<tokenext>Did anyone misread the title as " The Economics of the Perfect Square " ?</tokentext>
<sentencetext>Did anyone misread the title as "The Economics of the Perfect Square"?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648760</id>
	<title>Re:Oh Please</title>
	<author>Lije Baley</author>
	<datestamp>1269802560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Duh, you just outlined the economic rationale.  And b)We'd love to ship something bug free, but even as individuals with all of our time at our discretion we would not waste the rest of lives trying to get the bugs out of something as complex as modern software, so NO we won't do it SOMEDAY either. Maybe Skynet will though...</p></htmltext>
<tokenext>Duh , you just outlined the economic rationale .
And b ) We 'd love to ship something bug free , but even as individuals with all of our time at our discretion we would not waste the rest of lives trying to get the bugs out of something as complex as modern software , so NO we wo n't do it SOMEDAY either .
Maybe Skynet will though.. .</tokentext>
<sentencetext>Duh, you just outlined the economic rationale.
And b)We'd love to ship something bug free, but even as individuals with all of our time at our discretion we would not waste the rest of lives trying to get the bugs out of something as complex as modern software, so NO we won't do it SOMEDAY either.
Maybe Skynet will though...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649482</id>
	<title>A lesson</title>
	<author>BigBadBus</author>
	<datestamp>1269807600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I used to work for a small computer firm in Weybridge, England. Oh, damn it, since it collapsed ten years ago, I may as
well name it: MTA (Computer Consultants) Ltd. We had a project between 1997-9 to write a software demonstrator
for a radar resource manager for the Eurofighter project, for DERA Malvern. The project was divided into two parts,
of which phase 1 went through a successful factory acceptance task. However, a few bugs had been found in the
programme after this, one of them, due to me, was fairly serious. It was a small mathematical error but I produced
a bug in a few mninutes.
<br>Now MTA had gone through a turbulent time, having to sack all of its staff because of the lack of money
and the rehiring them. MTA were annoyed that DERA decided to stall the programme while it did a full evaluation
of the software, rather than go to phase 2, which would have provided money for the coffers. At this point, the only thing keeping MTA afloat was hope for this project and a tiny project. MTA stalled on
delivering the software, saying they would only do so when the software went to phase 2. By the time MTA had backed
down and provided the patch, I had already left. DERA cancelled the project and MTA went bust within the year.
<br>Moral? It doesn't pay to piss off those who pay you.</htmltext>
<tokenext>I used to work for a small computer firm in Weybridge , England .
Oh , damn it , since it collapsed ten years ago , I may as well name it : MTA ( Computer Consultants ) Ltd. We had a project between 1997-9 to write a software demonstrator for a radar resource manager for the Eurofighter project , for DERA Malvern .
The project was divided into two parts , of which phase 1 went through a successful factory acceptance task .
However , a few bugs had been found in the programme after this , one of them , due to me , was fairly serious .
It was a small mathematical error but I produced a bug in a few mninutes .
Now MTA had gone through a turbulent time , having to sack all of its staff because of the lack of money and the rehiring them .
MTA were annoyed that DERA decided to stall the programme while it did a full evaluation of the software , rather than go to phase 2 , which would have provided money for the coffers .
At this point , the only thing keeping MTA afloat was hope for this project and a tiny project .
MTA stalled on delivering the software , saying they would only do so when the software went to phase 2 .
By the time MTA had backed down and provided the patch , I had already left .
DERA cancelled the project and MTA went bust within the year .
Moral ? It does n't pay to piss off those who pay you .</tokentext>
<sentencetext>I used to work for a small computer firm in Weybridge, England.
Oh, damn it, since it collapsed ten years ago, I may as
well name it: MTA (Computer Consultants) Ltd. We had a project between 1997-9 to write a software demonstrator
for a radar resource manager for the Eurofighter project, for DERA Malvern.
The project was divided into two parts,
of which phase 1 went through a successful factory acceptance task.
However, a few bugs had been found in the
programme after this, one of them, due to me, was fairly serious.
It was a small mathematical error but I produced
a bug in a few mninutes.
Now MTA had gone through a turbulent time, having to sack all of its staff because of the lack of money
and the rehiring them.
MTA were annoyed that DERA decided to stall the programme while it did a full evaluation
of the software, rather than go to phase 2, which would have provided money for the coffers.
At this point, the only thing keeping MTA afloat was hope for this project and a tiny project.
MTA stalled on
delivering the software, saying they would only do so when the software went to phase 2.
By the time MTA had backed
down and provided the patch, I had already left.
DERA cancelled the project and MTA went bust within the year.
Moral? It doesn't pay to piss off those who pay you.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649882</id>
	<title>Release when?</title>
	<author>Midnight Thunder</author>
	<datestamp>1269767460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Perfect software is like a perfect person: hard to find. Even if you did find it, then it probably wouldn't be doing things in the way you want it to.</p><p>If I am asked to add a set a features and make it perfect, then I will do the best job I can, but in the end the question to be asked is "do you want perfect software or a deliverable?". Perfect software is also like a derivative, in that you can always get closer to your integer the more you work at it, but still not be there, it simply tends to infinity.</p></htmltext>
<tokenext>Perfect software is like a perfect person : hard to find .
Even if you did find it , then it probably would n't be doing things in the way you want it to.If I am asked to add a set a features and make it perfect , then I will do the best job I can , but in the end the question to be asked is " do you want perfect software or a deliverable ? " .
Perfect software is also like a derivative , in that you can always get closer to your integer the more you work at it , but still not be there , it simply tends to infinity .</tokentext>
<sentencetext>Perfect software is like a perfect person: hard to find.
Even if you did find it, then it probably wouldn't be doing things in the way you want it to.If I am asked to add a set a features and make it perfect, then I will do the best job I can, but in the end the question to be asked is "do you want perfect software or a deliverable?".
Perfect software is also like a derivative, in that you can always get closer to your integer the more you work at it, but still not be there, it simply tends to infinity.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31653408</id>
	<title>I had "one of these" years ago</title>
	<author>flatulus</author>
	<datestamp>1269798900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I had a software package to which I was adding features and there was one nagging, subtle bug that kept me chasing my tail for a couple of weeks.</p><p>I was fairly junior in my career, so you can imagine how I felt when the VP of Software Development called me in for a chat.  He impressed on me how it's really not practical to hold up a product shipment for some "little bug".  There will always be "little bugs", and I needed to get over it and move along.</p><p>I accepted this sage advice (and counted myself lucky that it stopped at that).</p><p>With no particular effort on my part, and quite ironically, I stumbled upon the cause of the bug about a week later and fixed it.  I never mentioned to anyone that I had in fact fixed the "not worth bothering with" bug.  But secretly I was pleased that my work would not suffer from the mandated compromise.</p><p>Of course, this is just the bug I "knew about."<nobr> <wbr></nobr>:-)</p></htmltext>
<tokenext>I had a software package to which I was adding features and there was one nagging , subtle bug that kept me chasing my tail for a couple of weeks.I was fairly junior in my career , so you can imagine how I felt when the VP of Software Development called me in for a chat .
He impressed on me how it 's really not practical to hold up a product shipment for some " little bug " .
There will always be " little bugs " , and I needed to get over it and move along.I accepted this sage advice ( and counted myself lucky that it stopped at that ) .With no particular effort on my part , and quite ironically , I stumbled upon the cause of the bug about a week later and fixed it .
I never mentioned to anyone that I had in fact fixed the " not worth bothering with " bug .
But secretly I was pleased that my work would not suffer from the mandated compromise.Of course , this is just the bug I " knew about .
" : - )</tokentext>
<sentencetext>I had a software package to which I was adding features and there was one nagging, subtle bug that kept me chasing my tail for a couple of weeks.I was fairly junior in my career, so you can imagine how I felt when the VP of Software Development called me in for a chat.
He impressed on me how it's really not practical to hold up a product shipment for some "little bug".
There will always be "little bugs", and I needed to get over it and move along.I accepted this sage advice (and counted myself lucky that it stopped at that).With no particular effort on my part, and quite ironically, I stumbled upon the cause of the bug about a week later and fixed it.
I never mentioned to anyone that I had in fact fixed the "not worth bothering with" bug.
But secretly I was pleased that my work would not suffer from the mandated compromise.Of course, this is just the bug I "knew about.
" :-)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651920</id>
	<title>A bug they won't care about?</title>
	<author>MyBrotherSteve</author>
	<datestamp>1269783180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>" It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way... having a few users hit some bugs they won't care about."

For commercial software that people are paying for, this line of thought is a bit of a misnomer. if that user took the time to go down to that 3rd level menu item, then for THEM, it DOES matter, and they won't say 'huh', they're going to be pissed &amp; wondering why that company would add a feature into the program that doesn't work right. I think the challenge that people in our (I.T.) industry have, is that they don't always realize that most people do not think like we do about software. WE realize that it can't be absolutely perfect, and we understand what programmers do and have to deal with. A normal user who is a plumber, or a teacher, or a doctor, or a student will be less than understanding about functionality that does not work properly. So, it's not about fixing every bug and that it will cost way too much to fix it; it's more about that software companies should look at fixing every bug that they DO know about, and if it looks like that cost will be way too high in comparison to the number of paying customers that might want to use that feature, then they should look at perhaps removing that feature until such time that it can be added back in and also work properly.</htmltext>
<tokenext>" It 's buried deep , and when the user hits it , he says 'huh, ' clicks a button , and then goes on his merry way... having a few users hit some bugs they wo n't care about .
" For commercial software that people are paying for , this line of thought is a bit of a misnomer .
if that user took the time to go down to that 3rd level menu item , then for THEM , it DOES matter , and they wo n't say 'huh ' , they 're going to be pissed &amp; wondering why that company would add a feature into the program that does n't work right .
I think the challenge that people in our ( I.T .
) industry have , is that they do n't always realize that most people do not think like we do about software .
WE realize that it ca n't be absolutely perfect , and we understand what programmers do and have to deal with .
A normal user who is a plumber , or a teacher , or a doctor , or a student will be less than understanding about functionality that does not work properly .
So , it 's not about fixing every bug and that it will cost way too much to fix it ; it 's more about that software companies should look at fixing every bug that they DO know about , and if it looks like that cost will be way too high in comparison to the number of paying customers that might want to use that feature , then they should look at perhaps removing that feature until such time that it can be added back in and also work properly .</tokentext>
<sentencetext>" It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way... having a few users hit some bugs they won't care about.
"

For commercial software that people are paying for, this line of thought is a bit of a misnomer.
if that user took the time to go down to that 3rd level menu item, then for THEM, it DOES matter, and they won't say 'huh', they're going to be pissed &amp; wondering why that company would add a feature into the program that doesn't work right.
I think the challenge that people in our (I.T.
) industry have, is that they don't always realize that most people do not think like we do about software.
WE realize that it can't be absolutely perfect, and we understand what programmers do and have to deal with.
A normal user who is a plumber, or a teacher, or a doctor, or a student will be less than understanding about functionality that does not work properly.
So, it's not about fixing every bug and that it will cost way too much to fix it; it's more about that software companies should look at fixing every bug that they DO know about, and if it looks like that cost will be way too high in comparison to the number of paying customers that might want to use that feature, then they should look at perhaps removing that feature until such time that it can be added back in and also work properly.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648750</id>
	<title>Maybe.</title>
	<author>Anonymous</author>
	<datestamp>1269802440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p>The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about.</p></div></blockquote><p>I think it also depends on how much it costs to remove the bugs.  Often times, the small bugs that people are more likely to accept or tolerate are also very easy to fix.  When the cost of fixing the bug is very low, it should be a no-brainer to do it.  If on the other hand the bug is expensive to fix -- requiring a complete redesign and re-coding, then if the bug is not severe it may well be better to leave it in.</p></div>
	</htmltext>
<tokenext>The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they wo n't care about.I think it also depends on how much it costs to remove the bugs .
Often times , the small bugs that people are more likely to accept or tolerate are also very easy to fix .
When the cost of fixing the bug is very low , it should be a no-brainer to do it .
If on the other hand the bug is expensive to fix -- requiring a complete redesign and re-coding , then if the bug is not severe it may well be better to leave it in .</tokentext>
<sentencetext>The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about.I think it also depends on how much it costs to remove the bugs.
Often times, the small bugs that people are more likely to accept or tolerate are also very easy to fix.
When the cost of fixing the bug is very low, it should be a no-brainer to do it.
If on the other hand the bug is expensive to fix -- requiring a complete redesign and re-coding, then if the bug is not severe it may well be better to leave it in.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650078</id>
	<title>Re:Oh Please</title>
	<author>Anonymous</author>
	<datestamp>1269769260000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>The other thing that might be a possibility... is that software needs to have bugs from the  business end to ensure lucrative service contracts.</p><p>Now this is just pure speculation of course... but I used to a work for networking vendor known for superior customer support... and making mega bugs in the servicing contracts as well.<br>I sat there looking at some ridiculous policies in the software realm that almost seemed to encourage bugs in the code as opposed to writing good software.</p><p>They were throwing code around to various teams... seemed to value programmers who could be tossed onto a project instead of those who wrote good software...</p><p>I left... not my kind of place... I don't like being a janitor cleaning up everything... but lately... I've gone more into technical project management.  You know what customers love... they love seeing lots of engineers giving them attention.<br>So it got me thinking if such policies to encourage buggy software are not just stupid policies, but actually active management policies... to ensure customers are willing to pay for lofty service contracts.<br>Get something that works reasonably well to get things working... but make sure the bug fixing phase never ends... and you never lose service contracts.<br>You never just sell a piece of hardware... like a spoon.</p></htmltext>
<tokenext>The other thing that might be a possibility... is that software needs to have bugs from the business end to ensure lucrative service contracts.Now this is just pure speculation of course... but I used to a work for networking vendor known for superior customer support... and making mega bugs in the servicing contracts as well.I sat there looking at some ridiculous policies in the software realm that almost seemed to encourage bugs in the code as opposed to writing good software.They were throwing code around to various teams... seemed to value programmers who could be tossed onto a project instead of those who wrote good software...I left... not my kind of place... I do n't like being a janitor cleaning up everything... but lately... I 've gone more into technical project management .
You know what customers love... they love seeing lots of engineers giving them attention.So it got me thinking if such policies to encourage buggy software are not just stupid policies , but actually active management policies... to ensure customers are willing to pay for lofty service contracts.Get something that works reasonably well to get things working... but make sure the bug fixing phase never ends... and you never lose service contracts.You never just sell a piece of hardware... like a spoon .</tokentext>
<sentencetext>The other thing that might be a possibility... is that software needs to have bugs from the  business end to ensure lucrative service contracts.Now this is just pure speculation of course... but I used to a work for networking vendor known for superior customer support... and making mega bugs in the servicing contracts as well.I sat there looking at some ridiculous policies in the software realm that almost seemed to encourage bugs in the code as opposed to writing good software.They were throwing code around to various teams... seemed to value programmers who could be tossed onto a project instead of those who wrote good software...I left... not my kind of place... I don't like being a janitor cleaning up everything... but lately... I've gone more into technical project management.
You know what customers love... they love seeing lots of engineers giving them attention.So it got me thinking if such policies to encourage buggy software are not just stupid policies, but actually active management policies... to ensure customers are willing to pay for lofty service contracts.Get something that works reasonably well to get things working... but make sure the bug fixing phase never ends... and you never lose service contracts.You never just sell a piece of hardware... like a spoon.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649472</id>
	<title>"If X is less than the cost of a recall..."</title>
	<author>Minwee</author>
	<datestamp>1269807540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Is this still Slashdot?  Why has nobody made the obvious quote from Fight Club yet?
</p><p>I haven't even seen a numbered list ending in "Profit!"  Why are you all letting me down?</p></div>
	</htmltext>
<tokenext>Is this still Slashdot ?
Why has nobody made the obvious quote from Fight Club yet ?
I have n't even seen a numbered list ending in " Profit !
" Why are you all letting me down ?</tokentext>
<sentencetext>Is this still Slashdot?
Why has nobody made the obvious quote from Fight Club yet?
I haven't even seen a numbered list ending in "Profit!
"  Why are you all letting me down?
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649162</id>
	<title>mediocrity</title>
	<author>electrogeist</author>
	<datestamp>1269805200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>"Once genius is submerged by bureaucracy, a nation is doomed to mediocrity. " -Richard Nixon<br><br>s/nation/project/</htmltext>
<tokenext>" Once genius is submerged by bureaucracy , a nation is doomed to mediocrity .
" -Richard Nixons/nation/project/</tokentext>
<sentencetext>"Once genius is submerged by bureaucracy, a nation is doomed to mediocrity.
" -Richard Nixons/nation/project/</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648862</id>
	<title>If they need it, and it's buggy, it's annoying</title>
	<author>Tsu Dho Nimh</author>
	<datestamp>1269803160000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p><nobr> <wbr></nobr><i>... a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble</i></p></div> </blockquote><p>Is going to be one extremely unhappy user because they had a reason for going that deep into the sub-cellars of the software to get at that obscure feature<nobr> <wbr></nobr>... and it is likely that they are the sport of user who is a bit more tech-savvy and ready to bitch than Joe Average user.</p></div>
	</htmltext>
<tokenext>... a user who goes through three levels of menus , opens an advanced configuration window , checks three checkboxes , and hits the 'A ' key gets a weird error message for his trouble Is going to be one extremely unhappy user because they had a reason for going that deep into the sub-cellars of the software to get at that obscure feature ... and it is likely that they are the sport of user who is a bit more tech-savvy and ready to bitch than Joe Average user .</tokentext>
<sentencetext> ... a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble Is going to be one extremely unhappy user because they had a reason for going that deep into the sub-cellars of the software to get at that obscure feature ... and it is likely that they are the sport of user who is a bit more tech-savvy and ready to bitch than Joe Average user.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31654522</id>
	<title>Re:How is this news?</title>
	<author>Anonymous</author>
	<datestamp>1269856260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Do you actually enjoy working on subpar stuff and plan to do that for years? After all that software will never be good because you're intentionally keeping it that way.<br><br>As for the article, when I was a developer I often fixed bugs not because they would be embarrassing to the company or would cause problems to the users. I fixed them because if they are there, my program/module won't be good enough for my standards.<br><br>Maybe it's bad economics, perhaps I should have spent more time helping to fix other people's stuff (don't get me wrong - I did spend a fair bit of time helping).<br><br>To me if you're that desperate to keep your job that you have to resort to leaving weird bugs in, then you probably shouldn't be working as a programmer in the first place. The world might be better off if you did something you were better at - I believe that's good economics too: more people doing what they're good at.<br><br>And not just economics - if you can't take pride in your work, maybe you should really be planning to do something else instead of trying to wedge yourself in like a bloodsucking tick. Something else where at the end of the day you can say "Y'know, I did a pretty good job there".</htmltext>
<tokenext>Do you actually enjoy working on subpar stuff and plan to do that for years ?
After all that software will never be good because you 're intentionally keeping it that way.As for the article , when I was a developer I often fixed bugs not because they would be embarrassing to the company or would cause problems to the users .
I fixed them because if they are there , my program/module wo n't be good enough for my standards.Maybe it 's bad economics , perhaps I should have spent more time helping to fix other people 's stuff ( do n't get me wrong - I did spend a fair bit of time helping ) .To me if you 're that desperate to keep your job that you have to resort to leaving weird bugs in , then you probably should n't be working as a programmer in the first place .
The world might be better off if you did something you were better at - I believe that 's good economics too : more people doing what they 're good at.And not just economics - if you ca n't take pride in your work , maybe you should really be planning to do something else instead of trying to wedge yourself in like a bloodsucking tick .
Something else where at the end of the day you can say " Y'know , I did a pretty good job there " .</tokentext>
<sentencetext>Do you actually enjoy working on subpar stuff and plan to do that for years?
After all that software will never be good because you're intentionally keeping it that way.As for the article, when I was a developer I often fixed bugs not because they would be embarrassing to the company or would cause problems to the users.
I fixed them because if they are there, my program/module won't be good enough for my standards.Maybe it's bad economics, perhaps I should have spent more time helping to fix other people's stuff (don't get me wrong - I did spend a fair bit of time helping).To me if you're that desperate to keep your job that you have to resort to leaving weird bugs in, then you probably shouldn't be working as a programmer in the first place.
The world might be better off if you did something you were better at - I believe that's good economics too: more people doing what they're good at.And not just economics - if you can't take pride in your work, maybe you should really be planning to do something else instead of trying to wedge yourself in like a bloodsucking tick.
Something else where at the end of the day you can say "Y'know, I did a pretty good job there".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648958</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649602</id>
	<title>My TV Remote has bugs...</title>
	<author>tonywestonuk</author>
	<datestamp>1269808620000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>If I connect  my TV remote to the mains AC, it will break. I blame the makers for not 'validating' my input voltage. My Cups/Mugs all have bugs, as when I drop them, they break....silly makers for not designing in dampers to cushion the blow. My car has bugs.... I can very easily crash it, how dare the manufacturers make something I can crash by just pressing the buttons/ turning the wheel in the wrong order.</p><p>My point is, that practically everything will fail, or demonstrate unpredictable behavior if it is subject to conditions to which it is not designed to handle. We accept this, as a fact of life!....Why should software be judged any different, just because it's 'virtual' and cant really be seen as a real world object?...to make a perfect bug free piece of software is practically impossible.....well, maybe 'hello world', and even this will fail should it be run on an architecture it was not designed to run on.</p></htmltext>
<tokenext>If I connect my TV remote to the mains AC , it will break .
I blame the makers for not 'validating ' my input voltage .
My Cups/Mugs all have bugs , as when I drop them , they break....silly makers for not designing in dampers to cushion the blow .
My car has bugs.... I can very easily crash it , how dare the manufacturers make something I can crash by just pressing the buttons/ turning the wheel in the wrong order.My point is , that practically everything will fail , or demonstrate unpredictable behavior if it is subject to conditions to which it is not designed to handle .
We accept this , as a fact of life ! ....Why should software be judged any different , just because it 's 'virtual ' and cant really be seen as a real world object ? ...to make a perfect bug free piece of software is practically impossible.....well , maybe 'hello world ' , and even this will fail should it be run on an architecture it was not designed to run on .</tokentext>
<sentencetext>If I connect  my TV remote to the mains AC, it will break.
I blame the makers for not 'validating' my input voltage.
My Cups/Mugs all have bugs, as when I drop them, they break....silly makers for not designing in dampers to cushion the blow.
My car has bugs.... I can very easily crash it, how dare the manufacturers make something I can crash by just pressing the buttons/ turning the wheel in the wrong order.My point is, that practically everything will fail, or demonstrate unpredictable behavior if it is subject to conditions to which it is not designed to handle.
We accept this, as a fact of life!....Why should software be judged any different, just because it's 'virtual' and cant really be seen as a real world object?...to make a perfect bug free piece of software is practically impossible.....well, maybe 'hello world', and even this will fail should it be run on an architecture it was not designed to run on.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648698</id>
	<title>Well, sure, if you have precognition</title>
	<author>Geoffrey.landis</author>
	<datestamp>1269802200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Well, sure, except that this assumes that you are PERFECT in your ability to predict the effect of a bug.  And if you're not, that bug that you think will only happen in some situation that's vastly improbably will, in fact, actually hit at exactly the WORST possible time, because maybe that key sequence gets used in some extremely important operation that you hadn't realized your software was going to be used for.  Or maybe that bug is ALSO triggered by some different sequence that you weren't quite prescient enough to realize would be common.</p></htmltext>
<tokenext>Well , sure , except that this assumes that you are PERFECT in your ability to predict the effect of a bug .
And if you 're not , that bug that you think will only happen in some situation that 's vastly improbably will , in fact , actually hit at exactly the WORST possible time , because maybe that key sequence gets used in some extremely important operation that you had n't realized your software was going to be used for .
Or maybe that bug is ALSO triggered by some different sequence that you were n't quite prescient enough to realize would be common .</tokentext>
<sentencetext>Well, sure, except that this assumes that you are PERFECT in your ability to predict the effect of a bug.
And if you're not, that bug that you think will only happen in some situation that's vastly improbably will, in fact, actually hit at exactly the WORST possible time, because maybe that key sequence gets used in some extremely important operation that you hadn't realized your software was going to be used for.
Or maybe that bug is ALSO triggered by some different sequence that you weren't quite prescient enough to realize would be common.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648746</id>
	<title>It's not a bug......</title>
	<author>Anonymous</author>
	<datestamp>1269802440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>it's a feature... There's your fix<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>it 's a feature... There 's your fix : )</tokentext>
<sentencetext>it's a feature... There's your fix :)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31654348</id>
	<title>Re:The core argument does make sense.</title>
	<author>Anonymous</author>
	<datestamp>1269853620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Sometimes it's better to ship a product and deliver it to 95\% of the user base instead of having everyone wait because 5\% wants feature X which is broken.</p></div><p>Would be interesting if you had 20 of those bugs.</p></div>
	</htmltext>
<tokenext>Sometimes it 's better to ship a product and deliver it to 95 \ % of the user base instead of having everyone wait because 5 \ % wants feature X which is broken.Would be interesting if you had 20 of those bugs .</tokentext>
<sentencetext>Sometimes it's better to ship a product and deliver it to 95\% of the user base instead of having everyone wait because 5\% wants feature X which is broken.Would be interesting if you had 20 of those bugs.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648910</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648904</id>
	<title>Functional Tests and Unit tests</title>
	<author>fysdt</author>
	<datestamp>1269803460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There are programming methods that aim to decrease the amount of bugs substantially with functional testing and unit testing. Unfortunately these tests don't make software 100\% bug-free but it they do reveal 'big bugs'.</htmltext>
<tokenext>There are programming methods that aim to decrease the amount of bugs substantially with functional testing and unit testing .
Unfortunately these tests do n't make software 100 \ % bug-free but it they do reveal 'big bugs' .</tokentext>
<sentencetext>There are programming methods that aim to decrease the amount of bugs substantially with functional testing and unit testing.
Unfortunately these tests don't make software 100\% bug-free but it they do reveal 'big bugs'.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648772</id>
	<title>I'm not sure I buy the argument</title>
	<author>Palestrina</author>
	<datestamp>1269802620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Software is not so different from other engineering disciplines that we cannot learn from the best practices of adjacent fields.  Although no human endeavor -- other than being Pope -- is infallible, we do see disciplined attempts to measure, manage and improve quality levels.  The point is not to reduce the quality level to zero, but to know what your quality level is and be able to hit your mark.  What level of quality is needed will depend on the market, your customers, the competition, the frequency of releases, whether the software is easily updated or burned into firmware and devices, etc.</p><p>In the end, the best way to create higher quality software is not to find and fix more bugs.  It is to use a disciplined approach to programming that introduces fewer bugs in the first place.  If you focus on defect detection and removal, then you are fighting the wrong battle. You can't win doing it that way.  Quality software comes from a disciplined process at all stages, from requirements to testing, and not just as an endgame activity to sway as many bugs as you can.</p></htmltext>
<tokenext>Software is not so different from other engineering disciplines that we can not learn from the best practices of adjacent fields .
Although no human endeavor -- other than being Pope -- is infallible , we do see disciplined attempts to measure , manage and improve quality levels .
The point is not to reduce the quality level to zero , but to know what your quality level is and be able to hit your mark .
What level of quality is needed will depend on the market , your customers , the competition , the frequency of releases , whether the software is easily updated or burned into firmware and devices , etc.In the end , the best way to create higher quality software is not to find and fix more bugs .
It is to use a disciplined approach to programming that introduces fewer bugs in the first place .
If you focus on defect detection and removal , then you are fighting the wrong battle .
You ca n't win doing it that way .
Quality software comes from a disciplined process at all stages , from requirements to testing , and not just as an endgame activity to sway as many bugs as you can .</tokentext>
<sentencetext>Software is not so different from other engineering disciplines that we cannot learn from the best practices of adjacent fields.
Although no human endeavor -- other than being Pope -- is infallible, we do see disciplined attempts to measure, manage and improve quality levels.
The point is not to reduce the quality level to zero, but to know what your quality level is and be able to hit your mark.
What level of quality is needed will depend on the market, your customers, the competition, the frequency of releases, whether the software is easily updated or burned into firmware and devices, etc.In the end, the best way to create higher quality software is not to find and fix more bugs.
It is to use a disciplined approach to programming that introduces fewer bugs in the first place.
If you focus on defect detection and removal, then you are fighting the wrong battle.
You can't win doing it that way.
Quality software comes from a disciplined process at all stages, from requirements to testing, and not just as an endgame activity to sway as many bugs as you can.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649170</id>
	<title>Im not aprogrmmer but do programming</title>
	<author>Anonymous</author>
	<datestamp>1269805260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Programmers view my approach to programming a bit weird. But so do I, they always claim bugs aren't a problem, its ingrained in the way you do things.</p><p>You can do things a LOT better. For starters stop making the same mistake many times.</p><p>And for gods sake don't always ask as much code as one possibly can do in any amount of time its inanely stupid. If the code is worth to you 20,000$ the be prepared to pay 20,000$ for it. It don't get better because you may sometimes get it cheaper if you luck out. Because in the end this always bites your ass.</p></htmltext>
<tokenext>Programmers view my approach to programming a bit weird .
But so do I , they always claim bugs are n't a problem , its ingrained in the way you do things.You can do things a LOT better .
For starters stop making the same mistake many times.And for gods sake do n't always ask as much code as one possibly can do in any amount of time its inanely stupid .
If the code is worth to you 20,000 $ the be prepared to pay 20,000 $ for it .
It do n't get better because you may sometimes get it cheaper if you luck out .
Because in the end this always bites your ass .</tokentext>
<sentencetext>Programmers view my approach to programming a bit weird.
But so do I, they always claim bugs aren't a problem, its ingrained in the way you do things.You can do things a LOT better.
For starters stop making the same mistake many times.And for gods sake don't always ask as much code as one possibly can do in any amount of time its inanely stupid.
If the code is worth to you 20,000$ the be prepared to pay 20,000$ for it.
It don't get better because you may sometimes get it cheaper if you luck out.
Because in the end this always bites your ass.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649224</id>
	<title>No bugs isn't a perfect product.</title>
	<author>ArundelCastle</author>
	<datestamp>1269805620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Even if it's bug free, that doesn't mean the software is designed to be easy or intuitive to use.  There is often more money to be made from deliberate obfuscation.  Every piece of Enterprise software I've used (particularly SAP) seems to follow this principle. And the huge aftermarket of expert consultants charging $150/hr for training and troubleshooting, seems to affirm it.  Keep in mind those consultants are usually teaching the corporate experts, I'm not even touching the surface of end user training, which I'm experienced at being responsible for.</p><p>The real money comes from support packages and direct-line support levels (ie: silver, gold, platinum and such to maintain a 24h call centre).  Let's ask a simple hypothetical: what if Windows was bulletproof and bug free? How would Microsoft make any money?  If nobody had reason to fix a problem within 30 minutes like their job depends on it?  Or even not upgrade to the next version because the last one works better?  With XP and Vista we already know the answer to that.</p></htmltext>
<tokenext>Even if it 's bug free , that does n't mean the software is designed to be easy or intuitive to use .
There is often more money to be made from deliberate obfuscation .
Every piece of Enterprise software I 've used ( particularly SAP ) seems to follow this principle .
And the huge aftermarket of expert consultants charging $ 150/hr for training and troubleshooting , seems to affirm it .
Keep in mind those consultants are usually teaching the corporate experts , I 'm not even touching the surface of end user training , which I 'm experienced at being responsible for.The real money comes from support packages and direct-line support levels ( ie : silver , gold , platinum and such to maintain a 24h call centre ) .
Let 's ask a simple hypothetical : what if Windows was bulletproof and bug free ?
How would Microsoft make any money ?
If nobody had reason to fix a problem within 30 minutes like their job depends on it ?
Or even not upgrade to the next version because the last one works better ?
With XP and Vista we already know the answer to that .</tokentext>
<sentencetext>Even if it's bug free, that doesn't mean the software is designed to be easy or intuitive to use.
There is often more money to be made from deliberate obfuscation.
Every piece of Enterprise software I've used (particularly SAP) seems to follow this principle.
And the huge aftermarket of expert consultants charging $150/hr for training and troubleshooting, seems to affirm it.
Keep in mind those consultants are usually teaching the corporate experts, I'm not even touching the surface of end user training, which I'm experienced at being responsible for.The real money comes from support packages and direct-line support levels (ie: silver, gold, platinum and such to maintain a 24h call centre).
Let's ask a simple hypothetical: what if Windows was bulletproof and bug free?
How would Microsoft make any money?
If nobody had reason to fix a problem within 30 minutes like their job depends on it?
Or even not upgrade to the next version because the last one works better?
With XP and Vista we already know the answer to that.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651284</id>
	<title>Until your users figure out the game</title>
	<author>gig</author>
	<datestamp>1269777600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The little bugs add up, and users consider your software and even computers in general to be very unreliable these days. The PC has such a bad reputation that users just openly mock it all the time. It's expected to suck. Microsoft software especially is expected to have bugs. The whole platform is just a big bugfest, a race to the bottom in quality.</p><p>Part of why Apple has been making hay over the past decade is that their software is just more reliable than what people have come to expect. They spent years putting a Unix core under the Mac and they were mocked for it, "why do consumers need that level of reliability?" Now, it's typical for a Mac never to crash, typical for an iPhone never to crash. Users may not even consciously be able to explain that, but it's part of what they love and why they come back.</p><p>Thr truth is, you can't parse out the right level of quality you're "supposed" to ship. You have to take pride in your work at every level. Software is layered, all dependencies<nobr> <wbr></nobr>... if you don't shoot for perfect you will never even get good. And you'll get into the race to the bottom, making Wal-Mart software. "Hey. we have 1 less bug thatn our competition, break out the champagne!"</p><p>Generally speaking, users hate computers. No wonder the PC is being replaced by mobiles with simplified software and a much, much higher expectation of quality.</p><p>So there is always damage from bugs. It may not be measured in this quarter's report, but you can see your whole product or company or platform hurt by it long-term.</p></htmltext>
<tokenext>The little bugs add up , and users consider your software and even computers in general to be very unreliable these days .
The PC has such a bad reputation that users just openly mock it all the time .
It 's expected to suck .
Microsoft software especially is expected to have bugs .
The whole platform is just a big bugfest , a race to the bottom in quality.Part of why Apple has been making hay over the past decade is that their software is just more reliable than what people have come to expect .
They spent years putting a Unix core under the Mac and they were mocked for it , " why do consumers need that level of reliability ?
" Now , it 's typical for a Mac never to crash , typical for an iPhone never to crash .
Users may not even consciously be able to explain that , but it 's part of what they love and why they come back.Thr truth is , you ca n't parse out the right level of quality you 're " supposed " to ship .
You have to take pride in your work at every level .
Software is layered , all dependencies ... if you do n't shoot for perfect you will never even get good .
And you 'll get into the race to the bottom , making Wal-Mart software .
" Hey. we have 1 less bug thatn our competition , break out the champagne !
" Generally speaking , users hate computers .
No wonder the PC is being replaced by mobiles with simplified software and a much , much higher expectation of quality.So there is always damage from bugs .
It may not be measured in this quarter 's report , but you can see your whole product or company or platform hurt by it long-term .</tokentext>
<sentencetext>The little bugs add up, and users consider your software and even computers in general to be very unreliable these days.
The PC has such a bad reputation that users just openly mock it all the time.
It's expected to suck.
Microsoft software especially is expected to have bugs.
The whole platform is just a big bugfest, a race to the bottom in quality.Part of why Apple has been making hay over the past decade is that their software is just more reliable than what people have come to expect.
They spent years putting a Unix core under the Mac and they were mocked for it, "why do consumers need that level of reliability?
" Now, it's typical for a Mac never to crash, typical for an iPhone never to crash.
Users may not even consciously be able to explain that, but it's part of what they love and why they come back.Thr truth is, you can't parse out the right level of quality you're "supposed" to ship.
You have to take pride in your work at every level.
Software is layered, all dependencies ... if you don't shoot for perfect you will never even get good.
And you'll get into the race to the bottom, making Wal-Mart software.
"Hey. we have 1 less bug thatn our competition, break out the champagne!
"Generally speaking, users hate computers.
No wonder the PC is being replaced by mobiles with simplified software and a much, much higher expectation of quality.So there is always damage from bugs.
It may not be measured in this quarter's report, but you can see your whole product or company or platform hurt by it long-term.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649238</id>
	<title>High Quality in Software Requires THINKING</title>
	<author>CAOgdin</author>
	<datestamp>1269805800000</datestamp>
	<modclass>Troll</modclass>
	<modscore>1</modscore>
	<htmltext>I know, that's too much to ask of modern code monkeys.

How many of you who "good enough" quality have ever even read a book on "Software Engineering?"  Have you even HEARD of the original NATO conference on that subject?  How many have studied interesting "Software Physics."

Yes, all code I write has bugs, because I am not omniscient.  There are inputs and environments I never imagined the program having to cope with.  But about half the code I write has two things rarely seen in code today:

1.  Comments in the form of Assertions (e.g. "At this point, input XYZ is confirmed to be in the range 87...92".
2.  About half the lines of actual code (absent comments) are validation of input conditions from the world (user and environment) outside the program itself.

Perfection is not actually achievable, but IT'S THE ONLY TARGET WORTH PURSUING.

Companies like Microsoft don't even try, because they're not in the software business; they're in the money-making business.  Professionals care; money-grubbers aren't.</htmltext>
<tokenext>I know , that 's too much to ask of modern code monkeys .
How many of you who " good enough " quality have ever even read a book on " Software Engineering ?
" Have you even HEARD of the original NATO conference on that subject ?
How many have studied interesting " Software Physics .
" Yes , all code I write has bugs , because I am not omniscient .
There are inputs and environments I never imagined the program having to cope with .
But about half the code I write has two things rarely seen in code today : 1 .
Comments in the form of Assertions ( e.g .
" At this point , input XYZ is confirmed to be in the range 87...92 " .
2. About half the lines of actual code ( absent comments ) are validation of input conditions from the world ( user and environment ) outside the program itself .
Perfection is not actually achievable , but IT 'S THE ONLY TARGET WORTH PURSUING .
Companies like Microsoft do n't even try , because they 're not in the software business ; they 're in the money-making business .
Professionals care ; money-grubbers are n't .</tokentext>
<sentencetext>I know, that's too much to ask of modern code monkeys.
How many of you who "good enough" quality have ever even read a book on "Software Engineering?
"  Have you even HEARD of the original NATO conference on that subject?
How many have studied interesting "Software Physics.
"

Yes, all code I write has bugs, because I am not omniscient.
There are inputs and environments I never imagined the program having to cope with.
But about half the code I write has two things rarely seen in code today:

1.
Comments in the form of Assertions (e.g.
"At this point, input XYZ is confirmed to be in the range 87...92".
2.  About half the lines of actual code (absent comments) are validation of input conditions from the world (user and environment) outside the program itself.
Perfection is not actually achievable, but IT'S THE ONLY TARGET WORTH PURSUING.
Companies like Microsoft don't even try, because they're not in the software business; they're in the money-making business.
Professionals care; money-grubbers aren't.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649894</id>
	<title>Software would be better w/o government force.</title>
	<author>AlexLibman</author>
	<datestamp>1269767580000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>In the free software world, that would mean the impossibility of violence-backed "licenses" like GPL - if you choose to make your code public then you can no longer control it.  Without the "viral" effect of Copyleft, open source code would be [i]a lot[/i] more business-friendly, resulting in more small businesses being able to compete with entrenched giants like Microsoft.  Just look at how much good Microsoft's competitor's were able to do with the small fraction of FLOSS that is permissively licensed: MacOS X, Safari, Google Chrome, EnterpriseDB (about to eat Oracle's lunch), the long list of games that embed SQLite or Python / Lua, etc, etc, etc.</p><p>In the proprietary software world, with EULA's no longer being any more enforcable than an "if you see me you owe me money" post-in note stuck on someone's forehead, we would see rapid growth of hosted applications, software as a service (SaaS), support subscriptions, certification subscriptions, business contracts, hardware bundling, etc, etc, etc.  Companies like Microsoft and Oracle would still be able to make money, but based on value-adding merit and not a race through the inherently-corrupt patent bureaucracy!</p></htmltext>
<tokenext>In the free software world , that would mean the impossibility of violence-backed " licenses " like GPL - if you choose to make your code public then you can no longer control it .
Without the " viral " effect of Copyleft , open source code would be [ i ] a lot [ /i ] more business-friendly , resulting in more small businesses being able to compete with entrenched giants like Microsoft .
Just look at how much good Microsoft 's competitor 's were able to do with the small fraction of FLOSS that is permissively licensed : MacOS X , Safari , Google Chrome , EnterpriseDB ( about to eat Oracle 's lunch ) , the long list of games that embed SQLite or Python / Lua , etc , etc , etc.In the proprietary software world , with EULA 's no longer being any more enforcable than an " if you see me you owe me money " post-in note stuck on someone 's forehead , we would see rapid growth of hosted applications , software as a service ( SaaS ) , support subscriptions , certification subscriptions , business contracts , hardware bundling , etc , etc , etc .
Companies like Microsoft and Oracle would still be able to make money , but based on value-adding merit and not a race through the inherently-corrupt patent bureaucracy !</tokentext>
<sentencetext>In the free software world, that would mean the impossibility of violence-backed "licenses" like GPL - if you choose to make your code public then you can no longer control it.
Without the "viral" effect of Copyleft, open source code would be [i]a lot[/i] more business-friendly, resulting in more small businesses being able to compete with entrenched giants like Microsoft.
Just look at how much good Microsoft's competitor's were able to do with the small fraction of FLOSS that is permissively licensed: MacOS X, Safari, Google Chrome, EnterpriseDB (about to eat Oracle's lunch), the long list of games that embed SQLite or Python / Lua, etc, etc, etc.In the proprietary software world, with EULA's no longer being any more enforcable than an "if you see me you owe me money" post-in note stuck on someone's forehead, we would see rapid growth of hosted applications, software as a service (SaaS), support subscriptions, certification subscriptions, business contracts, hardware bundling, etc, etc, etc.
Companies like Microsoft and Oracle would still be able to make money, but based on value-adding merit and not a race through the inherently-corrupt patent bureaucracy!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650048</id>
	<title>Actually no.</title>
	<author>Anonymous</author>
	<datestamp>1269768840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You customers will be looking for whatever helps them get their jobs done the easiest, cheapest and quickest.</p><p>If your next release contains fixes to all your minor bugs but no new market-required features then your customers will be jumping ship to the competitor whose bug-ridden code does contain the market-required features.</p></htmltext>
<tokenext>You customers will be looking for whatever helps them get their jobs done the easiest , cheapest and quickest.If your next release contains fixes to all your minor bugs but no new market-required features then your customers will be jumping ship to the competitor whose bug-ridden code does contain the market-required features .</tokentext>
<sentencetext>You customers will be looking for whatever helps them get their jobs done the easiest, cheapest and quickest.If your next release contains fixes to all your minor bugs but no new market-required features then your customers will be jumping ship to the competitor whose bug-ridden code does contain the market-required features.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648730</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31652092</id>
	<title>So how about Oracle and Borland</title>
	<author>cdn-programmer</author>
	<datestamp>1269784800000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext><p>Oracle shipped their database ported to Dos.  I don't use their products anymore.  This is what they did.</p><p>In SQL*FORMS one could define a field and indicate that is its numeric.  One should not be able to type in "ABCDE" in an numeric field.  Indeed if you did then SQL*FORMS trapped the error.  However SQL*FORMS also allowed a trigger to be set for the field.  If the trigger was set they disabled the error trap!  That software was so buggy it was almost impossible to use!  In the next version they had the error trap enabled but they changed so much other stuff that I had to re-write the code.  It does not feel good having to go to the client and advise that after months of work the product cannot be delivered and that they will have to wait months longer for the next version and hope for the best!</p><p>Borland shipped C++ for OS/2.  Again - a system full of crap.</p><p>IBM had so many problems with OS/2 that there were many things that could not be made to work!  One was networking between windows NT and IBM OS/2.  FTP transfers would just fail.  No errors and no warnings.</p><p>Then IBM had the great "feature" in OS/2 that on a dual monitor system one could open a "DOS" window on on the VGA side.  The other side was 8514.  If the focus was in DOS then OS/2 windows on the 8514 ran.  If the focus was in an OS/2 window then the DOS window not only froze - they blanked it out too!</p><p>When Microsoft brought out NT 4.0 OS/2 got the boot!  Funny - OS/2 didn't make it in the market place.  I had a tech support contract with IBM back then as well!  Another thing that was funny is that NT ran command line OS/2 code better than OS/2 did.  So how did IBM benefit from their buggy code?</p><p>Here's one Microsoft pulled off.  In their Fortran for Dos compiler we found a serious bug.  I don't know what triggered it but the compiler would remove certain "if" statements.  I managed to find it by looking specifically at the machine code and sure enough the instructions were not emitted.  I submitted a report to Microsoft and went to the client and fortunately I was dealing with engineers who did know something about programming.  I showed them via the debugger that the code was not there!  We figured out a way to get that specific "if" statement working... but we were dealing with 100's of 1000's of lines of code!  How does one check what other "if" statements might have been discarded by that crappy compiler?</p><p>So over the next year I checked up with Microsoft every few months.  Eventually they told me to buy the new version.  I did and when it arrived the first thing I did was to check to see if the bug had been fixed.  It wasn't!  They never did fix it that I know of.  Eventually we got to move off DOS into windows.  So I ordered that version.  I found the package actually contained two (2) compliers.  One was for 16 bit DOS mode.  The other was for windows mode.  They were incompatible with each other.  I gave up.  I have never programmed windows in my life!  I do not use it!  I did run NT for a while but never wrote any "windows" code.  I use Linux today and OpenBSD and that stuff works!</p></htmltext>
<tokenext>Oracle shipped their database ported to Dos .
I do n't use their products anymore .
This is what they did.In SQL * FORMS one could define a field and indicate that is its numeric .
One should not be able to type in " ABCDE " in an numeric field .
Indeed if you did then SQL * FORMS trapped the error .
However SQL * FORMS also allowed a trigger to be set for the field .
If the trigger was set they disabled the error trap !
That software was so buggy it was almost impossible to use !
In the next version they had the error trap enabled but they changed so much other stuff that I had to re-write the code .
It does not feel good having to go to the client and advise that after months of work the product can not be delivered and that they will have to wait months longer for the next version and hope for the best ! Borland shipped C + + for OS/2 .
Again - a system full of crap.IBM had so many problems with OS/2 that there were many things that could not be made to work !
One was networking between windows NT and IBM OS/2 .
FTP transfers would just fail .
No errors and no warnings.Then IBM had the great " feature " in OS/2 that on a dual monitor system one could open a " DOS " window on on the VGA side .
The other side was 8514 .
If the focus was in DOS then OS/2 windows on the 8514 ran .
If the focus was in an OS/2 window then the DOS window not only froze - they blanked it out too ! When Microsoft brought out NT 4.0 OS/2 got the boot !
Funny - OS/2 did n't make it in the market place .
I had a tech support contract with IBM back then as well !
Another thing that was funny is that NT ran command line OS/2 code better than OS/2 did .
So how did IBM benefit from their buggy code ? Here 's one Microsoft pulled off .
In their Fortran for Dos compiler we found a serious bug .
I do n't know what triggered it but the compiler would remove certain " if " statements .
I managed to find it by looking specifically at the machine code and sure enough the instructions were not emitted .
I submitted a report to Microsoft and went to the client and fortunately I was dealing with engineers who did know something about programming .
I showed them via the debugger that the code was not there !
We figured out a way to get that specific " if " statement working... but we were dealing with 100 's of 1000 's of lines of code !
How does one check what other " if " statements might have been discarded by that crappy compiler ? So over the next year I checked up with Microsoft every few months .
Eventually they told me to buy the new version .
I did and when it arrived the first thing I did was to check to see if the bug had been fixed .
It was n't !
They never did fix it that I know of .
Eventually we got to move off DOS into windows .
So I ordered that version .
I found the package actually contained two ( 2 ) compliers .
One was for 16 bit DOS mode .
The other was for windows mode .
They were incompatible with each other .
I gave up .
I have never programmed windows in my life !
I do not use it !
I did run NT for a while but never wrote any " windows " code .
I use Linux today and OpenBSD and that stuff works !</tokentext>
<sentencetext>Oracle shipped their database ported to Dos.
I don't use their products anymore.
This is what they did.In SQL*FORMS one could define a field and indicate that is its numeric.
One should not be able to type in "ABCDE" in an numeric field.
Indeed if you did then SQL*FORMS trapped the error.
However SQL*FORMS also allowed a trigger to be set for the field.
If the trigger was set they disabled the error trap!
That software was so buggy it was almost impossible to use!
In the next version they had the error trap enabled but they changed so much other stuff that I had to re-write the code.
It does not feel good having to go to the client and advise that after months of work the product cannot be delivered and that they will have to wait months longer for the next version and hope for the best!Borland shipped C++ for OS/2.
Again - a system full of crap.IBM had so many problems with OS/2 that there were many things that could not be made to work!
One was networking between windows NT and IBM OS/2.
FTP transfers would just fail.
No errors and no warnings.Then IBM had the great "feature" in OS/2 that on a dual monitor system one could open a "DOS" window on on the VGA side.
The other side was 8514.
If the focus was in DOS then OS/2 windows on the 8514 ran.
If the focus was in an OS/2 window then the DOS window not only froze - they blanked it out too!When Microsoft brought out NT 4.0 OS/2 got the boot!
Funny - OS/2 didn't make it in the market place.
I had a tech support contract with IBM back then as well!
Another thing that was funny is that NT ran command line OS/2 code better than OS/2 did.
So how did IBM benefit from their buggy code?Here's one Microsoft pulled off.
In their Fortran for Dos compiler we found a serious bug.
I don't know what triggered it but the compiler would remove certain "if" statements.
I managed to find it by looking specifically at the machine code and sure enough the instructions were not emitted.
I submitted a report to Microsoft and went to the client and fortunately I was dealing with engineers who did know something about programming.
I showed them via the debugger that the code was not there!
We figured out a way to get that specific "if" statement working... but we were dealing with 100's of 1000's of lines of code!
How does one check what other "if" statements might have been discarded by that crappy compiler?So over the next year I checked up with Microsoft every few months.
Eventually they told me to buy the new version.
I did and when it arrived the first thing I did was to check to see if the bug had been fixed.
It wasn't!
They never did fix it that I know of.
Eventually we got to move off DOS into windows.
So I ordered that version.
I found the package actually contained two (2) compliers.
One was for 16 bit DOS mode.
The other was for windows mode.
They were incompatible with each other.
I gave up.
I have never programmed windows in my life!
I do not use it!
I did run NT for a while but never wrote any "windows" code.
I use Linux today and OpenBSD and that stuff works!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651546</id>
	<title>more excuses from bad coders</title>
	<author>Michael Kristopeit</author>
	<datestamp>1269779520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>there are NO excuse for software that offers features that don't function properly.... who implemented the feature?  they didn't test it first?</htmltext>
<tokenext>there are NO excuse for software that offers features that do n't function properly.... who implemented the feature ?
they did n't test it first ?</tokentext>
<sentencetext>there are NO excuse for software that offers features that don't function properly.... who implemented the feature?
they didn't test it first?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31654254</id>
	<title>Misses the point: fix bugs for the future too!</title>
	<author>Grey Haired Luser</author>
	<datestamp>1269895320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you're trying to ship quality software, you don't just \_fix\_ bugs,<br>you treat each one as a learning experience, a mini-laboratory of<br>"what went wrong" here.  You don't just fix \_this\_ bug; you adjust<br>your processes/standards/whatever else so that this bug can never re-occur.<br>You also find out where \_else\_ this bug may have manifested; often<br>in slightly different ways.  It's unlikely to be the only exemplar of<br>this type of bug in your system.</p><p>Just doing a cost/benefit analysis saying: nah, unimportant, don't fix<br>it is stupid.  \_This\_ bug may be unimportant, but it may exist somewhere<br>else where it is important, or someone may write the same bug tomorrow<br>where it will be important.</p></htmltext>
<tokenext>If you 're trying to ship quality software , you do n't just \ _fix \ _ bugs,you treat each one as a learning experience , a mini-laboratory of " what went wrong " here .
You do n't just fix \ _this \ _ bug ; you adjustyour processes/standards/whatever else so that this bug can never re-occur.You also find out where \ _else \ _ this bug may have manifested ; oftenin slightly different ways .
It 's unlikely to be the only exemplar ofthis type of bug in your system.Just doing a cost/benefit analysis saying : nah , unimportant , do n't fixit is stupid .
\ _This \ _ bug may be unimportant , but it may exist somewhereelse where it is important , or someone may write the same bug tomorrowwhere it will be important .</tokentext>
<sentencetext>If you're trying to ship quality software, you don't just \_fix\_ bugs,you treat each one as a learning experience, a mini-laboratory of"what went wrong" here.
You don't just fix \_this\_ bug; you adjustyour processes/standards/whatever else so that this bug can never re-occur.You also find out where \_else\_ this bug may have manifested; oftenin slightly different ways.
It's unlikely to be the only exemplar ofthis type of bug in your system.Just doing a cost/benefit analysis saying: nah, unimportant, don't fixit is stupid.
\_This\_ bug may be unimportant, but it may exist somewhereelse where it is important, or someone may write the same bug tomorrowwhere it will be important.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649204</id>
	<title>Those bugs indicate a broken dev process</title>
	<author>Anonymous</author>
	<datestamp>1269805500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>if the simple and easy stuff is broken (the stuff that can be automatically checked),then bigger bugs lurk below. Article is dumb, assumes the dummy programmer can know the difference.</p></htmltext>
<tokenext>if the simple and easy stuff is broken ( the stuff that can be automatically checked ) ,then bigger bugs lurk below .
Article is dumb , assumes the dummy programmer can know the difference .</tokentext>
<sentencetext>if the simple and easy stuff is broken (the stuff that can be automatically checked),then bigger bugs lurk below.
Article is dumb, assumes the dummy programmer can know the difference.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650504</id>
	<title>Blasphemy</title>
	<author>toboldh</author>
	<datestamp>1269772200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Only god can create perfection.  Every piece of software requires at least one bug to avoid blasphemy.</htmltext>
<tokenext>Only god can create perfection .
Every piece of software requires at least one bug to avoid blasphemy .</tokentext>
<sentencetext>Only god can create perfection.
Every piece of software requires at least one bug to avoid blasphemy.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648790</id>
	<title>Err. Dumbo.</title>
	<author>Anonymous</author>
	<datestamp>1269802740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>They are not bugs.<br>They are DEFECTS.<br>Pure and simple.</p><p>That little example of the 'trivial' bug, if it is the feature, integration, function, exporter, importer, etc.. without which the user cannot work. If it is the feature for which they actually bought the product. And they have now wasted their time and money buying, installing, partially configuring the tool. And now, due to the incompetence of the developers they cannot continue. Then they Will think you are a Jerk, and that -all- developers are jerks. And they are right. I've worked at a 6-sigma organisation, it's not actually very hard to write bug-free code, you just have to care.</p><p>once again. They are NOT BUGS. They are DEFECTS caused by lacklusture workmanship.</p></htmltext>
<tokenext>They are not bugs.They are DEFECTS.Pure and simple.That little example of the 'trivial ' bug , if it is the feature , integration , function , exporter , importer , etc.. without which the user can not work .
If it is the feature for which they actually bought the product .
And they have now wasted their time and money buying , installing , partially configuring the tool .
And now , due to the incompetence of the developers they can not continue .
Then they Will think you are a Jerk , and that -all- developers are jerks .
And they are right .
I 've worked at a 6-sigma organisation , it 's not actually very hard to write bug-free code , you just have to care.once again .
They are NOT BUGS .
They are DEFECTS caused by lacklusture workmanship .</tokentext>
<sentencetext>They are not bugs.They are DEFECTS.Pure and simple.That little example of the 'trivial' bug, if it is the feature, integration, function, exporter, importer, etc.. without which the user cannot work.
If it is the feature for which they actually bought the product.
And they have now wasted their time and money buying, installing, partially configuring the tool.
And now, due to the incompetence of the developers they cannot continue.
Then they Will think you are a Jerk, and that -all- developers are jerks.
And they are right.
I've worked at a 6-sigma organisation, it's not actually very hard to write bug-free code, you just have to care.once again.
They are NOT BUGS.
They are DEFECTS caused by lacklusture workmanship.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648744</id>
	<title>Re:Oh Please</title>
	<author>Anonymous</author>
	<datestamp>1269802440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Exactly. Most coders have to use the code they write. Leaving bugs is not something you do if you know they are there. Sure some people do that, but not the ones that want to get it right - at least for their own use. This is why some open source software is not infinitely usable - it did what the original author needed, and was not intended particularly to solve everyone's silly problems. The example of the 'A' key is probably something that was going to work soon, but the need for it never materialized and someone forgot to disable the code that checks for the letter 'A' - and since it was not implemented, nobody checked it.</p><p>The first time I had code in production, running 24/7 I was kind of upset that I didn't need to look at it everyday, then amazed that it was working so well. Then, months later when I did have to go look at why it seemed to be not working right, I learned how important documentation and comments are. At this point I stopped being amazed that it worked well, but that it worked at all. Bugs are not left on purpose, only when there is not time or resources to fix them.</p></htmltext>
<tokenext>Exactly .
Most coders have to use the code they write .
Leaving bugs is not something you do if you know they are there .
Sure some people do that , but not the ones that want to get it right - at least for their own use .
This is why some open source software is not infinitely usable - it did what the original author needed , and was not intended particularly to solve everyone 's silly problems .
The example of the 'A ' key is probably something that was going to work soon , but the need for it never materialized and someone forgot to disable the code that checks for the letter 'A ' - and since it was not implemented , nobody checked it.The first time I had code in production , running 24/7 I was kind of upset that I did n't need to look at it everyday , then amazed that it was working so well .
Then , months later when I did have to go look at why it seemed to be not working right , I learned how important documentation and comments are .
At this point I stopped being amazed that it worked well , but that it worked at all .
Bugs are not left on purpose , only when there is not time or resources to fix them .</tokentext>
<sentencetext>Exactly.
Most coders have to use the code they write.
Leaving bugs is not something you do if you know they are there.
Sure some people do that, but not the ones that want to get it right - at least for their own use.
This is why some open source software is not infinitely usable - it did what the original author needed, and was not intended particularly to solve everyone's silly problems.
The example of the 'A' key is probably something that was going to work soon, but the need for it never materialized and someone forgot to disable the code that checks for the letter 'A' - and since it was not implemented, nobody checked it.The first time I had code in production, running 24/7 I was kind of upset that I didn't need to look at it everyday, then amazed that it was working so well.
Then, months later when I did have to go look at why it seemed to be not working right, I learned how important documentation and comments are.
At this point I stopped being amazed that it worked well, but that it worked at all.
Bugs are not left on purpose, only when there is not time or resources to fix them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31653424</id>
	<title>Economics of bugs</title>
	<author>Anonymous</author>
	<datestamp>1269798960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Why is it that software is one product in which bugs are acceptable?  What if other products were this way?<br>
&nbsp; - Sorry, the car will not shift into 5th with the radio tuned to FM the rear pasenger window down halfway, and the armrest up, you have to put the armrest down to go on the highway.<br>
&nbsp; - Sorry, we don't serve coffie on the 3rd tuesday of the month, please come back tommorow.<br>
&nbsp; - Sorry, this dictionary does not include the letter p.  lease use another word.</p><p>I understand that programmers are pushed to continually do more with less, and still get the product out, but every industry is this way.  Only software has a cheap mechinism for improvements to be incorporated after release (patches, updates, versions, etc).  In other products, the cost to correct errors is very high (recalls, discounts, or scrap), and are borne by the supplier, not the users.  In software, the costs are borne by the users, not the suppliers, and so there is an incentive to release suboptimal products.</p><p>PC computer games have a low cost to the supplier to fix after release, and so there is an insentive to release on specific deadlines.  On the other hand, consele games have (traditionally) had a higher cost to fix (impossible, prior to the newest generation of consels) after release.  There is a long history of PC games being practically unplayable at release, and some are never adequatly fixed, whereas is is very rare in which there are significant problems with a consel game.</p><p>
&nbsp; - Masters of Orion 2 PC (Misiles incoming should we raise sheilds captain? No, lets wait until we lose one death star class ship, before we raise shields or open fire)<br>
&nbsp; - Enter the Matrix PC (don't enter that room)<br>
&nbsp; - Empire total war PC (It sure would be nice to finish a game in that dosn't just crash, but the error is at least 20 turns back in the saved game file, so you just can't go back and try again)<br>
&nbsp; - KOFOR2 Xbox, then PC  (I will give you this one, at least it did not crash).</p><p>The only way that this is shifted back to the supplier is through "goodwill".  Until users demand bug free software, and shift the costs back to the developers, this will not change.  From the posts above, there appears to be split on this issue, with some programmers accepting the need not to use up goodwill, and others stating that bugs are a fact of life.</p></htmltext>
<tokenext>Why is it that software is one product in which bugs are acceptable ?
What if other products were this way ?
  - Sorry , the car will not shift into 5th with the radio tuned to FM the rear pasenger window down halfway , and the armrest up , you have to put the armrest down to go on the highway .
  - Sorry , we do n't serve coffie on the 3rd tuesday of the month , please come back tommorow .
  - Sorry , this dictionary does not include the letter p. lease use another word.I understand that programmers are pushed to continually do more with less , and still get the product out , but every industry is this way .
Only software has a cheap mechinism for improvements to be incorporated after release ( patches , updates , versions , etc ) .
In other products , the cost to correct errors is very high ( recalls , discounts , or scrap ) , and are borne by the supplier , not the users .
In software , the costs are borne by the users , not the suppliers , and so there is an incentive to release suboptimal products.PC computer games have a low cost to the supplier to fix after release , and so there is an insentive to release on specific deadlines .
On the other hand , consele games have ( traditionally ) had a higher cost to fix ( impossible , prior to the newest generation of consels ) after release .
There is a long history of PC games being practically unplayable at release , and some are never adequatly fixed , whereas is is very rare in which there are significant problems with a consel game .
  - Masters of Orion 2 PC ( Misiles incoming should we raise sheilds captain ?
No , lets wait until we lose one death star class ship , before we raise shields or open fire )   - Enter the Matrix PC ( do n't enter that room )   - Empire total war PC ( It sure would be nice to finish a game in that dos n't just crash , but the error is at least 20 turns back in the saved game file , so you just ca n't go back and try again )   - KOFOR2 Xbox , then PC ( I will give you this one , at least it did not crash ) .The only way that this is shifted back to the supplier is through " goodwill " .
Until users demand bug free software , and shift the costs back to the developers , this will not change .
From the posts above , there appears to be split on this issue , with some programmers accepting the need not to use up goodwill , and others stating that bugs are a fact of life .</tokentext>
<sentencetext>Why is it that software is one product in which bugs are acceptable?
What if other products were this way?
  - Sorry, the car will not shift into 5th with the radio tuned to FM the rear pasenger window down halfway, and the armrest up, you have to put the armrest down to go on the highway.
  - Sorry, we don't serve coffie on the 3rd tuesday of the month, please come back tommorow.
  - Sorry, this dictionary does not include the letter p.  lease use another word.I understand that programmers are pushed to continually do more with less, and still get the product out, but every industry is this way.
Only software has a cheap mechinism for improvements to be incorporated after release (patches, updates, versions, etc).
In other products, the cost to correct errors is very high (recalls, discounts, or scrap), and are borne by the supplier, not the users.
In software, the costs are borne by the users, not the suppliers, and so there is an incentive to release suboptimal products.PC computer games have a low cost to the supplier to fix after release, and so there is an insentive to release on specific deadlines.
On the other hand, consele games have (traditionally) had a higher cost to fix (impossible, prior to the newest generation of consels) after release.
There is a long history of PC games being practically unplayable at release, and some are never adequatly fixed, whereas is is very rare in which there are significant problems with a consel game.
  - Masters of Orion 2 PC (Misiles incoming should we raise sheilds captain?
No, lets wait until we lose one death star class ship, before we raise shields or open fire)
  - Enter the Matrix PC (don't enter that room)
  - Empire total war PC (It sure would be nice to finish a game in that dosn't just crash, but the error is at least 20 turns back in the saved game file, so you just can't go back and try again)
  - KOFOR2 Xbox, then PC  (I will give you this one, at least it did not crash).The only way that this is shifted back to the supplier is through "goodwill".
Until users demand bug free software, and shift the costs back to the developers, this will not change.
From the posts above, there appears to be split on this issue, with some programmers accepting the need not to use up goodwill, and others stating that bugs are a fact of life.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655108</id>
	<title>I couldn't afford anything less...  [Engineer]</title>
	<author>Decker-Mage</author>
	<datestamp>1269864180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>While I was in uniform, I couldn't afford to do anything less than perfect software.  When the potential cost of an error on my part was the loss of life or limb by an individual, or group of individuals, and the penalty for it was a sentence to Ft. Leavenworth, Ks., being guarded by pissed-off US Marines, or possibly even death, that concentrates the mind wonderfully [to mangle a quote].  I think this is a major difference between in approaches that I see throughout this discussion.  To wit, penalties.<br> <br>
Not once in the ten years that I was coding for the military nor in the two decades following (and yes, the software is still in use, typical of the military, and works just fine despite OS changes) was an error ever found.  Therefore, it is possible to write (at the least near-) perfect software.  However, this isn't just about just the penalties.<br> <br>
None of this was easy although it actually took me and my team far less time to successfully complete our projects than is typical of other teams and projects that I've seen over the years.  That is almost entirely due to the fact that we did engineering rather than ego-driven 'development', i.e. we took already existing, provably (mathematically) correct algorithms and data-structures with a heavy dose of built-in error checking in the form of state-machines, what I took to calling design by contract (strictly constrained, enumerated, and validated inputs &amp; outputs), and  extensive inline documentation especially for compiler or OS bugs of which we found more than a few for which fixes had to be encapsulated (hopefully for later removal).<br> <br>
I specifically bring up the time savings since, at first, it didn't seem that way as we easily spent three times longer in the actual design phase (architecture, data-structure definition, algorithm selection, language(s) and tooling selection, etc.) yet the actual coding phase was just a few days and testing also only took days to identify the previously mentioned OS and compiler errors.  This allowed <em>more</em> time to be spent on requirements collection (at least a week of hands on, anthropological interview style with the potential users) and user training during the installation and turn-over phase.  The total project time was just a few weeks, at most, and these were neither unambitious nor small projects.  It did take demonstrated, markedly positive (multi-million dollar ROI), results to convince 'management' that having people staring into space, scratching on legal pads, with stacks of books, and tapping the CompuServe fora (these were the pre-web days) was a <em>good</em> thing.  Furthermore, we could often restructure a work-flow or the entire application in a few hours and they were doing exactly that with one app I had created just a few weeks before the door hit my ass as I was being (medically) discharged from the service.  All my work yet the modifications (a total reversal of work-flow) was happening in mere hours and they were having fun (yes, fun) doing it.<br> <br>
However, I find it highly unlikely that we'll ever see these efforts in the 'real' world given a culture of (barely) 'good-enough', and no liability for fitness let alone correctness {RTF License/User Agreement}.</div>
	</htmltext>
<tokenext>While I was in uniform , I could n't afford to do anything less than perfect software .
When the potential cost of an error on my part was the loss of life or limb by an individual , or group of individuals , and the penalty for it was a sentence to Ft. Leavenworth , Ks. , being guarded by pissed-off US Marines , or possibly even death , that concentrates the mind wonderfully [ to mangle a quote ] .
I think this is a major difference between in approaches that I see throughout this discussion .
To wit , penalties .
Not once in the ten years that I was coding for the military nor in the two decades following ( and yes , the software is still in use , typical of the military , and works just fine despite OS changes ) was an error ever found .
Therefore , it is possible to write ( at the least near- ) perfect software .
However , this is n't just about just the penalties .
None of this was easy although it actually took me and my team far less time to successfully complete our projects than is typical of other teams and projects that I 've seen over the years .
That is almost entirely due to the fact that we did engineering rather than ego-driven 'development ' , i.e .
we took already existing , provably ( mathematically ) correct algorithms and data-structures with a heavy dose of built-in error checking in the form of state-machines , what I took to calling design by contract ( strictly constrained , enumerated , and validated inputs &amp; outputs ) , and extensive inline documentation especially for compiler or OS bugs of which we found more than a few for which fixes had to be encapsulated ( hopefully for later removal ) .
I specifically bring up the time savings since , at first , it did n't seem that way as we easily spent three times longer in the actual design phase ( architecture , data-structure definition , algorithm selection , language ( s ) and tooling selection , etc .
) yet the actual coding phase was just a few days and testing also only took days to identify the previously mentioned OS and compiler errors .
This allowed more time to be spent on requirements collection ( at least a week of hands on , anthropological interview style with the potential users ) and user training during the installation and turn-over phase .
The total project time was just a few weeks , at most , and these were neither unambitious nor small projects .
It did take demonstrated , markedly positive ( multi-million dollar ROI ) , results to convince 'management ' that having people staring into space , scratching on legal pads , with stacks of books , and tapping the CompuServe fora ( these were the pre-web days ) was a good thing .
Furthermore , we could often restructure a work-flow or the entire application in a few hours and they were doing exactly that with one app I had created just a few weeks before the door hit my ass as I was being ( medically ) discharged from the service .
All my work yet the modifications ( a total reversal of work-flow ) was happening in mere hours and they were having fun ( yes , fun ) doing it .
However , I find it highly unlikely that we 'll ever see these efforts in the 'real ' world given a culture of ( barely ) 'good-enough ' , and no liability for fitness let alone correctness { RTF License/User Agreement } .</tokentext>
<sentencetext>While I was in uniform, I couldn't afford to do anything less than perfect software.
When the potential cost of an error on my part was the loss of life or limb by an individual, or group of individuals, and the penalty for it was a sentence to Ft. Leavenworth, Ks., being guarded by pissed-off US Marines, or possibly even death, that concentrates the mind wonderfully [to mangle a quote].
I think this is a major difference between in approaches that I see throughout this discussion.
To wit, penalties.
Not once in the ten years that I was coding for the military nor in the two decades following (and yes, the software is still in use, typical of the military, and works just fine despite OS changes) was an error ever found.
Therefore, it is possible to write (at the least near-) perfect software.
However, this isn't just about just the penalties.
None of this was easy although it actually took me and my team far less time to successfully complete our projects than is typical of other teams and projects that I've seen over the years.
That is almost entirely due to the fact that we did engineering rather than ego-driven 'development', i.e.
we took already existing, provably (mathematically) correct algorithms and data-structures with a heavy dose of built-in error checking in the form of state-machines, what I took to calling design by contract (strictly constrained, enumerated, and validated inputs &amp; outputs), and  extensive inline documentation especially for compiler or OS bugs of which we found more than a few for which fixes had to be encapsulated (hopefully for later removal).
I specifically bring up the time savings since, at first, it didn't seem that way as we easily spent three times longer in the actual design phase (architecture, data-structure definition, algorithm selection, language(s) and tooling selection, etc.
) yet the actual coding phase was just a few days and testing also only took days to identify the previously mentioned OS and compiler errors.
This allowed more time to be spent on requirements collection (at least a week of hands on, anthropological interview style with the potential users) and user training during the installation and turn-over phase.
The total project time was just a few weeks, at most, and these were neither unambitious nor small projects.
It did take demonstrated, markedly positive (multi-million dollar ROI), results to convince 'management' that having people staring into space, scratching on legal pads, with stacks of books, and tapping the CompuServe fora (these were the pre-web days) was a good thing.
Furthermore, we could often restructure a work-flow or the entire application in a few hours and they were doing exactly that with one app I had created just a few weeks before the door hit my ass as I was being (medically) discharged from the service.
All my work yet the modifications (a total reversal of work-flow) was happening in mere hours and they were having fun (yes, fun) doing it.
However, I find it highly unlikely that we'll ever see these efforts in the 'real' world given a culture of (barely) 'good-enough', and no liability for fitness let alone correctness {RTF License/User Agreement}.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648626</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648706</id>
	<title>Uh, Duh?</title>
	<author>Anonymous</author>
	<datestamp>1269802260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Sums it up nicely</p><p>Thank you, think you very much</p></htmltext>
<tokenext>Sums it up nicelyThank you , think you very much</tokentext>
<sentencetext>Sums it up nicelyThank you, think you very much</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31695922</id>
	<title>Oh - bugs-pray!</title>
	<author>freaker\_TuC</author>
	<datestamp>1270043220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And I got bugspray, because it makes bugs pray!</p></htmltext>
<tokenext>And I got bugspray , because it makes bugs pray !</tokentext>
<sentencetext>And I got bugspray, because it makes bugs pray!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649362</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31652130</id>
	<title>Support Contracts</title>
	<author>zlel</author>
	<datestamp>1269785400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Where I am, bugs, half-baked functions and missing features allow expensive software contracts to keep development teams alive.
As soon as software become stable, customers tend to start killing off support contracts.
Well, a little pain, is good for the soul. In this case, the user's pain, for the developers' soul.</htmltext>
<tokenext>Where I am , bugs , half-baked functions and missing features allow expensive software contracts to keep development teams alive .
As soon as software become stable , customers tend to start killing off support contracts .
Well , a little pain , is good for the soul .
In this case , the user 's pain , for the developers ' soul .</tokentext>
<sentencetext>Where I am, bugs, half-baked functions and missing features allow expensive software contracts to keep development teams alive.
As soon as software become stable, customers tend to start killing off support contracts.
Well, a little pain, is good for the soul.
In this case, the user's pain, for the developers' soul.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649086</id>
	<title>Re:Oh Please</title>
	<author>phantomfive</author>
	<datestamp>1269804720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>We'd do it if we could<nobr> <wbr></nobr>... and someday we will.</p></div><p>Really? How? I'm genuinely curious.</p></div>
	</htmltext>
<tokenext>We 'd do it if we could ... and someday we will.Really ?
How ? I 'm genuinely curious .</tokentext>
<sentencetext>We'd do it if we could ... and someday we will.Really?
How? I'm genuinely curious.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650074</id>
	<title>Bug Free Software is Possible</title>
	<author>Anonymous</author>
	<datestamp>1269769200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I just requires a disciplined approach.</p><p>10,000 lines of C<br>0 Bugs</p><p>http://ertos.nicta.com.au/research/l4.verified/</p></htmltext>
<tokenext>I just requires a disciplined approach.10,000 lines of C0 Bugshttp : //ertos.nicta.com.au/research/l4.verified/</tokentext>
<sentencetext>I just requires a disciplined approach.10,000 lines of C0 Bugshttp://ertos.nicta.com.au/research/l4.verified/</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648772</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649500</id>
	<title>Obscure bugs can be fatal ones.</title>
	<author>Garrett Fox</author>
	<datestamp>1269807720000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>The post talks about minor bugs being the ones that are hard to reach, but that's not necessarily the case. There was a piece of radiation-beam hardware used for cancer treatment (the <a href="http://en.wikipedia.org/wiki/Therac-25" title="wikipedia.org">Therac-25</a> [wikipedia.org]), that became a case study in engineering because of a literally fatal flaw. It was possible to mis-configure the machine so that it struck the patient with a much more powerful radiation beam than was normally allowed. The relevant point was, this situation only happened if the operator did some obscure, seemingly unlikely combination of actions that would result in a lead plate getting misaligned or something. Yet it happened at least six times, killing at least two people. The fact that the bug was caused by this particular sequence of actions made it that much harder to identify -- and it was <i>not</i> a minor bug worth ignoring.</htmltext>
<tokenext>The post talks about minor bugs being the ones that are hard to reach , but that 's not necessarily the case .
There was a piece of radiation-beam hardware used for cancer treatment ( the Therac-25 [ wikipedia.org ] ) , that became a case study in engineering because of a literally fatal flaw .
It was possible to mis-configure the machine so that it struck the patient with a much more powerful radiation beam than was normally allowed .
The relevant point was , this situation only happened if the operator did some obscure , seemingly unlikely combination of actions that would result in a lead plate getting misaligned or something .
Yet it happened at least six times , killing at least two people .
The fact that the bug was caused by this particular sequence of actions made it that much harder to identify -- and it was not a minor bug worth ignoring .</tokentext>
<sentencetext>The post talks about minor bugs being the ones that are hard to reach, but that's not necessarily the case.
There was a piece of radiation-beam hardware used for cancer treatment (the Therac-25 [wikipedia.org]), that became a case study in engineering because of a literally fatal flaw.
It was possible to mis-configure the machine so that it struck the patient with a much more powerful radiation beam than was normally allowed.
The relevant point was, this situation only happened if the operator did some obscure, seemingly unlikely combination of actions that would result in a lead plate getting misaligned or something.
Yet it happened at least six times, killing at least two people.
The fact that the bug was caused by this particular sequence of actions made it that much harder to identify -- and it was not a minor bug worth ignoring.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649076</id>
	<title>Other golden rules</title>
	<author>Anonymous</author>
	<datestamp>1269804660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>1. If you're aware of a bug, stop and fix it.<br>2. If you cannot fix a bug quickly, you've got a design problem. Stop and fix it.<br>3. If you have so many bugs that you need a tool to track them, you've got a management problem. Stop and fix it.</p></htmltext>
<tokenext>1 .
If you 're aware of a bug , stop and fix it.2 .
If you can not fix a bug quickly , you 've got a design problem .
Stop and fix it.3 .
If you have so many bugs that you need a tool to track them , you 've got a management problem .
Stop and fix it .</tokentext>
<sentencetext>1.
If you're aware of a bug, stop and fix it.2.
If you cannot fix a bug quickly, you've got a design problem.
Stop and fix it.3.
If you have so many bugs that you need a tool to track them, you've got a management problem.
Stop and fix it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31652224</id>
	<title>Inherently Suspicious</title>
	<author>Anonymous</author>
	<datestamp>1269786240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I've always been inherently suspicious of people who claim to be programmers and then recommend articles like this. Instead of reading the fucking article, why don't you go fix some of your fucking bugs?<nobr> <wbr></nobr>;)</p></htmltext>
<tokenext>I 've always been inherently suspicious of people who claim to be programmers and then recommend articles like this .
Instead of reading the fucking article , why do n't you go fix some of your fucking bugs ?
; )</tokentext>
<sentencetext>I've always been inherently suspicious of people who claim to be programmers and then recommend articles like this.
Instead of reading the fucking article, why don't you go fix some of your fucking bugs?
;)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648626</id>
	<title>Lets look at it another way</title>
	<author>Anonymous</author>
	<datestamp>1269801720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>You cant afford perfect software.</p></htmltext>
<tokenext>You cant afford perfect software .</tokentext>
<sentencetext>You cant afford perfect software.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650236</id>
	<title>Re:Oh Please</title>
	<author>istartedi</author>
	<datestamp>1269770460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I would add, "* perfection can't be achieved within today's software lifecycle's".</p><p>Maybe at some point in the future, the software lifecycle will be longer.
A particularly mature piece of software might be considered "done" from the
standpoint of features.  Then, its lifecycle is indefinite.  You might consider
analog signal decoding as a very simple program with a feature set that is "done".
In the early days of FM radio there was debate about the best circuit for
decoding a signal, then they settled on a particular way of doing it.</p><p>Almost all modern software is considerably more complicated, although I
wager that much of the low-level communication software such as digital
radio and cell phone packet processing is approaching "done", or "perfection".
These are relatively simple programs that have to work with a high degree
of reliability.</p><p>An office suite, OTOH, is way too complicated, with way too many features being
added for this to happen.  However, it's not too hard to imagine that 100 years
from now there will be some kind of standard for office suite features, and you
will be able to get work done in minimum feature mode.  It will virtually never
fail.  Office suites will be DONE.  They'll be perfect.  Fortunately, we'll all
be dead or at the very least retired by then, so there's no need to worry about
programmers losing all their jobs just yet.</p><p>In other words, as you more succinctly put it, "someday we will".</p></htmltext>
<tokenext>I would add , " * perfection ca n't be achieved within today 's software lifecycle 's " .Maybe at some point in the future , the software lifecycle will be longer .
A particularly mature piece of software might be considered " done " from the standpoint of features .
Then , its lifecycle is indefinite .
You might consider analog signal decoding as a very simple program with a feature set that is " done " .
In the early days of FM radio there was debate about the best circuit for decoding a signal , then they settled on a particular way of doing it.Almost all modern software is considerably more complicated , although I wager that much of the low-level communication software such as digital radio and cell phone packet processing is approaching " done " , or " perfection " .
These are relatively simple programs that have to work with a high degree of reliability.An office suite , OTOH , is way too complicated , with way too many features being added for this to happen .
However , it 's not too hard to imagine that 100 years from now there will be some kind of standard for office suite features , and you will be able to get work done in minimum feature mode .
It will virtually never fail .
Office suites will be DONE .
They 'll be perfect .
Fortunately , we 'll all be dead or at the very least retired by then , so there 's no need to worry about programmers losing all their jobs just yet.In other words , as you more succinctly put it , " someday we will " .</tokentext>
<sentencetext>I would add, "* perfection can't be achieved within today's software lifecycle's".Maybe at some point in the future, the software lifecycle will be longer.
A particularly mature piece of software might be considered "done" from the
standpoint of features.
Then, its lifecycle is indefinite.
You might consider
analog signal decoding as a very simple program with a feature set that is "done".
In the early days of FM radio there was debate about the best circuit for
decoding a signal, then they settled on a particular way of doing it.Almost all modern software is considerably more complicated, although I
wager that much of the low-level communication software such as digital
radio and cell phone packet processing is approaching "done", or "perfection".
These are relatively simple programs that have to work with a high degree
of reliability.An office suite, OTOH, is way too complicated, with way too many features being
added for this to happen.
However, it's not too hard to imagine that 100 years
from now there will be some kind of standard for office suite features, and you
will be able to get work done in minimum feature mode.
It will virtually never
fail.
Office suites will be DONE.
They'll be perfect.
Fortunately, we'll all
be dead or at the very least retired by then, so there's no need to worry about
programmers losing all their jobs just yet.In other words, as you more succinctly put it, "someday we will".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649216</id>
	<title>Re:How is this news?</title>
	<author>clarkkent09</author>
	<datestamp>1269805560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yeah, I remember waaaay back the saying was something like it takes 20\% of the time to do the first 80\% of the code, and 80\% of the time to do the remaining 20\%. It would be nice to get every last bug fixed but if you have plans for the rest of your life other than bug fixing you have to draw the line somewhere and get it released.</htmltext>
<tokenext>Yeah , I remember waaaay back the saying was something like it takes 20 \ % of the time to do the first 80 \ % of the code , and 80 \ % of the time to do the remaining 20 \ % .
It would be nice to get every last bug fixed but if you have plans for the rest of your life other than bug fixing you have to draw the line somewhere and get it released .</tokentext>
<sentencetext>Yeah, I remember waaaay back the saying was something like it takes 20\% of the time to do the first 80\% of the code, and 80\% of the time to do the remaining 20\%.
It would be nice to get every last bug fixed but if you have plans for the rest of your life other than bug fixing you have to draw the line somewhere and get it released.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649038</id>
	<title>Re:Oh Please</title>
	<author>Anonymous</author>
	<datestamp>1269804420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext>We'll patiently wait for you to show us your prefect, bug free software. Until then we'll get on with the job of writing the software that you use every day.</htmltext>
<tokenext>We 'll patiently wait for you to show us your prefect , bug free software .
Until then we 'll get on with the job of writing the software that you use every day .</tokentext>
<sentencetext>We'll patiently wait for you to show us your prefect, bug free software.
Until then we'll get on with the job of writing the software that you use every day.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648866</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655306</id>
	<title>Re:The core argument does make sense.</title>
	<author>Draek</author>
	<datestamp>1269867000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The thing is, the 95\%/5\% argument also works for the feature X itself. If feature X works in 95\% of user scenarios and only triggers the obscure bug 5\% of the time, why would you disable the entire thing? just ship it as is and send a "thanks for reporting a bug to us, we're very sorry it happened to you" note to whoever is affected alongside the SP1.</p></htmltext>
<tokenext>The thing is , the 95 \ % /5 \ % argument also works for the feature X itself .
If feature X works in 95 \ % of user scenarios and only triggers the obscure bug 5 \ % of the time , why would you disable the entire thing ?
just ship it as is and send a " thanks for reporting a bug to us , we 're very sorry it happened to you " note to whoever is affected alongside the SP1 .</tokentext>
<sentencetext>The thing is, the 95\%/5\% argument also works for the feature X itself.
If feature X works in 95\% of user scenarios and only triggers the obscure bug 5\% of the time, why would you disable the entire thing?
just ship it as is and send a "thanks for reporting a bug to us, we're very sorry it happened to you" note to whoever is affected alongside the SP1.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648910</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651510</id>
	<title>Re:The core argument does make sense.</title>
	<author>Anonymous</author>
	<datestamp>1269779160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"bug free" is not really an option.</p></htmltext>
<tokenext>" bug free " is not really an option .</tokentext>
<sentencetext>"bug free" is not really an option.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648910</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649720</id>
	<title>Re:How is this news?</title>
	<author>spongman</author>
	<datestamp>1269809520000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>yeah, there's a also a mistaken suggestion that there's a correlation between the severity of the bug and the cost of fixing it.</p><p>in general there isn't.</p><p>you might have a crashing, data-destroying bug that's trivial to fix. or you might have a minor UI annoyance that would require a complete re-write in order to fix, possibly introducing a whole slew of new bugs.</p><p>unless you have a deep understanding of the architecture of the application, there's absolutely no way to judge which class a given bug is in.</p></htmltext>
<tokenext>yeah , there 's a also a mistaken suggestion that there 's a correlation between the severity of the bug and the cost of fixing it.in general there is n't.you might have a crashing , data-destroying bug that 's trivial to fix .
or you might have a minor UI annoyance that would require a complete re-write in order to fix , possibly introducing a whole slew of new bugs.unless you have a deep understanding of the architecture of the application , there 's absolutely no way to judge which class a given bug is in .</tokentext>
<sentencetext>yeah, there's a also a mistaken suggestion that there's a correlation between the severity of the bug and the cost of fixing it.in general there isn't.you might have a crashing, data-destroying bug that's trivial to fix.
or you might have a minor UI annoyance that would require a complete re-write in order to fix, possibly introducing a whole slew of new bugs.unless you have a deep understanding of the architecture of the application, there's absolutely no way to judge which class a given bug is in.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649766</id>
	<title>Re:I'm not sure I buy HAPPY HAIRYPALM SUNDAY</title>
	<author>reformacion</author>
	<datestamp>1269809820000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext>Ratzinger placed his wee wee in my puty pantes.
see <a href="http://prorev.com/" title="prorev.com" rel="nofollow">http://prorev.com/</a> [prorev.com] for breaking headline  POPE CALLS CRITICISM 'PETTY GOSSIP'</htmltext>
<tokenext>Ratzinger placed his wee wee in my puty pantes .
see http : //prorev.com/ [ prorev.com ] for breaking headline POPE CALLS CRITICISM 'PETTY GOSSIP'</tokentext>
<sentencetext>Ratzinger placed his wee wee in my puty pantes.
see http://prorev.com/ [prorev.com] for breaking headline  POPE CALLS CRITICISM 'PETTY GOSSIP'</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648772</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660</id>
	<title>Oh Please</title>
	<author>Anonymous</author>
	<datestamp>1269801900000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>The reason that every piece of software ships with bugs is because:
<br>* It's created by people
<br>* The programmers, testers, etc can never find <i>all</i> the bugs
<br>* It's gotta get out the door so you can <i>pay</i> your programmers, testers, etc
<br>* All of the above
<br> <br>There is a matter of pride with individual programmers, small groups, and most open source programming projects. We'd <b>all</b> love to be able to crow about shipping a bug free project/product. We'd do it if we could<nobr> <wbr></nobr>... and someday we will.</htmltext>
<tokenext>The reason that every piece of software ships with bugs is because : * It 's created by people * The programmers , testers , etc can never find all the bugs * It 's got ta get out the door so you can pay your programmers , testers , etc * All of the above There is a matter of pride with individual programmers , small groups , and most open source programming projects .
We 'd all love to be able to crow about shipping a bug free project/product .
We 'd do it if we could ... and someday we will .</tokentext>
<sentencetext>The reason that every piece of software ships with bugs is because:
* It's created by people
* The programmers, testers, etc can never find all the bugs
* It's gotta get out the door so you can pay your programmers, testers, etc
* All of the above
 There is a matter of pride with individual programmers, small groups, and most open source programming projects.
We'd all love to be able to crow about shipping a bug free project/product.
We'd do it if we could ... and someday we will.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650128</id>
	<title>Crappy excuse alert!</title>
	<author>plopez</author>
	<datestamp>1269769740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you don't have pride in your work, quit. Making excuses for bugs has no excuse. It guarantees you will ship bad software. There is a ratcheting effect. At first you accept some defects, then you accept more, etc.</p><p>And if I was that user I would be angry. I just wasted all that time navigating through all of those menus (also a sign of bad software, too many levels) for no good reason. You just pushed off your lack of caring on to me. I would look for better software. Something which costs me less $$$$ in lost productivity. As a user, the economics of this makes no sense.</p><p>It is exactly this sort of attitude which destroyed the American car companies.</p></htmltext>
<tokenext>If you do n't have pride in your work , quit .
Making excuses for bugs has no excuse .
It guarantees you will ship bad software .
There is a ratcheting effect .
At first you accept some defects , then you accept more , etc.And if I was that user I would be angry .
I just wasted all that time navigating through all of those menus ( also a sign of bad software , too many levels ) for no good reason .
You just pushed off your lack of caring on to me .
I would look for better software .
Something which costs me less $ $ $ $ in lost productivity .
As a user , the economics of this makes no sense.It is exactly this sort of attitude which destroyed the American car companies .</tokentext>
<sentencetext>If you don't have pride in your work, quit.
Making excuses for bugs has no excuse.
It guarantees you will ship bad software.
There is a ratcheting effect.
At first you accept some defects, then you accept more, etc.And if I was that user I would be angry.
I just wasted all that time navigating through all of those menus (also a sign of bad software, too many levels) for no good reason.
You just pushed off your lack of caring on to me.
I would look for better software.
Something which costs me less $$$$ in lost productivity.
As a user, the economics of this makes no sense.It is exactly this sort of attitude which destroyed the American car companies.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649290</id>
	<title>Re:How is this news?</title>
	<author>Anonymous</author>
	<datestamp>1269806100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That was my first thought as well. Thanks for being quick about it.</p></htmltext>
<tokenext>That was my first thought as well .
Thanks for being quick about it .</tokentext>
<sentencetext>That was my first thought as well.
Thanks for being quick about it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649220</id>
	<title>Re:Oh Please</title>
	<author>Vellmont</author>
	<datestamp>1269805560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><i><br>Most coders have to use the code they write. Leaving bugs is not something you do if you know they are there. Sure some people do that, but not the ones that want to get it right<br></i><br>This happens all the time.  Have you never read release notes that have a list of "known bugs"?  Generally that's open source software.  The closed source software has the exact same list, it just exists on the software makers private network.</p><p>Sure, if you KNOW how to fix the bug and it's easy most people will just fix it.  The other cases it depends on the economics.  Open source software isn't any different than closed source in this respect.  Resources are always finite whether they're money or time.</p></htmltext>
<tokenext>Most coders have to use the code they write .
Leaving bugs is not something you do if you know they are there .
Sure some people do that , but not the ones that want to get it rightThis happens all the time .
Have you never read release notes that have a list of " known bugs " ?
Generally that 's open source software .
The closed source software has the exact same list , it just exists on the software makers private network.Sure , if you KNOW how to fix the bug and it 's easy most people will just fix it .
The other cases it depends on the economics .
Open source software is n't any different than closed source in this respect .
Resources are always finite whether they 're money or time .</tokentext>
<sentencetext>Most coders have to use the code they write.
Leaving bugs is not something you do if you know they are there.
Sure some people do that, but not the ones that want to get it rightThis happens all the time.
Have you never read release notes that have a list of "known bugs"?
Generally that's open source software.
The closed source software has the exact same list, it just exists on the software makers private network.Sure, if you KNOW how to fix the bug and it's easy most people will just fix it.
The other cases it depends on the economics.
Open source software isn't any different than closed source in this respect.
Resources are always finite whether they're money or time.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648744</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649266</id>
	<title>Economics of Perfect (Gaming) Software</title>
	<author>macraig</author>
	<datestamp>1269805980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yeah, in my own mind I inserted that extra word in the title, and I was disappointed that it wasn't about that at all.  I'd like to see an article about that, describing how the "perfect" game would be an economic Bad Idea, and including interviews with game developers who finally admit that they deliberately repeat old shortcomings and mistakes and stop short of perfection, knowing that the perfect game would completely destroy the market for next year's game.  I can think of one or two that actually tried to damn the torpedoes and thwart this dynamic, but ultimately they got shut down by the suits holding the purse strings.</p></htmltext>
<tokenext>Yeah , in my own mind I inserted that extra word in the title , and I was disappointed that it was n't about that at all .
I 'd like to see an article about that , describing how the " perfect " game would be an economic Bad Idea , and including interviews with game developers who finally admit that they deliberately repeat old shortcomings and mistakes and stop short of perfection , knowing that the perfect game would completely destroy the market for next year 's game .
I can think of one or two that actually tried to damn the torpedoes and thwart this dynamic , but ultimately they got shut down by the suits holding the purse strings .</tokentext>
<sentencetext>Yeah, in my own mind I inserted that extra word in the title, and I was disappointed that it wasn't about that at all.
I'd like to see an article about that, describing how the "perfect" game would be an economic Bad Idea, and including interviews with game developers who finally admit that they deliberately repeat old shortcomings and mistakes and stop short of perfection, knowing that the perfect game would completely destroy the market for next year's game.
I can think of one or two that actually tried to damn the torpedoes and thwart this dynamic, but ultimately they got shut down by the suits holding the purse strings.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649144</id>
	<title>That's a symptom, not a bug.</title>
	<author>John Hasler</author>
	<datestamp>1269805140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; If a user who goes through three levels of menus, opens an advanced<br>&gt; configuration window, checks three checkboxes, and hits the 'A' key<br>&gt; gets a weird error message for his trouble, that's a little bug.</p><p>That's a symptom, not a bug.  It could be a symptom of a buffer overflow that, if not fixed, will soon be exploited to clean out the bank accounts of 100,000 of your customers.  You won't know until you've fixed it.</p></htmltext>
<tokenext>&gt; If a user who goes through three levels of menus , opens an advanced &gt; configuration window , checks three checkboxes , and hits the 'A ' key &gt; gets a weird error message for his trouble , that 's a little bug.That 's a symptom , not a bug .
It could be a symptom of a buffer overflow that , if not fixed , will soon be exploited to clean out the bank accounts of 100,000 of your customers .
You wo n't know until you 've fixed it .</tokentext>
<sentencetext>&gt; If a user who goes through three levels of menus, opens an advanced&gt; configuration window, checks three checkboxes, and hits the 'A' key&gt; gets a weird error message for his trouble, that's a little bug.That's a symptom, not a bug.
It could be a symptom of a buffer overflow that, if not fixed, will soon be exploited to clean out the bank accounts of 100,000 of your customers.
You won't know until you've fixed it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655154</id>
	<title>Re:How is this news?</title>
	<author>Anonymous</author>
	<datestamp>1269864780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You don't need an economics degree to know this, even school kids have always figured out that it's easier to jump from 70\% to 85\%, but it gets exponentially harder to increase the score as you approach 100\%.</p></htmltext>
<tokenext>You do n't need an economics degree to know this , even school kids have always figured out that it 's easier to jump from 70 \ % to 85 \ % , but it gets exponentially harder to increase the score as you approach 100 \ % .</tokentext>
<sentencetext>You don't need an economics degree to know this, even school kids have always figured out that it's easier to jump from 70\% to 85\%, but it gets exponentially harder to increase the score as you approach 100\%.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649256</id>
	<title>This sounds like the Ford Pinto design philosophy</title>
	<author>countertrolling</author>
	<datestamp>1269805920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Leave in "little" flaws to save a buck. Well we all know what happened there.</p></htmltext>
<tokenext>Leave in " little " flaws to save a buck .
Well we all know what happened there .</tokentext>
<sentencetext>Leave in "little" flaws to save a buck.
Well we all know what happened there.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649760</id>
	<title>Re:How is this news?</title>
	<author>spongman</author>
	<datestamp>1269809760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>i just hope your boss is smart enough to know this so that once your company fails he'll  warn all your potential future employers not to hire you.</p></htmltext>
<tokenext>i just hope your boss is smart enough to know this so that once your company fails he 'll warn all your potential future employers not to hire you .</tokentext>
<sentencetext>i just hope your boss is smart enough to know this so that once your company fails he'll  warn all your potential future employers not to hire you.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648958</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648946</id>
	<title>sometimes crash == possible exploit</title>
	<author>Eponymous Coward</author>
	<datestamp>1269803760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>It isn't always easy to judge the severity of bugs. Exploits often grow from a black hat figuring out how to crash a program. Some of the greatest exploits started with the smallest of footholds.</p></htmltext>
<tokenext>It is n't always easy to judge the severity of bugs .
Exploits often grow from a black hat figuring out how to crash a program .
Some of the greatest exploits started with the smallest of footholds .</tokentext>
<sentencetext>It isn't always easy to judge the severity of bugs.
Exploits often grow from a black hat figuring out how to crash a program.
Some of the greatest exploits started with the smallest of footholds.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651672</id>
	<title>features versus bugs</title>
	<author>BradMajors</author>
	<datestamp>1269780660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If it is OK for some obscure features to have bugs, then this is an indication that these features are not really needed.  The solution is neither to fix or not fix bugs in this feature but rather to remove the feature entirely.</p></htmltext>
<tokenext>If it is OK for some obscure features to have bugs , then this is an indication that these features are not really needed .
The solution is neither to fix or not fix bugs in this feature but rather to remove the feature entirely .</tokentext>
<sentencetext>If it is OK for some obscure features to have bugs, then this is an indication that these features are not really needed.
The solution is neither to fix or not fix bugs in this feature but rather to remove the feature entirely.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648754</id>
	<title>Wrong name</title>
	<author>Anonymous</author>
	<datestamp>1269802500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It should have been Perfect Software-Econonmy or something like that. The Perfect Software(tm) has zero bugs, and if such a program ever happens, its cost will be very high.</htmltext>
<tokenext>It should have been Perfect Software-Econonmy or something like that .
The Perfect Software ( tm ) has zero bugs , and if such a program ever happens , its cost will be very high .</tokentext>
<sentencetext>It should have been Perfect Software-Econonmy or something like that.
The Perfect Software(tm) has zero bugs, and if such a program ever happens, its cost will be very high.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31666472</id>
	<title>severity levels</title>
	<author>Anonymous</author>
	<datestamp>1269883860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>One shop I worked in assigned each 'issue' a severity level from 1 to 4:</p><p>
&nbsp; &nbsp; 1:<br>
&nbsp; &nbsp; &nbsp; &nbsp; - program crashed<br>
&nbsp; &nbsp; &nbsp; &nbsp; - loss of user-entered info<br>
&nbsp; &nbsp; &nbsp; &nbsp; - wrong answer given and it wasn't obviously wrong (from customer's point of view)</p><p>
&nbsp; &nbsp; 2:  obviously wrong answer, no workaround</p><p>
&nbsp; &nbsp; 3:  obviously wrong answer, workaround available</p><p>
&nbsp; &nbsp; 4:  minor issue, such as documentation typo, consistency of UI, etc.</p><p>The 'how easy' to trigger aspect of the issue was only informally considered when prioritizing issues w/in a level.</p><p>
&nbsp; &nbsp;</p></htmltext>
<tokenext>One shop I worked in assigned each 'issue ' a severity level from 1 to 4 :     1 :         - program crashed         - loss of user-entered info         - wrong answer given and it was n't obviously wrong ( from customer 's point of view )     2 : obviously wrong answer , no workaround     3 : obviously wrong answer , workaround available     4 : minor issue , such as documentation typo , consistency of UI , etc.The 'how easy ' to trigger aspect of the issue was only informally considered when prioritizing issues w/in a level .
   </tokentext>
<sentencetext>One shop I worked in assigned each 'issue' a severity level from 1 to 4:
    1:
        - program crashed
        - loss of user-entered info
        - wrong answer given and it wasn't obviously wrong (from customer's point of view)
    2:  obviously wrong answer, no workaround
    3:  obviously wrong answer, workaround available
    4:  minor issue, such as documentation typo, consistency of UI, etc.The 'how easy' to trigger aspect of the issue was only informally considered when prioritizing issues w/in a level.
   </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651960</id>
	<title>Re:That guy is a crank</title>
	<author>Anonymous</author>
	<datestamp>1269783540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Check out his free energy rants, and other quality postings which involve denouncing science and insulting every forum that mentions his blog in a bad light. He could be a professional troll for his day job, but this is the internet.</p></htmltext>
<tokenext>Check out his free energy rants , and other quality postings which involve denouncing science and insulting every forum that mentions his blog in a bad light .
He could be a professional troll for his day job , but this is the internet .</tokentext>
<sentencetext>Check out his free energy rants, and other quality postings which involve denouncing science and insulting every forum that mentions his blog in a bad light.
He could be a professional troll for his day job, but this is the internet.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649790</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648730</id>
	<title>Dangerous approach</title>
	<author>Anonymous</author>
	<datestamp>1269802380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>This sounds a lot like the "Good Enough Software" policies that certain companies used to have.  It's true that having a few minor bugs is acceptable; in fact, it's pretty much inevitable.  But you should expect to have bugs that you haven't even noticed at the time you ship your software.  If you start ignoring the bugs you do know about, you increase the total number considerably.  From there, it's a slippery slope.  Pretty soon, you'll be answering bug reports with a chorus of "Minor, leave it," and your code will be riddled with tons of minor bugs.  Your users will go from "huh" to "what?" to "dammit" to "f*ck this!"  Your software will look sloppy and unprofessional, and even if none of the bugs are showstoppers, your customers will be looking for alternatives.</p></htmltext>
<tokenext>This sounds a lot like the " Good Enough Software " policies that certain companies used to have .
It 's true that having a few minor bugs is acceptable ; in fact , it 's pretty much inevitable .
But you should expect to have bugs that you have n't even noticed at the time you ship your software .
If you start ignoring the bugs you do know about , you increase the total number considerably .
From there , it 's a slippery slope .
Pretty soon , you 'll be answering bug reports with a chorus of " Minor , leave it , " and your code will be riddled with tons of minor bugs .
Your users will go from " huh " to " what ?
" to " dammit " to " f * ck this !
" Your software will look sloppy and unprofessional , and even if none of the bugs are showstoppers , your customers will be looking for alternatives .</tokentext>
<sentencetext>This sounds a lot like the "Good Enough Software" policies that certain companies used to have.
It's true that having a few minor bugs is acceptable; in fact, it's pretty much inevitable.
But you should expect to have bugs that you haven't even noticed at the time you ship your software.
If you start ignoring the bugs you do know about, you increase the total number considerably.
From there, it's a slippery slope.
Pretty soon, you'll be answering bug reports with a chorus of "Minor, leave it," and your code will be riddled with tons of minor bugs.
Your users will go from "huh" to "what?
" to "dammit" to "f*ck this!
"  Your software will look sloppy and unprofessional, and even if none of the bugs are showstoppers, your customers will be looking for alternatives.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648866</id>
	<title>Re:Oh Please</title>
	<author>Anonymous</author>
	<datestamp>1269803220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The reason that every piece of software ships with defects is because:<br>* It's created by people who think defects are inevitable<br>* The programmers, testers, etc spend all their time fixing defects after they have been introduced rather then trying to never introduce them in the first place<br>* It's gotta get out the door and capitalism treats low quality as a PR problem, instead of a people problem.<br>* All of the above</p><p>There.. fixed it for you<nobr> <wbr></nobr>;-)</p></htmltext>
<tokenext>The reason that every piece of software ships with defects is because : * It 's created by people who think defects are inevitable * The programmers , testers , etc spend all their time fixing defects after they have been introduced rather then trying to never introduce them in the first place * It 's got ta get out the door and capitalism treats low quality as a PR problem , instead of a people problem .
* All of the aboveThere.. fixed it for you ; - )</tokentext>
<sentencetext>The reason that every piece of software ships with defects is because:* It's created by people who think defects are inevitable* The programmers, testers, etc spend all their time fixing defects after they have been introduced rather then trying to never introduce them in the first place* It's gotta get out the door and capitalism treats low quality as a PR problem, instead of a people problem.
* All of the aboveThere.. fixed it for you ;-)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650102</id>
	<title>Diminishing returns for who?</title>
	<author>Anonymous</author>
	<datestamp>1269769500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Sure, there are diminishing returns from the corporate payroll/sales perspective, but even tiny bugs tap manpower out of your customers, and as such, put a drain on the economy.</p><p>Hours of my time every week are spent working around bugs that the OP would probably have considered too minor to be worth fixing.  It's all nickel and dime stuff -- five or ten minutes here or there, sometimes even just seconds, but many times a day.  We'd use less buggy software, but it doesn't exist.  Sometimes we fix the bugs and push it upstream if it is OpenSource, but a lot of it isn't.  It's almost never worth our time to do it for our own purposes, but it is worth it when you consider the total user base.<nobr> <wbr></nobr>/me contemplates the total manpower cost of most network administration UIs not being able to figure out that 0024.81b3.ff3e or 00-24-81-b3-ff-3e or 002481-b3ff3e are MAC addresses.</p></htmltext>
<tokenext>Sure , there are diminishing returns from the corporate payroll/sales perspective , but even tiny bugs tap manpower out of your customers , and as such , put a drain on the economy.Hours of my time every week are spent working around bugs that the OP would probably have considered too minor to be worth fixing .
It 's all nickel and dime stuff -- five or ten minutes here or there , sometimes even just seconds , but many times a day .
We 'd use less buggy software , but it does n't exist .
Sometimes we fix the bugs and push it upstream if it is OpenSource , but a lot of it is n't .
It 's almost never worth our time to do it for our own purposes , but it is worth it when you consider the total user base .
/me contemplates the total manpower cost of most network administration UIs not being able to figure out that 0024.81b3.ff3e or 00-24-81-b3-ff-3e or 002481-b3ff3e are MAC addresses .</tokentext>
<sentencetext>Sure, there are diminishing returns from the corporate payroll/sales perspective, but even tiny bugs tap manpower out of your customers, and as such, put a drain on the economy.Hours of my time every week are spent working around bugs that the OP would probably have considered too minor to be worth fixing.
It's all nickel and dime stuff -- five or ten minutes here or there, sometimes even just seconds, but many times a day.
We'd use less buggy software, but it doesn't exist.
Sometimes we fix the bugs and push it upstream if it is OpenSource, but a lot of it isn't.
It's almost never worth our time to do it for our own purposes, but it is worth it when you consider the total user base.
/me contemplates the total manpower cost of most network administration UIs not being able to figure out that 0024.81b3.ff3e or 00-24-81-b3-ff-3e or 002481-b3ff3e are MAC addresses.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31653148</id>
	<title>yeah</title>
	<author>jdc18</author>
	<datestamp>1269795900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>That is why i always leave bugs, it is not because i am a sloppy programmer</htmltext>
<tokenext>That is why i always leave bugs , it is not because i am a sloppy programmer</tokentext>
<sentencetext>That is why i always leave bugs, it is not because i am a sloppy programmer</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31652940</id>
	<title>Re:I'm not sure I buy the argument</title>
	<author>thoughtsatthemoment</author>
	<datestamp>1269794160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If we have a bunch of top notch disciplined programmers to begin with, we'd all be building paradise by now. The problem is, you almost always have to start with existing code with other programmers with varied quality, especially in a company. The cost of rewrite is simply too high.

As to being disciplined, well, you can easily be disciplined in doing things with the wrong approach. Many programmers like to talk about best practices, but that's just the best practices KNOWN to them.</htmltext>
<tokenext>If we have a bunch of top notch disciplined programmers to begin with , we 'd all be building paradise by now .
The problem is , you almost always have to start with existing code with other programmers with varied quality , especially in a company .
The cost of rewrite is simply too high .
As to being disciplined , well , you can easily be disciplined in doing things with the wrong approach .
Many programmers like to talk about best practices , but that 's just the best practices KNOWN to them .</tokentext>
<sentencetext>If we have a bunch of top notch disciplined programmers to begin with, we'd all be building paradise by now.
The problem is, you almost always have to start with existing code with other programmers with varied quality, especially in a company.
The cost of rewrite is simply too high.
As to being disciplined, well, you can easily be disciplined in doing things with the wrong approach.
Many programmers like to talk about best practices, but that's just the best practices KNOWN to them.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648772</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651728</id>
	<title>Re:How is this news?</title>
	<author>Anonymous</author>
	<datestamp>1269781140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Only if you assume that bugs are like needle in haystacks; you only need to find them.</p><p>Finding the source of a bug and fixing it may very well lead to a multitude of other bugs.</p><p>It's like finding a needle in the haystack, taking it out, and in doing so, more needles somehow spawn within the haystack.</p></htmltext>
<tokenext>Only if you assume that bugs are like needle in haystacks ; you only need to find them.Finding the source of a bug and fixing it may very well lead to a multitude of other bugs.It 's like finding a needle in the haystack , taking it out , and in doing so , more needles somehow spawn within the haystack .</tokentext>
<sentencetext>Only if you assume that bugs are like needle in haystacks; you only need to find them.Finding the source of a bug and fixing it may very well lead to a multitude of other bugs.It's like finding a needle in the haystack, taking it out, and in doing so, more needles somehow spawn within the haystack.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648632</id>
	<title>Leaving bugs is not professional</title>
	<author>Anonymous</author>
	<datestamp>1269801780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Fix them all, you basterds!</p></htmltext>
<tokenext>Fix them all , you basterds !</tokentext>
<sentencetext>Fix them all, you basterds!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651406</id>
	<title>You can ship solid software</title>
	<author>Anonymous</author>
	<datestamp>1269778500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That is nearly bug free.  The "trick" is to have well defined interfaces and to write tests at unit, integration and program levels that exercise every line of code with boundary conditions.  When you find new bugs, add them to the tests, then work to make the tests you added pass without breaking anything else.</p><p>You can even do things like looping the tests and profiling your program to make sure it's performance is as good as it can be at every level.</p></htmltext>
<tokenext>That is nearly bug free .
The " trick " is to have well defined interfaces and to write tests at unit , integration and program levels that exercise every line of code with boundary conditions .
When you find new bugs , add them to the tests , then work to make the tests you added pass without breaking anything else.You can even do things like looping the tests and profiling your program to make sure it 's performance is as good as it can be at every level .</tokentext>
<sentencetext>That is nearly bug free.
The "trick" is to have well defined interfaces and to write tests at unit, integration and program levels that exercise every line of code with boundary conditions.
When you find new bugs, add them to the tests, then work to make the tests you added pass without breaking anything else.You can even do things like looping the tests and profiling your program to make sure it's performance is as good as it can be at every level.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651218</id>
	<title>What?</title>
	<author>Mr0bvious</author>
	<datestamp>1269777060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>So user impact being considered when assessing a bug's criticality is uncommon?</htmltext>
<tokenext>So user impact being considered when assessing a bug 's criticality is uncommon ?</tokentext>
<sentencetext>So user impact being considered when assessing a bug's criticality is uncommon?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649072</id>
	<title>It's *intended* accleration...</title>
	<author>Anonymous</author>
	<datestamp>1269804600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Did Toyota Sponsor this article?  Really, it's a *little* bug, we should just let it go....</p></htmltext>
<tokenext>Did Toyota Sponsor this article ?
Really , it 's a * little * bug , we should just let it go... .</tokentext>
<sentencetext>Did Toyota Sponsor this article?
Really, it's a *little* bug, we should just let it go....</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31653278</id>
	<title>Perfection can be bad for business</title>
	<author>Anonymous</author>
	<datestamp>1269797280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>My code does its basic job so well, nobody wants to pay for upgrades or maintenance.</p></htmltext>
<tokenext>My code does its basic job so well , nobody wants to pay for upgrades or maintenance .</tokentext>
<sentencetext>My code does its basic job so well, nobody wants to pay for upgrades or maintenance.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649362</id>
	<title>Re:Oh Please</title>
	<author>Tablizer</author>
	<datestamp>1269806580000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p> The reason that every piece of software ships with bugs is because:...It's created by people...</p></div> </blockquote><p>I'm breeding cockroaches to write code. How ironic: bugs will solve bugs.<br>
&nbsp; &nbsp;</p></div>
	</htmltext>
<tokenext>The reason that every piece of software ships with bugs is because : ...It 's created by people... I 'm breeding cockroaches to write code .
How ironic : bugs will solve bugs .
   </tokentext>
<sentencetext> The reason that every piece of software ships with bugs is because:...It's created by people... I'm breeding cockroaches to write code.
How ironic: bugs will solve bugs.
   
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648866
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31695922
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649362
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648760
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31654522
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648958
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31654348
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649086
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651960
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649790
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649874
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649316
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648698
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649720
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655306
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649290
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649224
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649220
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648744
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651068
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655108
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648626
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650750
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650048
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648730
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649760
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648958
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31653010
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648958
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650494
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650078
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650074
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648772
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650236
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650102
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649628
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648750
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649334
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648700
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655154
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651510
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648910
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649216
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31652940
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648772
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648772
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_28_167251_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651728
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648772
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649766
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650074
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31652940
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648750
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649628
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648626
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649874
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655108
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648754
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649162
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648632
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648660
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648744
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649220
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649224
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648760
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650078
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649086
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649362
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31695922
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648866
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649038
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650236
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648730
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650048
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651716
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648910
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31654348
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651510
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655306
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648618
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649720
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651068
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31655154
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650494
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649216
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649790
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651960
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31651728
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650750
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31650102
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649290
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648958
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31654522
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649760
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31653010
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649144
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649266
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649072
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649238
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648700
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649334
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648862
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649500
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_28_167251.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31648698
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_28_167251.31649316
</commentlist>
</conversation>
