<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_11_17_005210</id>
	<title>We Really Don't Know Jack About Maintenance</title>
	<author>kdawson</author>
	<datestamp>1258466760000</datestamp>
	<htmltext>davecb writes <i>"The ACM has been kind enough to print Paul Stachour's and my 'jack' article about Software Maintenance. Paul first pointed out back in 1984 that we and our managers were being foolish &mdash; when we were still running Unix V7 &mdash; and if anything it's been getting worse. Turns out maintenance has been a 'solved problem in computer science' since at least then, and <a href="http://cacm.acm.org/magazines/2009/11/48444-you-dont-know-jack-about-software-maintenance/fulltext">we're just beginning to rediscover it</a>."</i></htmltext>
<tokenext>davecb writes " The ACM has been kind enough to print Paul Stachour 's and my 'jack ' article about Software Maintenance .
Paul first pointed out back in 1984 that we and our managers were being foolish    when we were still running Unix V7    and if anything it 's been getting worse .
Turns out maintenance has been a 'solved problem in computer science ' since at least then , and we 're just beginning to rediscover it .
"</tokentext>
<sentencetext>davecb writes "The ACM has been kind enough to print Paul Stachour's and my 'jack' article about Software Maintenance.
Paul first pointed out back in 1984 that we and our managers were being foolish — when we were still running Unix V7 — and if anything it's been getting worse.
Turns out maintenance has been a 'solved problem in computer science' since at least then, and we're just beginning to rediscover it.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30138614</id>
	<title>How to combat the probllems of modern systems</title>
	<author>Orion Blastar</author>
	<datestamp>1258470840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The Classic Computer Science college courses in the 1980's and on back to the 1950's taught the following things:</p><p>Software Psychology<br>Software Maintenance<br>Analysis and Design<br>Logical Methods<br>Quality Control<br>Writing Secure Code<br>Writing Optimized Code<br>Best Coding Practices<br>Debugging<br>Scaling<br>Migrating Legacy Software<br>Managing Garbage Collection<br>Managing Memory Usage</p><p>And many more.</p><p>The Modern Computer Science from the 1990's on up to now, has skipped many steps above and just goes on to writing the software code and not worrying about anything else. Which is a lot like teaching Natural Science classes without even bothering to follow the Scientific Method. The Above are the Computer Scientific Method of Computer Science, but somehow got over looked and thrown out of the modern Computer Science classes.</p><p>For example many Computer Science students couldn't handle garbage collection and memory management so they had invented Java and C# and other programming languages to do it for them. It is because of lack of optmized code and memory management that we get huge programs that need a 3Ghz or faster processor and at least 3Gigs of RAM to run, when really a 200Mhz processor and 512M of RAM would be enough to do the same thing with garbage collection and memory management.</p><p>I am not the old guy saying "Get off my lawn!" I am the exceptional old school comp sci worker saying we need to "think up nifty new ways on how to combat the problems that we currently have in the computer industry" by improving upon our computer science skills and adding in the above to them to solve those problems. I am not even close to retirement age, but I know a broken system when I see one. The current comp sci system is broken, and colleges are not teaching the right stuff we need to "think up nifty new ways on how to combat the problems that we currently have in the computer industry" and very few if any are teaching that.</p><p>We need to bring these old school skills to the 21st century and modernize them.</p><p>If the current computer scientists refuse to write books on the subject, and shun people like me, then I guess people like me are going to have to school the young and old with books on those subjects and make millions selling them to the clueless and the firms that have no idea how to fix their own problems. I'm Orion Blastar, and I am coming to save your arse with a different and better way of developing code and an improved computer science, not seen since the days of Ben Snyderman.</p><p>Make way for Fringe Computer Science and Modern 21st Century Computer Science.</p></htmltext>
<tokenext>The Classic Computer Science college courses in the 1980 's and on back to the 1950 's taught the following things : Software PsychologySoftware MaintenanceAnalysis and DesignLogical MethodsQuality ControlWriting Secure CodeWriting Optimized CodeBest Coding PracticesDebuggingScalingMigrating Legacy SoftwareManaging Garbage CollectionManaging Memory UsageAnd many more.The Modern Computer Science from the 1990 's on up to now , has skipped many steps above and just goes on to writing the software code and not worrying about anything else .
Which is a lot like teaching Natural Science classes without even bothering to follow the Scientific Method .
The Above are the Computer Scientific Method of Computer Science , but somehow got over looked and thrown out of the modern Computer Science classes.For example many Computer Science students could n't handle garbage collection and memory management so they had invented Java and C # and other programming languages to do it for them .
It is because of lack of optmized code and memory management that we get huge programs that need a 3Ghz or faster processor and at least 3Gigs of RAM to run , when really a 200Mhz processor and 512M of RAM would be enough to do the same thing with garbage collection and memory management.I am not the old guy saying " Get off my lawn !
" I am the exceptional old school comp sci worker saying we need to " think up nifty new ways on how to combat the problems that we currently have in the computer industry " by improving upon our computer science skills and adding in the above to them to solve those problems .
I am not even close to retirement age , but I know a broken system when I see one .
The current comp sci system is broken , and colleges are not teaching the right stuff we need to " think up nifty new ways on how to combat the problems that we currently have in the computer industry " and very few if any are teaching that.We need to bring these old school skills to the 21st century and modernize them.If the current computer scientists refuse to write books on the subject , and shun people like me , then I guess people like me are going to have to school the young and old with books on those subjects and make millions selling them to the clueless and the firms that have no idea how to fix their own problems .
I 'm Orion Blastar , and I am coming to save your arse with a different and better way of developing code and an improved computer science , not seen since the days of Ben Snyderman.Make way for Fringe Computer Science and Modern 21st Century Computer Science .</tokentext>
<sentencetext>The Classic Computer Science college courses in the 1980's and on back to the 1950's taught the following things:Software PsychologySoftware MaintenanceAnalysis and DesignLogical MethodsQuality ControlWriting Secure CodeWriting Optimized CodeBest Coding PracticesDebuggingScalingMigrating Legacy SoftwareManaging Garbage CollectionManaging Memory UsageAnd many more.The Modern Computer Science from the 1990's on up to now, has skipped many steps above and just goes on to writing the software code and not worrying about anything else.
Which is a lot like teaching Natural Science classes without even bothering to follow the Scientific Method.
The Above are the Computer Scientific Method of Computer Science, but somehow got over looked and thrown out of the modern Computer Science classes.For example many Computer Science students couldn't handle garbage collection and memory management so they had invented Java and C# and other programming languages to do it for them.
It is because of lack of optmized code and memory management that we get huge programs that need a 3Ghz or faster processor and at least 3Gigs of RAM to run, when really a 200Mhz processor and 512M of RAM would be enough to do the same thing with garbage collection and memory management.I am not the old guy saying "Get off my lawn!
" I am the exceptional old school comp sci worker saying we need to "think up nifty new ways on how to combat the problems that we currently have in the computer industry" by improving upon our computer science skills and adding in the above to them to solve those problems.
I am not even close to retirement age, but I know a broken system when I see one.
The current comp sci system is broken, and colleges are not teaching the right stuff we need to "think up nifty new ways on how to combat the problems that we currently have in the computer industry" and very few if any are teaching that.We need to bring these old school skills to the 21st century and modernize them.If the current computer scientists refuse to write books on the subject, and shun people like me, then I guess people like me are going to have to school the young and old with books on those subjects and make millions selling them to the clueless and the firms that have no idea how to fix their own problems.
I'm Orion Blastar, and I am coming to save your arse with a different and better way of developing code and an improved computer science, not seen since the days of Ben Snyderman.Make way for Fringe Computer Science and Modern 21st Century Computer Science.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30131090</id>
	<title>That is not what the OP was talking about</title>
	<author>SuperKendall</author>
	<datestamp>1258483140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Perfective maintenance makes the application easier to maintain in the future.</i></p><p>The original poster had this to say:</p><p><i>Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.</i></p><p>Reducing bug counts is software maintenance as we know it (it's why you are there), not perfective.</p><p>Cutting code size, I could possibly see as perfective although that should be done with a lot of testing around it.  Changing formatting, is actually rather bad in a maintenance role as it increases the amount of code to review for no good reason (I personally find such changes neutral in regards to the ability for others to understand code).</p><p>Adding functionality though?  No way is that "making an application easier to maintain"</p><p>I don't really see his comments as relating to Perfective kinds of maintenance.  I was mostly reacting with horror to the "add new features" aspect which is development.</p></htmltext>
<tokenext>Perfective maintenance makes the application easier to maintain in the future.The original poster had this to say : Taking code and cutting its size by half , fixing up all the screwed-up inconsistent formatting , while adding functionality and reducing bug counts , is a pleasure.Reducing bug counts is software maintenance as we know it ( it 's why you are there ) , not perfective.Cutting code size , I could possibly see as perfective although that should be done with a lot of testing around it .
Changing formatting , is actually rather bad in a maintenance role as it increases the amount of code to review for no good reason ( I personally find such changes neutral in regards to the ability for others to understand code ) .Adding functionality though ?
No way is that " making an application easier to maintain " I do n't really see his comments as relating to Perfective kinds of maintenance .
I was mostly reacting with horror to the " add new features " aspect which is development .</tokentext>
<sentencetext>Perfective maintenance makes the application easier to maintain in the future.The original poster had this to say:Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.Reducing bug counts is software maintenance as we know it (it's why you are there), not perfective.Cutting code size, I could possibly see as perfective although that should be done with a lot of testing around it.
Changing formatting, is actually rather bad in a maintenance role as it increases the amount of code to review for no good reason (I personally find such changes neutral in regards to the ability for others to understand code).Adding functionality though?
No way is that "making an application easier to maintain"I don't really see his comments as relating to Perfective kinds of maintenance.
I was mostly reacting with horror to the "add new features" aspect which is development.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126954</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127926</id>
	<title>Just me?</title>
	<author>aflag</author>
	<datestamp>1258466820000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Was it just me who thought the article was awful? What it described was nothing more than versioning for applications. I fail to see how what he described as good practice was different from his openoffice wanting to be updated. Was it the need to restart the program afterwards? All examples he provided seem to need to restart at least one program.

In the case of the addition of Canada, for instance, the whole server had to be updated and, I assume, it needed to be restarted. Then he said there was two version of the software, one in canada and one in the US that used the same server. If the clients talk to the server using any reasonable protocol the server would be able to handle both versions just as easy. It could be the case that the only difference is that one client is able to send one sort of message that the other isn't. I can hardly think of a software that has the maintaince problems he exposes.

When he goes on to talk about the glibc with an old version of linux kernel. That library exists exactly to export an interface that any program -- old or new -- can use. It does that by communicating with the kernel directly, and I think it's pretty reasonable for one or two functions to stop working on old versions of ther kernel.</htmltext>
<tokenext>Was it just me who thought the article was awful ?
What it described was nothing more than versioning for applications .
I fail to see how what he described as good practice was different from his openoffice wanting to be updated .
Was it the need to restart the program afterwards ?
All examples he provided seem to need to restart at least one program .
In the case of the addition of Canada , for instance , the whole server had to be updated and , I assume , it needed to be restarted .
Then he said there was two version of the software , one in canada and one in the US that used the same server .
If the clients talk to the server using any reasonable protocol the server would be able to handle both versions just as easy .
It could be the case that the only difference is that one client is able to send one sort of message that the other is n't .
I can hardly think of a software that has the maintaince problems he exposes .
When he goes on to talk about the glibc with an old version of linux kernel .
That library exists exactly to export an interface that any program -- old or new -- can use .
It does that by communicating with the kernel directly , and I think it 's pretty reasonable for one or two functions to stop working on old versions of ther kernel .</tokentext>
<sentencetext>Was it just me who thought the article was awful?
What it described was nothing more than versioning for applications.
I fail to see how what he described as good practice was different from his openoffice wanting to be updated.
Was it the need to restart the program afterwards?
All examples he provided seem to need to restart at least one program.
In the case of the addition of Canada, for instance, the whole server had to be updated and, I assume, it needed to be restarted.
Then he said there was two version of the software, one in canada and one in the US that used the same server.
If the clients talk to the server using any reasonable protocol the server would be able to handle both versions just as easy.
It could be the case that the only difference is that one client is able to send one sort of message that the other isn't.
I can hardly think of a software that has the maintaince problems he exposes.
When he goes on to talk about the glibc with an old version of linux kernel.
That library exists exactly to export an interface that any program -- old or new -- can use.
It does that by communicating with the kernel directly, and I think it's pretty reasonable for one or two functions to stop working on old versions of ther kernel.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125336</id>
	<title>six sigma</title>
	<author>bunbuntheminilop</author>
	<datestamp>1258387740000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext>Could a six sigma program help here? A systematic and structured approach to problem solving is needed. Whenever someone fixes a bug that creates a new bug, then it's a waste of everyone time and effort.</htmltext>
<tokenext>Could a six sigma program help here ?
A systematic and structured approach to problem solving is needed .
Whenever someone fixes a bug that creates a new bug , then it 's a waste of everyone time and effort .</tokentext>
<sentencetext>Could a six sigma program help here?
A systematic and structured approach to problem solving is needed.
Whenever someone fixes a bug that creates a new bug, then it's a waste of everyone time and effort.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127426</id>
	<title>Re:Wait a second...</title>
	<author>Fred\_A</author>
	<datestamp>1258458960000</datestamp>
	<modclass>Funny</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>Doesn't modular programming solve this problem?</p></div><p>Theory, I'd like to introduce you to practice. You two are very different, you should have lots of things to talk about.</p></div>
	</htmltext>
<tokenext>Does n't modular programming solve this problem ? Theory , I 'd like to introduce you to practice .
You two are very different , you should have lots of things to talk about .</tokentext>
<sentencetext>Doesn't modular programming solve this problem?Theory, I'd like to introduce you to practice.
You two are very different, you should have lots of things to talk about.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128578</id>
	<title>"not as glamorous as fresh, raw coding"</title>
	<author>Black-Man</author>
	<datestamp>1258471920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And that is the problem. Everyone thinks the glamour is the new code... which they invariably *screw* up and expect someone else to come in and fix those "details". Developers/Architects suffer from ADD.</p></htmltext>
<tokenext>And that is the problem .
Everyone thinks the glamour is the new code... which they invariably * screw * up and expect someone else to come in and fix those " details " .
Developers/Architects suffer from ADD .</tokentext>
<sentencetext>And that is the problem.
Everyone thinks the glamour is the new code... which they invariably *screw* up and expect someone else to come in and fix those "details".
Developers/Architects suffer from ADD.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125306</id>
	<title>Re:Important forgotten steps</title>
	<author>antgiant</author>
	<datestamp>1258387440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Am I the only one who can't help but read this post to the tune of the Twelve Days of Christmas?</htmltext>
<tokenext>Am I the only one who ca n't help but read this post to the tune of the Twelve Days of Christmas ?</tokentext>
<sentencetext>Am I the only one who can't help but read this post to the tune of the Twelve Days of Christmas?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126954</id>
	<title>Re:That is not maintenance.</title>
	<author>deoxyribonucleose</author>
	<datestamp>1258450920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p> <i>Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.</i> </p><p>Yes it is.</p><p>But that is not maintenance, as practiced by any rational company.  That is development or (more specifically) optimization.</p><p>Maintenance is about solving a problem code is having, with the absolute smallest number of changes possible.  Even new features can fall under this heading when software is in true "maintenance mode" in order to avoid a lot of excess testing.</p><p>I actually don't mind it, as it is a different sort of challenge to take a code base you know little about and introduce a working change with as little code as possible.   But it's not as glamorous as fresh, raw coding.</p></div><p>Software maintenance tasks fall into one of four categories:
</p><ol>
<li>Corrective maintenance fixes bugs in the maintenance object.</li><li>Preventive maintenance fixes bugs which have not yet been reported (including e.g. problems that would hinder application scaling).</li><li>Adaptive maintenance works around bugs in external objects (the O/S, the DBMS, integrated apps, whatnot).</li><li>Perfective maintenance makes the application easier to maintain in the future. </li></ol><p>
Perfective maintenance is what the grandparent post is talking about. A rational company balances these four kinds of maintenance against the expected future lifetime and current value of the software investment. Now, most software owning organizations are less than rational, but that's a different problem!
</p></div>
	</htmltext>
<tokenext>Taking code and cutting its size by half , fixing up all the screwed-up inconsistent formatting , while adding functionality and reducing bug counts , is a pleasure .
Yes it is.But that is not maintenance , as practiced by any rational company .
That is development or ( more specifically ) optimization.Maintenance is about solving a problem code is having , with the absolute smallest number of changes possible .
Even new features can fall under this heading when software is in true " maintenance mode " in order to avoid a lot of excess testing.I actually do n't mind it , as it is a different sort of challenge to take a code base you know little about and introduce a working change with as little code as possible .
But it 's not as glamorous as fresh , raw coding.Software maintenance tasks fall into one of four categories : Corrective maintenance fixes bugs in the maintenance object.Preventive maintenance fixes bugs which have not yet been reported ( including e.g .
problems that would hinder application scaling ) .Adaptive maintenance works around bugs in external objects ( the O/S , the DBMS , integrated apps , whatnot ) .Perfective maintenance makes the application easier to maintain in the future .
Perfective maintenance is what the grandparent post is talking about .
A rational company balances these four kinds of maintenance against the expected future lifetime and current value of the software investment .
Now , most software owning organizations are less than rational , but that 's a different problem !</tokentext>
<sentencetext> Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.
Yes it is.But that is not maintenance, as practiced by any rational company.
That is development or (more specifically) optimization.Maintenance is about solving a problem code is having, with the absolute smallest number of changes possible.
Even new features can fall under this heading when software is in true "maintenance mode" in order to avoid a lot of excess testing.I actually don't mind it, as it is a different sort of challenge to take a code base you know little about and introduce a working change with as little code as possible.
But it's not as glamorous as fresh, raw coding.Software maintenance tasks fall into one of four categories:

Corrective maintenance fixes bugs in the maintenance object.Preventive maintenance fixes bugs which have not yet been reported (including e.g.
problems that would hinder application scaling).Adaptive maintenance works around bugs in external objects (the O/S, the DBMS, integrated apps, whatnot).Perfective maintenance makes the application easier to maintain in the future.
Perfective maintenance is what the grandparent post is talking about.
A rational company balances these four kinds of maintenance against the expected future lifetime and current value of the software investment.
Now, most software owning organizations are less than rational, but that's a different problem!

	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128554</id>
	<title>Re:That is not maintenance.</title>
	<author>Cro Magnon</author>
	<datestamp>1258471740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>When I was doing maintenance, I did "evolution not revolution".  My main focus was usually fixing a specific problem, but I had no qualms about cleaning up some of the crap while I did so.  Obviously, I didn't have time to make significant improvements at one time, but if I was working on the program long enough, a tweak here and there would eventually add up to noticable improvements.</p></htmltext>
<tokenext>When I was doing maintenance , I did " evolution not revolution " .
My main focus was usually fixing a specific problem , but I had no qualms about cleaning up some of the crap while I did so .
Obviously , I did n't have time to make significant improvements at one time , but if I was working on the program long enough , a tweak here and there would eventually add up to noticable improvements .</tokentext>
<sentencetext>When I was doing maintenance, I did "evolution not revolution".
My main focus was usually fixing a specific problem, but I had no qualms about cleaning up some of the crap while I did so.
Obviously, I didn't have time to make significant improvements at one time, but if I was working on the program long enough, a tweak here and there would eventually add up to noticable improvements.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125418</id>
	<title>Re:Grrr</title>
	<author>Brian Gordon</author>
	<datestamp>1258388580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Development methodologies have nothing to do with computer science either.</p></htmltext>
<tokenext>Development methodologies have nothing to do with computer science either .</tokentext>
<sentencetext>Development methodologies have nothing to do with computer science either.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125060</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126334</id>
	<title>No such thing as a free lunch</title>
	<author>Balial</author>
	<datestamp>1258399020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This guy seems a little *too* optimistic about his solution. It's a great solution, and if you want to see a good example of its use, check out the <a href="http://en.wikipedia.org/wiki/K42" title="wikipedia.org" rel="nofollow">K42</a> [wikipedia.org] operating system. It solves a bunch of the performance problems a naive implementation as the article describes would have.
<br>
However, it's not a free lunch. Runtime marshalling and switching between interfaces? Does the author have any idea how hard that is? One tiny mistake and your entire database is full of junk data because you forgot that bit-X means Y, or your regex P had a typo. if you're going to adopt this "Continuous Change" model, you need to do an awful lot of validation testing on all the possible inputs from all the different API versions, and make <b>absolutely</b> sure you get the internal state you intended. Another way to say this, a hidden feature of the discrete approach is that you know the state of your system at all points in time. You're not running a franken-process.
<br>
BTW, I'm not trying to dump on the idea, I reckon it's cool, just the article doesn't really represent it accurately.</htmltext>
<tokenext>This guy seems a little * too * optimistic about his solution .
It 's a great solution , and if you want to see a good example of its use , check out the K42 [ wikipedia.org ] operating system .
It solves a bunch of the performance problems a naive implementation as the article describes would have .
However , it 's not a free lunch .
Runtime marshalling and switching between interfaces ?
Does the author have any idea how hard that is ?
One tiny mistake and your entire database is full of junk data because you forgot that bit-X means Y , or your regex P had a typo .
if you 're going to adopt this " Continuous Change " model , you need to do an awful lot of validation testing on all the possible inputs from all the different API versions , and make absolutely sure you get the internal state you intended .
Another way to say this , a hidden feature of the discrete approach is that you know the state of your system at all points in time .
You 're not running a franken-process .
BTW , I 'm not trying to dump on the idea , I reckon it 's cool , just the article does n't really represent it accurately .</tokentext>
<sentencetext>This guy seems a little *too* optimistic about his solution.
It's a great solution, and if you want to see a good example of its use, check out the K42 [wikipedia.org] operating system.
It solves a bunch of the performance problems a naive implementation as the article describes would have.
However, it's not a free lunch.
Runtime marshalling and switching between interfaces?
Does the author have any idea how hard that is?
One tiny mistake and your entire database is full of junk data because you forgot that bit-X means Y, or your regex P had a typo.
if you're going to adopt this "Continuous Change" model, you need to do an awful lot of validation testing on all the possible inputs from all the different API versions, and make absolutely sure you get the internal state you intended.
Another way to say this, a hidden feature of the discrete approach is that you know the state of your system at all points in time.
You're not running a franken-process.
BTW, I'm not trying to dump on the idea, I reckon it's cool, just the article doesn't really represent it accurately.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127976</id>
	<title>Maintenence is a bad word for it</title>
	<author>plopez</author>
	<datestamp>1258467420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It should be referred to as "software extension and fixes". Or something else, but not "maintenance".</p><p>Many managers have been trained to defer maintenance in production environments as a way to cut costs. Which may be true if the equipment costs are low enough. If the labor + parts + other materials are all more expensive than replacement costs and downtime for broken equipment is cheaper than replacement costs, so what?</p><p>This creates a dangerous attitude. Too often downtime costs are not computed. It is also dangerouse when this attitude is transferred to software, which is *not* an industrial process. Many managers do not seem to understand you can not manage software development like an industrial process.</p></htmltext>
<tokenext>It should be referred to as " software extension and fixes " .
Or something else , but not " maintenance " .Many managers have been trained to defer maintenance in production environments as a way to cut costs .
Which may be true if the equipment costs are low enough .
If the labor + parts + other materials are all more expensive than replacement costs and downtime for broken equipment is cheaper than replacement costs , so what ? This creates a dangerous attitude .
Too often downtime costs are not computed .
It is also dangerouse when this attitude is transferred to software , which is * not * an industrial process .
Many managers do not seem to understand you can not manage software development like an industrial process .</tokentext>
<sentencetext>It should be referred to as "software extension and fixes".
Or something else, but not "maintenance".Many managers have been trained to defer maintenance in production environments as a way to cut costs.
Which may be true if the equipment costs are low enough.
If the labor + parts + other materials are all more expensive than replacement costs and downtime for broken equipment is cheaper than replacement costs, so what?This creates a dangerous attitude.
Too often downtime costs are not computed.
It is also dangerouse when this attitude is transferred to software, which is *not* an industrial process.
Many managers do not seem to understand you can not manage software development like an industrial process.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408</id>
	<title>Different Kinds of Companies</title>
	<author>digsbo</author>
	<datestamp>1258388520000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>Decades ago, companies which developed technology were...technology companies.  With real engineers, and highly technically skilled management.  Today, companies with business-oriented management and zero technology background own and develop systems.  They often do it poorly, with insufficiently empowered engineering teams, and insufficiently skilled engineers.</p><p>So today we've got a lot of Java and<nobr> <wbr></nobr>.Net shops filled with junior-level programmers and no disciplined, experienced systems engineers.  Is it a surprise that when MS brought programming to the masses that the masses failed to learn engineering?</p></htmltext>
<tokenext>Decades ago , companies which developed technology were...technology companies .
With real engineers , and highly technically skilled management .
Today , companies with business-oriented management and zero technology background own and develop systems .
They often do it poorly , with insufficiently empowered engineering teams , and insufficiently skilled engineers.So today we 've got a lot of Java and .Net shops filled with junior-level programmers and no disciplined , experienced systems engineers .
Is it a surprise that when MS brought programming to the masses that the masses failed to learn engineering ?</tokentext>
<sentencetext>Decades ago, companies which developed technology were...technology companies.
With real engineers, and highly technically skilled management.
Today, companies with business-oriented management and zero technology background own and develop systems.
They often do it poorly, with insufficiently empowered engineering teams, and insufficiently skilled engineers.So today we've got a lot of Java and .Net shops filled with junior-level programmers and no disciplined, experienced systems engineers.
Is it a surprise that when MS brought programming to the masses that the masses failed to learn engineering?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990</id>
	<title>"Everyone knows maintenance is boring"</title>
	<author>Anonymous</author>
	<datestamp>1258384440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>FTFA:<blockquote><div><p>Everyone knows maintenance is difficult and boring, and therefore avoids doing it</p></div>
</blockquote><p>
Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.
</p><p>
It's all in the mindset.  It's only boring if you limit yourself to the boring parts.</p></div>
	</htmltext>
<tokenext>FTFA : Everyone knows maintenance is difficult and boring , and therefore avoids doing it Taking code and cutting its size by half , fixing up all the screwed-up inconsistent formatting , while adding functionality and reducing bug counts , is a pleasure .
It 's all in the mindset .
It 's only boring if you limit yourself to the boring parts .</tokentext>
<sentencetext>FTFA:Everyone knows maintenance is difficult and boring, and therefore avoids doing it

Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.
It's all in the mindset.
It's only boring if you limit yourself to the boring parts.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127452</id>
	<title>Re:Grrr</title>
	<author>Fred\_A</author>
	<datestamp>1258459260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Computer science work gets done at universities and research institutions, not at Initech.</p></div><p>That's because computer science isn't good for the company.</p></div>
	</htmltext>
<tokenext>Computer science work gets done at universities and research institutions , not at Initech.That 's because computer science is n't good for the company .</tokentext>
<sentencetext>Computer science work gets done at universities and research institutions, not at Initech.That's because computer science isn't good for the company.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128314</id>
	<title>Re:"Everyone knows maintenance is boring"</title>
	<author>Anonymous</author>
	<datestamp>1258470360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>While not breaking anything in a 20M SLOC program.</p><p>I worked on guidance, navigation and control software maintenance. If I messed up and the 7 levels of testing after me didn't catch the issue, people could die. Further a multi-BILLION $$$ vehicle could be lost with cargo worth hundreds of millions of dollars.</p><p>In 7 years, I introduced 2 errors.  When I left, the entire 11 person team had 1/2 errors per year error rate. One of the errors was specifically questioned by me and considered by a team of 15 people for 3 weeks before we decided to do nothing about it. How did such a low error rate happen?  Process, checklists for checklists, formal reviews and a little skill. We had 1 computer scientist in the team. The rest of us were engineering and math majors.  I think CS people don't like rules or process.</p><p>For example, we couldn't reformat source code. Every line touched had to be touched for a valid new requirement. The compiler output nicely formatted code, so the source format wasn't important. Our initials were tagged to every LOC that was touched. Talk about personal responsibility.</p><p>An error was defined as "not meeting the intent of the requirements."  Performing a calculation 1 pass late was considered a major error in this real-time system.  The highest priority code ran at 25Hz, so 1/25th of a second late was an error.</p><p>OTOH, we were very expensive.  My code is still flying.  Watch the EXTREMELY smooth shuttle landing in 11 days.</p></htmltext>
<tokenext>While not breaking anything in a 20M SLOC program.I worked on guidance , navigation and control software maintenance .
If I messed up and the 7 levels of testing after me did n't catch the issue , people could die .
Further a multi-BILLION $ $ $ vehicle could be lost with cargo worth hundreds of millions of dollars.In 7 years , I introduced 2 errors .
When I left , the entire 11 person team had 1/2 errors per year error rate .
One of the errors was specifically questioned by me and considered by a team of 15 people for 3 weeks before we decided to do nothing about it .
How did such a low error rate happen ?
Process , checklists for checklists , formal reviews and a little skill .
We had 1 computer scientist in the team .
The rest of us were engineering and math majors .
I think CS people do n't like rules or process.For example , we could n't reformat source code .
Every line touched had to be touched for a valid new requirement .
The compiler output nicely formatted code , so the source format was n't important .
Our initials were tagged to every LOC that was touched .
Talk about personal responsibility.An error was defined as " not meeting the intent of the requirements .
" Performing a calculation 1 pass late was considered a major error in this real-time system .
The highest priority code ran at 25Hz , so 1/25th of a second late was an error.OTOH , we were very expensive .
My code is still flying .
Watch the EXTREMELY smooth shuttle landing in 11 days .</tokentext>
<sentencetext>While not breaking anything in a 20M SLOC program.I worked on guidance, navigation and control software maintenance.
If I messed up and the 7 levels of testing after me didn't catch the issue, people could die.
Further a multi-BILLION $$$ vehicle could be lost with cargo worth hundreds of millions of dollars.In 7 years, I introduced 2 errors.
When I left, the entire 11 person team had 1/2 errors per year error rate.
One of the errors was specifically questioned by me and considered by a team of 15 people for 3 weeks before we decided to do nothing about it.
How did such a low error rate happen?
Process, checklists for checklists, formal reviews and a little skill.
We had 1 computer scientist in the team.
The rest of us were engineering and math majors.
I think CS people don't like rules or process.For example, we couldn't reformat source code.
Every line touched had to be touched for a valid new requirement.
The compiler output nicely formatted code, so the source format wasn't important.
Our initials were tagged to every LOC that was touched.
Talk about personal responsibility.An error was defined as "not meeting the intent of the requirements.
"  Performing a calculation 1 pass late was considered a major error in this real-time system.
The highest priority code ran at 25Hz, so 1/25th of a second late was an error.OTOH, we were very expensive.
My code is still flying.
Watch the EXTREMELY smooth shuttle landing in 11 days.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252</id>
	<title>Re:Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258386960000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>1</modscore>
	<htmltext><p>I beg to differ, in my computer science classes at the University of Missouri Rolla, they taught us software maintenance to go along with our programming classes. It is for more than just business software or application software it can be used for system software as well as operating systems, firmware, database applications, and everything else except the kitchen sink (but we are working on that one, he heh heh:).</p><p>If you don't do maintenance for your software, it is a lot like not doing maintenance for your car, eventually you'll run into trouble and then it will be more costly to repair (how much is a day or two of downtime worth to your firm?) than it would have been to do the maintenance of your software.</p><p>They don't teach software maintenance, debugging, documentation, legacy systems and legacy software, best practices, etc in computer science classes anymore, or the professors just skip over them or the students don't pay close attention anymore. Because I've worked with Comp Sci graduates that had no idea how to do any of them, and it was always up to be to debug their program and do software maintenance on them. Because I solved many problems that everyone else said couldn't be done, I kept getting promotions. But the work got really hard and I got stressed out and got sick and eventually got fired. It seemed out of a team of 30 developers, I was the only one able to fix the problems and avoid the system and servers crashing 12 times a day or more due to sloppy programming. But they fired me anyway for getting too sick at work, and keep on the sloppy programmers. I read the Microsoft Newsgroups they use for support and read by searching my former employer's domain name on how they struggled to migrate to Dotnet and couldn't get the Dotnet versions of the programs working as well as the ones I fixed and maintained. How could I, the only competent developer they had, been fired when they needed me for the Dotnet migration? It is simple, managers and developers don't want to do things like software maintenance or even debugging or best practices because they consider them "time wasters" and "unneeded expenses" and that the work I did cost them an expense they didn't need, so they didn't need me. But they were so blind to see that the work I did while it was an expense, it saved then millions of dollars in lost productivity, lost CPU time, cost savings in not needing to buy faster processors and more memory as my code ran tight and compact in lower ones, and days if not weeks of downtime and a dysfunctional system and software that takes them years to fix by hiring high priced contractors to do the work I would have done for my small salary.</p><p>Yes I am convinced that if I am well enough to return to work, to become that high priced consultant and do debugging, best practices, software maintenance, etc because 99.9\% of the market doesn't know how or doesn't want to do those things.</p><p>Before they let me go the VP of IT told me this "You are a developer, developers are a dime a dozen. We get 500 resumes a week just for your position alone. We can easily hire someone at a fraction of your current salary who won't get sick on the job." After they let me go they realized that I wasn't some dime a dozen programmer, but too late, can't change the past. If they want me back, I'll be a high priced contractor with an iron clad contract that contains bonuses, stock options, and other things in it.</p></htmltext>
<tokenext>I beg to differ , in my computer science classes at the University of Missouri Rolla , they taught us software maintenance to go along with our programming classes .
It is for more than just business software or application software it can be used for system software as well as operating systems , firmware , database applications , and everything else except the kitchen sink ( but we are working on that one , he heh heh : ) .If you do n't do maintenance for your software , it is a lot like not doing maintenance for your car , eventually you 'll run into trouble and then it will be more costly to repair ( how much is a day or two of downtime worth to your firm ?
) than it would have been to do the maintenance of your software.They do n't teach software maintenance , debugging , documentation , legacy systems and legacy software , best practices , etc in computer science classes anymore , or the professors just skip over them or the students do n't pay close attention anymore .
Because I 've worked with Comp Sci graduates that had no idea how to do any of them , and it was always up to be to debug their program and do software maintenance on them .
Because I solved many problems that everyone else said could n't be done , I kept getting promotions .
But the work got really hard and I got stressed out and got sick and eventually got fired .
It seemed out of a team of 30 developers , I was the only one able to fix the problems and avoid the system and servers crashing 12 times a day or more due to sloppy programming .
But they fired me anyway for getting too sick at work , and keep on the sloppy programmers .
I read the Microsoft Newsgroups they use for support and read by searching my former employer 's domain name on how they struggled to migrate to Dotnet and could n't get the Dotnet versions of the programs working as well as the ones I fixed and maintained .
How could I , the only competent developer they had , been fired when they needed me for the Dotnet migration ?
It is simple , managers and developers do n't want to do things like software maintenance or even debugging or best practices because they consider them " time wasters " and " unneeded expenses " and that the work I did cost them an expense they did n't need , so they did n't need me .
But they were so blind to see that the work I did while it was an expense , it saved then millions of dollars in lost productivity , lost CPU time , cost savings in not needing to buy faster processors and more memory as my code ran tight and compact in lower ones , and days if not weeks of downtime and a dysfunctional system and software that takes them years to fix by hiring high priced contractors to do the work I would have done for my small salary.Yes I am convinced that if I am well enough to return to work , to become that high priced consultant and do debugging , best practices , software maintenance , etc because 99.9 \ % of the market does n't know how or does n't want to do those things.Before they let me go the VP of IT told me this " You are a developer , developers are a dime a dozen .
We get 500 resumes a week just for your position alone .
We can easily hire someone at a fraction of your current salary who wo n't get sick on the job .
" After they let me go they realized that I was n't some dime a dozen programmer , but too late , ca n't change the past .
If they want me back , I 'll be a high priced contractor with an iron clad contract that contains bonuses , stock options , and other things in it .</tokentext>
<sentencetext>I beg to differ, in my computer science classes at the University of Missouri Rolla, they taught us software maintenance to go along with our programming classes.
It is for more than just business software or application software it can be used for system software as well as operating systems, firmware, database applications, and everything else except the kitchen sink (but we are working on that one, he heh heh:).If you don't do maintenance for your software, it is a lot like not doing maintenance for your car, eventually you'll run into trouble and then it will be more costly to repair (how much is a day or two of downtime worth to your firm?
) than it would have been to do the maintenance of your software.They don't teach software maintenance, debugging, documentation, legacy systems and legacy software, best practices, etc in computer science classes anymore, or the professors just skip over them or the students don't pay close attention anymore.
Because I've worked with Comp Sci graduates that had no idea how to do any of them, and it was always up to be to debug their program and do software maintenance on them.
Because I solved many problems that everyone else said couldn't be done, I kept getting promotions.
But the work got really hard and I got stressed out and got sick and eventually got fired.
It seemed out of a team of 30 developers, I was the only one able to fix the problems and avoid the system and servers crashing 12 times a day or more due to sloppy programming.
But they fired me anyway for getting too sick at work, and keep on the sloppy programmers.
I read the Microsoft Newsgroups they use for support and read by searching my former employer's domain name on how they struggled to migrate to Dotnet and couldn't get the Dotnet versions of the programs working as well as the ones I fixed and maintained.
How could I, the only competent developer they had, been fired when they needed me for the Dotnet migration?
It is simple, managers and developers don't want to do things like software maintenance or even debugging or best practices because they consider them "time wasters" and "unneeded expenses" and that the work I did cost them an expense they didn't need, so they didn't need me.
But they were so blind to see that the work I did while it was an expense, it saved then millions of dollars in lost productivity, lost CPU time, cost savings in not needing to buy faster processors and more memory as my code ran tight and compact in lower ones, and days if not weeks of downtime and a dysfunctional system and software that takes them years to fix by hiring high priced contractors to do the work I would have done for my small salary.Yes I am convinced that if I am well enough to return to work, to become that high priced consultant and do debugging, best practices, software maintenance, etc because 99.9\% of the market doesn't know how or doesn't want to do those things.Before they let me go the VP of IT told me this "You are a developer, developers are a dime a dozen.
We get 500 resumes a week just for your position alone.
We can easily hire someone at a fraction of your current salary who won't get sick on the job.
" After they let me go they realized that I wasn't some dime a dozen programmer, but too late, can't change the past.
If they want me back, I'll be a high priced contractor with an iron clad contract that contains bonuses, stock options, and other things in it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127500</id>
	<title>Typical modern CACM article</title>
	<author>Chalst</author>
	<datestamp>1258460100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Long, wordy, buzz-word heavy article with a little bit of interesting content buried deep inside.  I wish I hadn't bothered to read it.</p><p>In case you haven't, but are thinking you might: you can run machines that are never down, even when software is being updated, if you use a few tricks.  I knew most of the one's they mentioned already, and use them on my company website, which is far from downtime-proof, but has a 3-year uptime so far: call my software maintenence status "fairly sturdy".</p><p>If you're interested in upgrading to software maintenance status "bulletproof", then read something about fault-tolerant computing in Erlang.  You'll learn more that way.</p></htmltext>
<tokenext>Long , wordy , buzz-word heavy article with a little bit of interesting content buried deep inside .
I wish I had n't bothered to read it.In case you have n't , but are thinking you might : you can run machines that are never down , even when software is being updated , if you use a few tricks .
I knew most of the one 's they mentioned already , and use them on my company website , which is far from downtime-proof , but has a 3-year uptime so far : call my software maintenence status " fairly sturdy " .If you 're interested in upgrading to software maintenance status " bulletproof " , then read something about fault-tolerant computing in Erlang .
You 'll learn more that way .</tokentext>
<sentencetext>Long, wordy, buzz-word heavy article with a little bit of interesting content buried deep inside.
I wish I hadn't bothered to read it.In case you haven't, but are thinking you might: you can run machines that are never down, even when software is being updated, if you use a few tricks.
I knew most of the one's they mentioned already, and use them on my company website, which is far from downtime-proof, but has a 3-year uptime so far: call my software maintenence status "fairly sturdy".If you're interested in upgrading to software maintenance status "bulletproof", then read something about fault-tolerant computing in Erlang.
You'll learn more that way.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614</id>
	<title>Re:That's mighty elitist of you</title>
	<author>Anonymous</author>
	<datestamp>1258390920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A Turing machine cannot solve the problem of software maintenance.  You cannot model software maintenance as a finite state machine.  There is no algorithmic solution.  There is no space-time trade-off that you can make improve the situation.</p><p>It is not a problem to be solved by computing.  It is outside the realm of Computer Science, and clearly in the lap of Software Engineering.</p></htmltext>
<tokenext>A Turing machine can not solve the problem of software maintenance .
You can not model software maintenance as a finite state machine .
There is no algorithmic solution .
There is no space-time trade-off that you can make improve the situation.It is not a problem to be solved by computing .
It is outside the realm of Computer Science , and clearly in the lap of Software Engineering .</tokentext>
<sentencetext>A Turing machine cannot solve the problem of software maintenance.
You cannot model software maintenance as a finite state machine.
There is no algorithmic solution.
There is no space-time trade-off that you can make improve the situation.It is not a problem to be solved by computing.
It is outside the realm of Computer Science, and clearly in the lap of Software Engineering.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125202</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30143874</id>
	<title>Synopsis</title>
	<author>Anonymous</author>
	<datestamp>1257092400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Utilize the power of version numbering your structures".<br>It's a cool suggestion, but I wonder if it was worth reading the whole article... perhaps it pays of in the future...</p></htmltext>
<tokenext>" Utilize the power of version numbering your structures " .It 's a cool suggestion , but I wonder if it was worth reading the whole article... perhaps it pays of in the future.. .</tokentext>
<sentencetext>"Utilize the power of version numbering your structures".It's a cool suggestion, but I wonder if it was worth reading the whole article... perhaps it pays of in the future...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125970</id>
	<title>Re:Different Kinds of Companies</title>
	<author>Opportunist</author>
	<datestamp>1258394580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>No, but whether MS started that earlier. It would not have mattered a bit whether MS brought programming to the masses. Someone would have. Actually, Borland was way ahead of MS with C-Builder and Delphi when it comes to easily accessible RAD tools.</p><p>The core problem is that the need for more software was there, when the amount of good programmers remained more or less stable, or at the very least didn't explode at the same rate as the demand. Think back 25 years, to the time before RAD tools, and notice how you had a lot less computerized work places and much more standardisation. IBM one-size-fits-all mainframes were still the norm, with a few PCs starting to poke their heads up, and even those were usually running a handful of different programs, tops. Often you had a machine dediated to a single task, and not really that many programs to choose from. Companies bought a system, paid insane sums and ran it 'til system and machine croaked, often for a decade or even longer. Hell, I know of a few systems that still run on DOS 3.3 and do the same job they did a quarter century ago.</p><p>Today, everyone wants a custom job, additionally we have a LOT more demand and a LOT more companies relying on computers and computer programs, and thus the demand for programs soared. The supply of good programmers didn't keep up, so we have to throw worse programmers into the game. And these people need RADs, for them RADs don't just make the work easier, they make it possible. That this results in inferior programs, because the people using those RADs don't even remotely understand what those RADs do for them, is a given. Blaming MS for it isn't. The demand would be there, so someone would have supplied the solution.</p></htmltext>
<tokenext>No , but whether MS started that earlier .
It would not have mattered a bit whether MS brought programming to the masses .
Someone would have .
Actually , Borland was way ahead of MS with C-Builder and Delphi when it comes to easily accessible RAD tools.The core problem is that the need for more software was there , when the amount of good programmers remained more or less stable , or at the very least did n't explode at the same rate as the demand .
Think back 25 years , to the time before RAD tools , and notice how you had a lot less computerized work places and much more standardisation .
IBM one-size-fits-all mainframes were still the norm , with a few PCs starting to poke their heads up , and even those were usually running a handful of different programs , tops .
Often you had a machine dediated to a single task , and not really that many programs to choose from .
Companies bought a system , paid insane sums and ran it 'til system and machine croaked , often for a decade or even longer .
Hell , I know of a few systems that still run on DOS 3.3 and do the same job they did a quarter century ago.Today , everyone wants a custom job , additionally we have a LOT more demand and a LOT more companies relying on computers and computer programs , and thus the demand for programs soared .
The supply of good programmers did n't keep up , so we have to throw worse programmers into the game .
And these people need RADs , for them RADs do n't just make the work easier , they make it possible .
That this results in inferior programs , because the people using those RADs do n't even remotely understand what those RADs do for them , is a given .
Blaming MS for it is n't .
The demand would be there , so someone would have supplied the solution .</tokentext>
<sentencetext>No, but whether MS started that earlier.
It would not have mattered a bit whether MS brought programming to the masses.
Someone would have.
Actually, Borland was way ahead of MS with C-Builder and Delphi when it comes to easily accessible RAD tools.The core problem is that the need for more software was there, when the amount of good programmers remained more or less stable, or at the very least didn't explode at the same rate as the demand.
Think back 25 years, to the time before RAD tools, and notice how you had a lot less computerized work places and much more standardisation.
IBM one-size-fits-all mainframes were still the norm, with a few PCs starting to poke their heads up, and even those were usually running a handful of different programs, tops.
Often you had a machine dediated to a single task, and not really that many programs to choose from.
Companies bought a system, paid insane sums and ran it 'til system and machine croaked, often for a decade or even longer.
Hell, I know of a few systems that still run on DOS 3.3 and do the same job they did a quarter century ago.Today, everyone wants a custom job, additionally we have a LOT more demand and a LOT more companies relying on computers and computer programs, and thus the demand for programs soared.
The supply of good programmers didn't keep up, so we have to throw worse programmers into the game.
And these people need RADs, for them RADs don't just make the work easier, they make it possible.
That this results in inferior programs, because the people using those RADs don't even remotely understand what those RADs do for them, is a given.
Blaming MS for it isn't.
The demand would be there, so someone would have supplied the solution.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30133996</id>
	<title>Re:Delete the word 'software' from TFA title</title>
	<author>Dragoness Eclectic</author>
	<datestamp>1258449600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Never been in the military, have you?  In the Navy, Preventative Maintenance (PM) is a big part of your duties as an enlisted sailor. I imagine it's the same for the Army, Air Force and Marines.</p></htmltext>
<tokenext>Never been in the military , have you ?
In the Navy , Preventative Maintenance ( PM ) is a big part of your duties as an enlisted sailor .
I imagine it 's the same for the Army , Air Force and Marines .</tokentext>
<sentencetext>Never been in the military, have you?
In the Navy, Preventative Maintenance (PM) is a big part of your duties as an enlisted sailor.
I imagine it's the same for the Army, Air Force and Marines.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125532</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980</id>
	<title>Wait a second...</title>
	<author>Anonymous</author>
	<datestamp>1258384380000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext>Doesn't modular programming solve this problem? If you design the core software correctly from the get-go to be truly modular, then any changes in the future are a matter of swapping in or out desired modules, and snapping on new ones?
<br> <br>
Maybe I'm too naive, but is there REALLY that much spaghetti code these days?</htmltext>
<tokenext>Does n't modular programming solve this problem ?
If you design the core software correctly from the get-go to be truly modular , then any changes in the future are a matter of swapping in or out desired modules , and snapping on new ones ?
Maybe I 'm too naive , but is there REALLY that much spaghetti code these days ?</tokentext>
<sentencetext>Doesn't modular programming solve this problem?
If you design the core software correctly from the get-go to be truly modular, then any changes in the future are a matter of swapping in or out desired modules, and snapping on new ones?
Maybe I'm too naive, but is there REALLY that much spaghetti code these days?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125768</id>
	<title>Re:Important forgotten steps</title>
	<author>Anonymous</author>
	<datestamp>1258392780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Quiet, you're sharing our company's proprietary software engineering department procedures!</p></htmltext>
<tokenext>Quiet , you 're sharing our company 's proprietary software engineering department procedures !</tokentext>
<sentencetext>Quiet, you're sharing our company's proprietary software engineering department procedures!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232</id>
	<title>That is not maintenance.</title>
	<author>Anonymous</author>
	<datestamp>1258386720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p><i>Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.</i></p><p>Yes it is.</p><p>But that is not maintenance, as practiced by any rational company.  That is development or (more specifically) optimization.</p><p>Maintenance is about solving a problem code is having, with the absolute smallest number of changes possible.  Even new features can fall under this heading when software is in true "maintenance mode" in order to avoid a lot of excess testing.</p><p>I actually don't mind it, as it is a different sort of challenge to take a code base you know little about and introduce a working change with as little code as possible.   But it's not as glamorous as fresh, raw coding.</p></htmltext>
<tokenext>Taking code and cutting its size by half , fixing up all the screwed-up inconsistent formatting , while adding functionality and reducing bug counts , is a pleasure.Yes it is.But that is not maintenance , as practiced by any rational company .
That is development or ( more specifically ) optimization.Maintenance is about solving a problem code is having , with the absolute smallest number of changes possible .
Even new features can fall under this heading when software is in true " maintenance mode " in order to avoid a lot of excess testing.I actually do n't mind it , as it is a different sort of challenge to take a code base you know little about and introduce a working change with as little code as possible .
But it 's not as glamorous as fresh , raw coding .</tokentext>
<sentencetext>Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.Yes it is.But that is not maintenance, as practiced by any rational company.
That is development or (more specifically) optimization.Maintenance is about solving a problem code is having, with the absolute smallest number of changes possible.
Even new features can fall under this heading when software is in true "maintenance mode" in order to avoid a lot of excess testing.I actually don't mind it, as it is a different sort of challenge to take a code base you know little about and introduce a working change with as little code as possible.
But it's not as glamorous as fresh, raw coding.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126332</id>
	<title>we're just beginning to rediscover it."</title>
	<author>thoglette</author>
	<datestamp>1258399020000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><blockquote><div><p>"we're just beginning to rediscover it."</p></div></blockquote><p>
In this age of 20yo CEOs and single-quarter companies it's hardly suprising that most software is no better than a rigged demo.
</p><p>
Just make it shiny enough for someone to buy the company and then let their support staff of MS trained monkeys deal with it
</p><p>
Then we have the "artists" (in both the software and hardware field) who have survived for twenty years without "all that sh1t".  Course, like the CEO, they've  gone on to their next challenge long before the chickens come home to roost.   And it's not their fault everyone else is incompetent, is it?
</p><p>
I continue to be amazed, on a weekly basis, by the complete lack of experience shown by the actions and products of very large companies.
</p><p>
Oh, I reject the claim that</p><blockquote><div><p>Software maintenance is not like hardware maintenance, which is the return of the item to its original state. Software maintenance involves moving an item away from its original state.</p></div></blockquote><p>   The author has obviously never maintained hardware: it has bugs, patches, upgrades just like any other part of your system.
</p></div>
	</htmltext>
<tokenext>" we 're just beginning to rediscover it .
" In this age of 20yo CEOs and single-quarter companies it 's hardly suprising that most software is no better than a rigged demo .
Just make it shiny enough for someone to buy the company and then let their support staff of MS trained monkeys deal with it Then we have the " artists " ( in both the software and hardware field ) who have survived for twenty years without " all that sh1t " .
Course , like the CEO , they 've gone on to their next challenge long before the chickens come home to roost .
And it 's not their fault everyone else is incompetent , is it ?
I continue to be amazed , on a weekly basis , by the complete lack of experience shown by the actions and products of very large companies .
Oh , I reject the claim thatSoftware maintenance is not like hardware maintenance , which is the return of the item to its original state .
Software maintenance involves moving an item away from its original state .
The author has obviously never maintained hardware : it has bugs , patches , upgrades just like any other part of your system .</tokentext>
<sentencetext>"we're just beginning to rediscover it.
"
In this age of 20yo CEOs and single-quarter companies it's hardly suprising that most software is no better than a rigged demo.
Just make it shiny enough for someone to buy the company and then let their support staff of MS trained monkeys deal with it

Then we have the "artists" (in both the software and hardware field) who have survived for twenty years without "all that sh1t".
Course, like the CEO, they've  gone on to their next challenge long before the chickens come home to roost.
And it's not their fault everyone else is incompetent, is it?
I continue to be amazed, on a weekly basis, by the complete lack of experience shown by the actions and products of very large companies.
Oh, I reject the claim thatSoftware maintenance is not like hardware maintenance, which is the return of the item to its original state.
Software maintenance involves moving an item away from its original state.
The author has obviously never maintained hardware: it has bugs, patches, upgrades just like any other part of your system.

	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125498</id>
	<title>Re:Grrr</title>
	<author>phantomfive</author>
	<datestamp>1258389660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This article really doesn't have much to do with computer maintenance either.  It is trying to address software maintenance from the point of view of a software developer,  but it reads as though it were written by an academic who hasn't actually worked in the industry for years, and who is just trying to get credit for a publication.<br> <br>
It first categorizes different ways of maintaining software, with no real rationale for choosing those categories, then goes on to describe a versioning system that somehow makes everything easy.  They also throw in some nice 'hip' language like "Pointy Haired Boss (BHP)" and "You Don't Know Jack." <br> <br>
Now, they are right that versioning is a useful technique in software development, but it is no more than that, merely a technique. Software maintenance from a developer's perspective is a broad topic involving many techniques for coding flexibly, including design patterns, encapsulation, writing readable code, etc.  They have focused on one technique and present it as <b>the</b> solution to maintaining software.<br> <br>
It is as if I said, "Don't use global variables and your code will be perfect."  While it is reasonable advice, there's more to perfect code than using/not using global variables.</htmltext>
<tokenext>This article really does n't have much to do with computer maintenance either .
It is trying to address software maintenance from the point of view of a software developer , but it reads as though it were written by an academic who has n't actually worked in the industry for years , and who is just trying to get credit for a publication .
It first categorizes different ways of maintaining software , with no real rationale for choosing those categories , then goes on to describe a versioning system that somehow makes everything easy .
They also throw in some nice 'hip ' language like " Pointy Haired Boss ( BHP ) " and " You Do n't Know Jack .
" Now , they are right that versioning is a useful technique in software development , but it is no more than that , merely a technique .
Software maintenance from a developer 's perspective is a broad topic involving many techniques for coding flexibly , including design patterns , encapsulation , writing readable code , etc .
They have focused on one technique and present it as the solution to maintaining software .
It is as if I said , " Do n't use global variables and your code will be perfect .
" While it is reasonable advice , there 's more to perfect code than using/not using global variables .</tokentext>
<sentencetext>This article really doesn't have much to do with computer maintenance either.
It is trying to address software maintenance from the point of view of a software developer,  but it reads as though it were written by an academic who hasn't actually worked in the industry for years, and who is just trying to get credit for a publication.
It first categorizes different ways of maintaining software, with no real rationale for choosing those categories, then goes on to describe a versioning system that somehow makes everything easy.
They also throw in some nice 'hip' language like "Pointy Haired Boss (BHP)" and "You Don't Know Jack.
"  
Now, they are right that versioning is a useful technique in software development, but it is no more than that, merely a technique.
Software maintenance from a developer's perspective is a broad topic involving many techniques for coding flexibly, including design patterns, encapsulation, writing readable code, etc.
They have focused on one technique and present it as the solution to maintaining software.
It is as if I said, "Don't use global variables and your code will be perfect.
"  While it is reasonable advice, there's more to perfect code than using/not using global variables.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125406</id>
	<title>Premature Declaration of Victory</title>
	<author>Capt.Albatross</author>
	<datestamp>1258388520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The problem has a hard part, and another that is just tedious. The authors declare the latter is solved, but ignore the former.
<p>Given a working upgrade, rolling it out while keeping things running is 'just' a matter of careful preparation and attention to detail. Being able to understand the existing system so you can get to a working upgrade is often the hard part, and while modular programming might be part of the solution, doing it right is not so easy, judging by the frequency with which it is done poorly (the phrase 'modular programming' itself belongs with 'buy low, sell high' in terms of the completeness with which it specifies a solution to a problem.)</p></htmltext>
<tokenext>The problem has a hard part , and another that is just tedious .
The authors declare the latter is solved , but ignore the former .
Given a working upgrade , rolling it out while keeping things running is 'just ' a matter of careful preparation and attention to detail .
Being able to understand the existing system so you can get to a working upgrade is often the hard part , and while modular programming might be part of the solution , doing it right is not so easy , judging by the frequency with which it is done poorly ( the phrase 'modular programming ' itself belongs with 'buy low , sell high ' in terms of the completeness with which it specifies a solution to a problem .
)</tokentext>
<sentencetext>The problem has a hard part, and another that is just tedious.
The authors declare the latter is solved, but ignore the former.
Given a working upgrade, rolling it out while keeping things running is 'just' a matter of careful preparation and attention to detail.
Being able to understand the existing system so you can get to a working upgrade is often the hard part, and while modular programming might be part of the solution, doing it right is not so easy, judging by the frequency with which it is done poorly (the phrase 'modular programming' itself belongs with 'buy low, sell high' in terms of the completeness with which it specifies a solution to a problem.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30137184</id>
	<title>one small edit</title>
	<author>sohp</author>
	<datestamp>1258461540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>s/Maintenance/Development/</p><p>Oh sure, there are a handful who know something, but to a first approximation, the above is correct.</p></htmltext>
<tokenext>s/Maintenance/Development/Oh sure , there are a handful who know something , but to a first approximation , the above is correct .</tokentext>
<sentencetext>s/Maintenance/Development/Oh sure, there are a handful who know something, but to a first approximation, the above is correct.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125812</id>
	<title>Re:"Everyone knows maintenance is boring"</title>
	<author>shmlco</author>
	<datestamp>1258393080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"Maintenance isn't a rewrite from scratch to do the same thing, as much as we'd like it to be."</p><p>Meaning that you can't figure out how the previous developer did what he did, and if you rewrite it from scratch at least YOU will understand it.</p><p>Unfortunately, that doesn't help the next developer, who's now totally unable to read and parse your brilliant semi-logical code...</p><p>And wants to rewrite IT from scratch.</p></htmltext>
<tokenext>" Maintenance is n't a rewrite from scratch to do the same thing , as much as we 'd like it to be .
" Meaning that you ca n't figure out how the previous developer did what he did , and if you rewrite it from scratch at least YOU will understand it.Unfortunately , that does n't help the next developer , who 's now totally unable to read and parse your brilliant semi-logical code...And wants to rewrite IT from scratch .</tokentext>
<sentencetext>"Maintenance isn't a rewrite from scratch to do the same thing, as much as we'd like it to be.
"Meaning that you can't figure out how the previous developer did what he did, and if you rewrite it from scratch at least YOU will understand it.Unfortunately, that doesn't help the next developer, who's now totally unable to read and parse your brilliant semi-logical code...And wants to rewrite IT from scratch.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125288</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125288</id>
	<title>Re:"Everyone knows maintenance is boring"</title>
	<author>steelfood</author>
	<datestamp>1258387260000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>More likely, the code was written and documented badly in the first place, so it's not a matter of taking it and cutting it down into something more elegant. Instead, it's about trying to decipher exactly what's going on, then trying to figure out how to make it at least superficially better while trying to keep within the same crappy framework. This has to all be done within budget, or the work done will go to waste when the project's scrapped, and there won't be a budget for maintenance again.</p><p>Maintenance isn't a rewrite from scratch to do the same thing, as much as we'd like it to be. Production systems have to be kept up. Migration to new code has to be both backwards compatible and produce enough visible results to make it worthwhile. It can't be too big of a change, nor too little. It's hardly any wonder software developers don't get to, and managers don't want to do it.</p></htmltext>
<tokenext>More likely , the code was written and documented badly in the first place , so it 's not a matter of taking it and cutting it down into something more elegant .
Instead , it 's about trying to decipher exactly what 's going on , then trying to figure out how to make it at least superficially better while trying to keep within the same crappy framework .
This has to all be done within budget , or the work done will go to waste when the project 's scrapped , and there wo n't be a budget for maintenance again.Maintenance is n't a rewrite from scratch to do the same thing , as much as we 'd like it to be .
Production systems have to be kept up .
Migration to new code has to be both backwards compatible and produce enough visible results to make it worthwhile .
It ca n't be too big of a change , nor too little .
It 's hardly any wonder software developers do n't get to , and managers do n't want to do it .</tokentext>
<sentencetext>More likely, the code was written and documented badly in the first place, so it's not a matter of taking it and cutting it down into something more elegant.
Instead, it's about trying to decipher exactly what's going on, then trying to figure out how to make it at least superficially better while trying to keep within the same crappy framework.
This has to all be done within budget, or the work done will go to waste when the project's scrapped, and there won't be a budget for maintenance again.Maintenance isn't a rewrite from scratch to do the same thing, as much as we'd like it to be.
Production systems have to be kept up.
Migration to new code has to be both backwards compatible and produce enough visible results to make it worthwhile.
It can't be too big of a change, nor too little.
It's hardly any wonder software developers don't get to, and managers don't want to do it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125100</id>
	<title>Re:Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258385460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>BS. That's like saying that genetics occurs only in laboratories.</p></htmltext>
<tokenext>BS .
That 's like saying that genetics occurs only in laboratories .</tokentext>
<sentencetext>BS.
That's like saying that genetics occurs only in laboratories.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30146646</id>
	<title>It's about upgrade distribution, not repair.</title>
	<author>hendrikboom</author>
	<datestamp>1257103440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A useful article, but does not address the hard part of software maintenance.  It is about how to design software so that it is easy to distribute and install updates, not about how to track down the bugs and determine what those updates are.</htmltext>
<tokenext>A useful article , but does not address the hard part of software maintenance .
It is about how to design software so that it is easy to distribute and install updates , not about how to track down the bugs and determine what those updates are .</tokentext>
<sentencetext>A useful article, but does not address the hard part of software maintenance.
It is about how to design software so that it is easy to distribute and install updates, not about how to track down the bugs and determine what those updates are.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30136118</id>
	<title>Re:Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258457100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I would hate to work for someone like you.... Back in my day when men were men....</p><p>Please go back to your porch and yelling at kids to get off your lawn.</p><p>Computer Science degrees have nothing to do with teaching "legacy systems" and "legacy software". A CS degree shows that you understand the theoretical knowledge of computing. A CS degree is not intended to make people maintenance programmers or even good programmers. It is intended to make people Computer Scientists. You know those guys that think up nifty new ways on how to combat the problems that we currently have in the computer industry.</p></htmltext>
<tokenext>I would hate to work for someone like you.... Back in my day when men were men....Please go back to your porch and yelling at kids to get off your lawn.Computer Science degrees have nothing to do with teaching " legacy systems " and " legacy software " .
A CS degree shows that you understand the theoretical knowledge of computing .
A CS degree is not intended to make people maintenance programmers or even good programmers .
It is intended to make people Computer Scientists .
You know those guys that think up nifty new ways on how to combat the problems that we currently have in the computer industry .</tokentext>
<sentencetext>I would hate to work for someone like you.... Back in my day when men were men....Please go back to your porch and yelling at kids to get off your lawn.Computer Science degrees have nothing to do with teaching "legacy systems" and "legacy software".
A CS degree shows that you understand the theoretical knowledge of computing.
A CS degree is not intended to make people maintenance programmers or even good programmers.
It is intended to make people Computer Scientists.
You know those guys that think up nifty new ways on how to combat the problems that we currently have in the computer industry.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125766</id>
	<title>Re:That's mighty elitist of you</title>
	<author>SuperKendall</author>
	<datestamp>1258392780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>A Turing machine cannot solve the problem of software maintenance.</i></p><p>That is true but does not mean it's not a valid sub-field with equal importance.  The same kinds of issues exist in "real" engineering disciplines where a plan must go from conception to reality involving many different people.</p></htmltext>
<tokenext>A Turing machine can not solve the problem of software maintenance.That is true but does not mean it 's not a valid sub-field with equal importance .
The same kinds of issues exist in " real " engineering disciplines where a plan must go from conception to reality involving many different people .</tokentext>
<sentencetext>A Turing machine cannot solve the problem of software maintenance.That is true but does not mean it's not a valid sub-field with equal importance.
The same kinds of issues exist in "real" engineering disciplines where a plan must go from conception to reality involving many different people.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127506</id>
	<title>Re:six sigma</title>
	<author>Acer500</author>
	<datestamp>1258460160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p> Whenever someone fixes a bug that creates a new bug, then it's a waste of everyone time and effort.</p></div><p>Bah, you're doing it wrong. We used to say in my old work that every bug fix created TWO new bugs<nobr> <wbr></nobr>:) . That also ensured job stability<nobr> <wbr></nobr>:P .</p></div>
	</htmltext>
<tokenext>Whenever someone fixes a bug that creates a new bug , then it 's a waste of everyone time and effort.Bah , you 're doing it wrong .
We used to say in my old work that every bug fix created TWO new bugs : ) .
That also ensured job stability : P .</tokentext>
<sentencetext> Whenever someone fixes a bug that creates a new bug, then it's a waste of everyone time and effort.Bah, you're doing it wrong.
We used to say in my old work that every bug fix created TWO new bugs :) .
That also ensured job stability :P .
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125336</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125842</id>
	<title>Re:Wait a second...</title>
	<author>Opportunist</author>
	<datestamp>1258393380000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>No modular system survives version +0.1.</p><p>You have a perfectly modeled modular system, and you really think you thought of everything. Only to notice that someone comes up with some problem you didn't take into account. So what do you do? Redesign the whole modular system, unravel all the finished modules and rework them to fit the new interfaces you have to design? Nah, we can handle a single nonstandard data handoff...</p><p>Do I have to go on?</p></htmltext>
<tokenext>No modular system survives version + 0.1.You have a perfectly modeled modular system , and you really think you thought of everything .
Only to notice that someone comes up with some problem you did n't take into account .
So what do you do ?
Redesign the whole modular system , unravel all the finished modules and rework them to fit the new interfaces you have to design ?
Nah , we can handle a single nonstandard data handoff...Do I have to go on ?</tokentext>
<sentencetext>No modular system survives version +0.1.You have a perfectly modeled modular system, and you really think you thought of everything.
Only to notice that someone comes up with some problem you didn't take into account.
So what do you do?
Redesign the whole modular system, unravel all the finished modules and rework them to fit the new interfaces you have to design?
Nah, we can handle a single nonstandard data handoff...Do I have to go on?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30129894</id>
	<title>Re:Good luck</title>
	<author>RAMMS+EIN</author>
	<datestamp>1258477620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>``Security has become the number 1 reason that software is now a continuous version stream with patches rolling out every 6 minutes.''</p><p>Which is why I am such a fan of distributions that don't do feature updates. Keep everything the same, only sending out updates to fix bugs.</p><p>``The UNIX-like OSes of the world have always handled this concept more gracefully, but when you look at windows that wants to reboot 4 times a week for updates it seems much more like an afterthought.''</p><p>I am not so sure. I think Unix got lucky, in that it grew up in a world where computer security was much less of an issue than nowadays. By the time Internet worms and the like became widespread, Unix had had a long time to mature, and faded to the background enough that people had mostly forgotten about it (how many people know what HP-UX is anymore?)</p><p>So you don't see a lot of malware targeting Unix, because it isn't such a big target, because there are a plethora of different, non-binary compatible versions out there, and because most of the outdated versions are mostly out of use and forgotten, whereas the up to date versions are quite mature.</p><p>The big exception to this is popular software that is getting many features added to it rapidly, such as the Linux kernel, various popular desktop programs, and many, many web applications: these are both rife with bugs and often break compatibility on updates. On the other hand, they're still popular, because people want those features.</p><p>The beauty of the Unix universe is that you can have it your way. You can have a stable system with few bugs and little maintenance, or you can have a cutting edge system with the latest features, at the cost of more bugs and time spent on maintenance.</p></htmltext>
<tokenext>` ` Security has become the number 1 reason that software is now a continuous version stream with patches rolling out every 6 minutes .
''Which is why I am such a fan of distributions that do n't do feature updates .
Keep everything the same , only sending out updates to fix bugs. ` ` The UNIX-like OSes of the world have always handled this concept more gracefully , but when you look at windows that wants to reboot 4 times a week for updates it seems much more like an afterthought .
''I am not so sure .
I think Unix got lucky , in that it grew up in a world where computer security was much less of an issue than nowadays .
By the time Internet worms and the like became widespread , Unix had had a long time to mature , and faded to the background enough that people had mostly forgotten about it ( how many people know what HP-UX is anymore ?
) So you do n't see a lot of malware targeting Unix , because it is n't such a big target , because there are a plethora of different , non-binary compatible versions out there , and because most of the outdated versions are mostly out of use and forgotten , whereas the up to date versions are quite mature.The big exception to this is popular software that is getting many features added to it rapidly , such as the Linux kernel , various popular desktop programs , and many , many web applications : these are both rife with bugs and often break compatibility on updates .
On the other hand , they 're still popular , because people want those features.The beauty of the Unix universe is that you can have it your way .
You can have a stable system with few bugs and little maintenance , or you can have a cutting edge system with the latest features , at the cost of more bugs and time spent on maintenance .</tokentext>
<sentencetext>``Security has become the number 1 reason that software is now a continuous version stream with patches rolling out every 6 minutes.
''Which is why I am such a fan of distributions that don't do feature updates.
Keep everything the same, only sending out updates to fix bugs.``The UNIX-like OSes of the world have always handled this concept more gracefully, but when you look at windows that wants to reboot 4 times a week for updates it seems much more like an afterthought.
''I am not so sure.
I think Unix got lucky, in that it grew up in a world where computer security was much less of an issue than nowadays.
By the time Internet worms and the like became widespread, Unix had had a long time to mature, and faded to the background enough that people had mostly forgotten about it (how many people know what HP-UX is anymore?
)So you don't see a lot of malware targeting Unix, because it isn't such a big target, because there are a plethora of different, non-binary compatible versions out there, and because most of the outdated versions are mostly out of use and forgotten, whereas the up to date versions are quite mature.The big exception to this is popular software that is getting many features added to it rapidly, such as the Linux kernel, various popular desktop programs, and many, many web applications: these are both rife with bugs and often break compatibility on updates.
On the other hand, they're still popular, because people want those features.The beauty of the Unix universe is that you can have it your way.
You can have a stable system with few bugs and little maintenance, or you can have a cutting edge system with the latest features, at the cost of more bugs and time spent on maintenance.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125208</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125574</id>
	<title>Re:Grrr</title>
	<author>lennier</author>
	<datestamp>1258390380000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>""Software maintenance" has absolutely nothing to do with computer science. "</p><p>And that attitude is EXACTLY why computing still sucks.</p><p>If it involves computers, and it's an interesting unsolved problem - and guess what, a LOT of real-world problems turn out to be extremely interesting and extremely unsolved, full of all sorts of corner cases and exceptions to previously supposed 'laws' - then it's computer science.</p><p>System administration is like artificial intelligence. It's a human-centric job involving a lot of common sense, and it can't always be readily automated because the rules keep changing. That ought to raise warning flags.<nobr> <wbr></nobr>.Like vision or language recognition, a lot of scientists seem to think administration is so easy that only dumb people bother to investigate it. So they don't. But that's the opposite of the truth. Humans are still stuck doing rote maintenance precisely BECAUSE it's so tricky to do that computers can't yet do it. Which means it's very, very interesting.</p><p>A sensible approach to computer science would treat all phases of the development and deployment of information, computing and communication systems as computing systems in themselves. Yes, that involves crossing disciplinary boundaries. Perhaps that's more cybernetics or systems thinking or linguistics or sociology or psychology than computer science as it's currently narrowly defined itself to be. But in that case, computer science has defined itself out of the interesting part of the game - the impact and use of computing in the real world and what parts of this can and can't be predicted and automated - which would be a very sad thing.</p></htmltext>
<tokenext>" " Software maintenance " has absolutely nothing to do with computer science .
" And that attitude is EXACTLY why computing still sucks.If it involves computers , and it 's an interesting unsolved problem - and guess what , a LOT of real-world problems turn out to be extremely interesting and extremely unsolved , full of all sorts of corner cases and exceptions to previously supposed 'laws ' - then it 's computer science.System administration is like artificial intelligence .
It 's a human-centric job involving a lot of common sense , and it ca n't always be readily automated because the rules keep changing .
That ought to raise warning flags .
.Like vision or language recognition , a lot of scientists seem to think administration is so easy that only dumb people bother to investigate it .
So they do n't .
But that 's the opposite of the truth .
Humans are still stuck doing rote maintenance precisely BECAUSE it 's so tricky to do that computers ca n't yet do it .
Which means it 's very , very interesting.A sensible approach to computer science would treat all phases of the development and deployment of information , computing and communication systems as computing systems in themselves .
Yes , that involves crossing disciplinary boundaries .
Perhaps that 's more cybernetics or systems thinking or linguistics or sociology or psychology than computer science as it 's currently narrowly defined itself to be .
But in that case , computer science has defined itself out of the interesting part of the game - the impact and use of computing in the real world and what parts of this can and ca n't be predicted and automated - which would be a very sad thing .</tokentext>
<sentencetext>""Software maintenance" has absolutely nothing to do with computer science.
"And that attitude is EXACTLY why computing still sucks.If it involves computers, and it's an interesting unsolved problem - and guess what, a LOT of real-world problems turn out to be extremely interesting and extremely unsolved, full of all sorts of corner cases and exceptions to previously supposed 'laws' - then it's computer science.System administration is like artificial intelligence.
It's a human-centric job involving a lot of common sense, and it can't always be readily automated because the rules keep changing.
That ought to raise warning flags.
.Like vision or language recognition, a lot of scientists seem to think administration is so easy that only dumb people bother to investigate it.
So they don't.
But that's the opposite of the truth.
Humans are still stuck doing rote maintenance precisely BECAUSE it's so tricky to do that computers can't yet do it.
Which means it's very, very interesting.A sensible approach to computer science would treat all phases of the development and deployment of information, computing and communication systems as computing systems in themselves.
Yes, that involves crossing disciplinary boundaries.
Perhaps that's more cybernetics or systems thinking or linguistics or sociology or psychology than computer science as it's currently narrowly defined itself to be.
But in that case, computer science has defined itself out of the interesting part of the game - the impact and use of computing in the real world and what parts of this can and can't be predicted and automated - which would be a very sad thing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126792</id>
	<title>Re:That's mighty elitist of you</title>
	<author>Anonymous</author>
	<datestamp>1258448640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>A Turing machine cannot solve the problem of software maintenance. You cannot model software maintenance as a finite state machine. There is no algorithmic solution. There is no space-time trade-off that you can make improve the situation.</p></div><p> Now, where would I found a proof of all of this? Even an exact formulation of the problem of software maintenance would suffice in this case.</p></div>
	</htmltext>
<tokenext>A Turing machine can not solve the problem of software maintenance .
You can not model software maintenance as a finite state machine .
There is no algorithmic solution .
There is no space-time trade-off that you can make improve the situation .
Now , where would I found a proof of all of this ?
Even an exact formulation of the problem of software maintenance would suffice in this case .</tokentext>
<sentencetext>A Turing machine cannot solve the problem of software maintenance.
You cannot model software maintenance as a finite state machine.
There is no algorithmic solution.
There is no space-time trade-off that you can make improve the situation.
Now, where would I found a proof of all of this?
Even an exact formulation of the problem of software maintenance would suffice in this case.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125492</id>
	<title>Re:Important forgotten steps</title>
	<author>HighFalutinCoder</author>
	<datestamp>1258389660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You missed the last bullet point: "Quality Software...Priceless"  (or perhaps in this case, timeless)</htmltext>
<tokenext>You missed the last bullet point : " Quality Software...Priceless " ( or perhaps in this case , timeless )</tokentext>
<sentencetext>You missed the last bullet point: "Quality Software...Priceless"  (or perhaps in this case, timeless)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128208</id>
	<title>Re:Wait a second...</title>
	<author>hey!</author>
	<datestamp>1258469640000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Oh, modularity is undoubtedly a good thing.  There's a word for non-modular code: crap.</p><p>The problem is all the things you *can't* solve with modularity.  Having chosen the wrong architecture because you had the wrong conception of the problem isn't fixed by modularity.  You can swap out modules all day long and it won't help, because the problem is how the modules fit together.  Then there are the interdependencies that exist outside your architectural conceptualizations; that pretty much includes most security issues.  Your "modularity" is an abstraction you impose on the physical reality of computation.  The black hats peek under the covers and find all the couplings you can "safely ignore".</p><p>Then there are the things your module depends on: library versions, frameworks, operating systems, databases etc.   The answer to this is that most "modules" aren't really very modular because they're coupled to these things; I think of these couplings as "vertical" couplings as opposed to "horizontal" couplings with other modules I create.  The best answer is to de-couple modules from those things too, to isolate dependencies in a very small number of interface modules.  But that's a lot of work, and a lot of times you've got to do it with programmers who have something like "Struts for the Ignorant Programmer" open on their desk, giving them concrete, cut-and-paste examples of how to *couple* their code to some version of a framework.  Those programmers are so far from the ivory tower they're living in the treacle well.</p><p>That's the problem of craft in a nutshell.  You don't have unlimited time, but pure expediency can waste more of your time than anything else.  You can start chopping down a tree sooner if you don't bother to sharpen your ax, and if the boss judges progress by ax cuts you'll probably end up doing it that way.</p></htmltext>
<tokenext>Oh , modularity is undoubtedly a good thing .
There 's a word for non-modular code : crap.The problem is all the things you * ca n't * solve with modularity .
Having chosen the wrong architecture because you had the wrong conception of the problem is n't fixed by modularity .
You can swap out modules all day long and it wo n't help , because the problem is how the modules fit together .
Then there are the interdependencies that exist outside your architectural conceptualizations ; that pretty much includes most security issues .
Your " modularity " is an abstraction you impose on the physical reality of computation .
The black hats peek under the covers and find all the couplings you can " safely ignore " .Then there are the things your module depends on : library versions , frameworks , operating systems , databases etc .
The answer to this is that most " modules " are n't really very modular because they 're coupled to these things ; I think of these couplings as " vertical " couplings as opposed to " horizontal " couplings with other modules I create .
The best answer is to de-couple modules from those things too , to isolate dependencies in a very small number of interface modules .
But that 's a lot of work , and a lot of times you 've got to do it with programmers who have something like " Struts for the Ignorant Programmer " open on their desk , giving them concrete , cut-and-paste examples of how to * couple * their code to some version of a framework .
Those programmers are so far from the ivory tower they 're living in the treacle well.That 's the problem of craft in a nutshell .
You do n't have unlimited time , but pure expediency can waste more of your time than anything else .
You can start chopping down a tree sooner if you do n't bother to sharpen your ax , and if the boss judges progress by ax cuts you 'll probably end up doing it that way .</tokentext>
<sentencetext>Oh, modularity is undoubtedly a good thing.
There's a word for non-modular code: crap.The problem is all the things you *can't* solve with modularity.
Having chosen the wrong architecture because you had the wrong conception of the problem isn't fixed by modularity.
You can swap out modules all day long and it won't help, because the problem is how the modules fit together.
Then there are the interdependencies that exist outside your architectural conceptualizations; that pretty much includes most security issues.
Your "modularity" is an abstraction you impose on the physical reality of computation.
The black hats peek under the covers and find all the couplings you can "safely ignore".Then there are the things your module depends on: library versions, frameworks, operating systems, databases etc.
The answer to this is that most "modules" aren't really very modular because they're coupled to these things; I think of these couplings as "vertical" couplings as opposed to "horizontal" couplings with other modules I create.
The best answer is to de-couple modules from those things too, to isolate dependencies in a very small number of interface modules.
But that's a lot of work, and a lot of times you've got to do it with programmers who have something like "Struts for the Ignorant Programmer" open on their desk, giving them concrete, cut-and-paste examples of how to *couple* their code to some version of a framework.
Those programmers are so far from the ivory tower they're living in the treacle well.That's the problem of craft in a nutshell.
You don't have unlimited time, but pure expediency can waste more of your time than anything else.
You can start chopping down a tree sooner if you don't bother to sharpen your ax, and if the boss judges progress by ax cuts you'll probably end up doing it that way.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125424</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125404</id>
	<title>Re:Important forgotten steps</title>
	<author>Anonymous</author>
	<datestamp>1258388520000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>... and a partridge in a pear tree....</p></htmltext>
<tokenext>... and a partridge in a pear tree... .</tokentext>
<sentencetext>... and a partridge in a pear tree....</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127908</id>
	<title>Re:"Everyone knows maintenance is boring"</title>
	<author>Aladrin</author>
	<datestamp>1258466760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Even the 'boring' maintenance can be made fun by doing it right.  If you have had to do a task more than twice, or can see doing it multiple times in the future, it's obviously something that can use some automation.</p><p>In the rare case that it really -does- need a human eye on it, simplify it to such an extent that the boss would love to give it to someone that makes 1/4 your pay, and then you only have to deal with unforeseen problems with it.</p><p>When (as a smaller company) our system admin quit, I got stuck with all his non-sysadmin duties.  (There wasn't much to do system-wise at the time, so that was most of his job.)  Over the course of a few weeks, I turned his job into a series of scripts.  Eventually, I integrated the scripts into our administration system and now customer service ends up doing most of it.  When the dust finally settles for current projects, I'll be moving the last little bit I have to do over to the outsourced programming team.</p><p>Turning those tasks into automated or simplified processes was almost as much fun as my regular coding work.</p></htmltext>
<tokenext>Even the 'boring ' maintenance can be made fun by doing it right .
If you have had to do a task more than twice , or can see doing it multiple times in the future , it 's obviously something that can use some automation.In the rare case that it really -does- need a human eye on it , simplify it to such an extent that the boss would love to give it to someone that makes 1/4 your pay , and then you only have to deal with unforeseen problems with it.When ( as a smaller company ) our system admin quit , I got stuck with all his non-sysadmin duties .
( There was n't much to do system-wise at the time , so that was most of his job .
) Over the course of a few weeks , I turned his job into a series of scripts .
Eventually , I integrated the scripts into our administration system and now customer service ends up doing most of it .
When the dust finally settles for current projects , I 'll be moving the last little bit I have to do over to the outsourced programming team.Turning those tasks into automated or simplified processes was almost as much fun as my regular coding work .</tokentext>
<sentencetext>Even the 'boring' maintenance can be made fun by doing it right.
If you have had to do a task more than twice, or can see doing it multiple times in the future, it's obviously something that can use some automation.In the rare case that it really -does- need a human eye on it, simplify it to such an extent that the boss would love to give it to someone that makes 1/4 your pay, and then you only have to deal with unforeseen problems with it.When (as a smaller company) our system admin quit, I got stuck with all his non-sysadmin duties.
(There wasn't much to do system-wise at the time, so that was most of his job.
)  Over the course of a few weeks, I turned his job into a series of scripts.
Eventually, I integrated the scripts into our administration system and now customer service ends up doing most of it.
When the dust finally settles for current projects, I'll be moving the last little bit I have to do over to the outsourced programming team.Turning those tasks into automated or simplified processes was almost as much fun as my regular coding work.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30132916</id>
	<title>Re:Wait a second...</title>
	<author>jimicus</author>
	<datestamp>1258489140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The FA deals with that by proposing you include version numbering in the interface itself.</p></htmltext>
<tokenext>The FA deals with that by proposing you include version numbering in the interface itself .</tokentext>
<sentencetext>The FA deals with that by proposing you include version numbering in the interface itself.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125842</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126026</id>
	<title>Re:Different Kinds of Companies</title>
	<author>DigiShaman</author>
	<datestamp>1258395300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>History proves that <b>quantity</b> over quality is preferred throughout all human endeavors. Tangible items from mass production come to mind. However, non-tangible items such as ideas (code) also follow this route as well. Don't blame Microsoft. They're merely an example of what's naturally to come.</p></htmltext>
<tokenext>History proves that quantity over quality is preferred throughout all human endeavors .
Tangible items from mass production come to mind .
However , non-tangible items such as ideas ( code ) also follow this route as well .
Do n't blame Microsoft .
They 're merely an example of what 's naturally to come .</tokentext>
<sentencetext>History proves that quantity over quality is preferred throughout all human endeavors.
Tangible items from mass production come to mind.
However, non-tangible items such as ideas (code) also follow this route as well.
Don't blame Microsoft.
They're merely an example of what's naturally to come.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098</id>
	<title>Important forgotten steps</title>
	<author>Lord Grey</author>
	<datestamp>1258385460000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><ul>
<li>One Iteration Planning Meeting (minimum four hours in duration)</li><li>One Integration Planning Meeting, to schedule changes with all other changes (minimum three hours in duration)</li><li>Twenty Stand-up Meetings (two per day for ten days) so everyone can tell each other why they're behind on the planned changes</li><li>Two scheduled Backlog Meetings to reschedule the planned changes that won't make it into this iteration</li><li>Six presentations to the Senior Management Team of at least one hour each to communicate our effective Change Management Strategy</li><li>At least three Tag-Up Meetings, called spontaneously, because some people still just don't get it, originally scheduled for 30 minutes each but extended to 60 minutes because exactly one person in the room wanted to argue</li><li>One Retrospective Meeting, which no one wants to attend because they're already behind on the backlog tasks</li></ul></htmltext>
<tokenext>One Iteration Planning Meeting ( minimum four hours in duration ) One Integration Planning Meeting , to schedule changes with all other changes ( minimum three hours in duration ) Twenty Stand-up Meetings ( two per day for ten days ) so everyone can tell each other why they 're behind on the planned changesTwo scheduled Backlog Meetings to reschedule the planned changes that wo n't make it into this iterationSix presentations to the Senior Management Team of at least one hour each to communicate our effective Change Management StrategyAt least three Tag-Up Meetings , called spontaneously , because some people still just do n't get it , originally scheduled for 30 minutes each but extended to 60 minutes because exactly one person in the room wanted to argueOne Retrospective Meeting , which no one wants to attend because they 're already behind on the backlog tasks</tokentext>
<sentencetext>
One Iteration Planning Meeting (minimum four hours in duration)One Integration Planning Meeting, to schedule changes with all other changes (minimum three hours in duration)Twenty Stand-up Meetings (two per day for ten days) so everyone can tell each other why they're behind on the planned changesTwo scheduled Backlog Meetings to reschedule the planned changes that won't make it into this iterationSix presentations to the Senior Management Team of at least one hour each to communicate our effective Change Management StrategyAt least three Tag-Up Meetings, called spontaneously, because some people still just don't get it, originally scheduled for 30 minutes each but extended to 60 minutes because exactly one person in the room wanted to argueOne Retrospective Meeting, which no one wants to attend because they're already behind on the backlog tasks</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125208</id>
	<title>Good luck</title>
	<author>Anonymous</author>
	<datestamp>1258386600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A lot of admins are pretty wary of throwing the latest and greatest on their boxes for the simple reason that it may, or shall I say, will break things. Its no fun to throw a service pack on to find it has nuked your installation, or upgrading your mail server to find out that your configuration isn't global to the new version. Now that sort of thing happens. I'm just saying there are all kinds of little issues (or huge ones) that can arrive. At least with older software you already know the faults and are prepared to work around them. Security has become the number 1 reason that software is now a continuous version stream with patches rolling out every 6 minutes. The UNIX-like OSes of the world have always handled this concept more gracefully, but when you look at windows that wants to reboot 4 times a week for updates it seems much more like an afterthought. Even linux can handle most updates without a reboot or hiccup. You don't even have to know that they occur of you like. If they can figure out how to swap the kernel live, we might start to see some really insane up times. I don't understand his argument. Most server type operating systems have few issues with updating themselves on the fly. There are a lot of insecure, unpatched boxes out there, but that is more bad administration than anything. Is there something that I am missing here or is he talking about ease of migration with data and new versions of software and keeping types universal so that they will interface with different versions? THAT is a problem. Like, for instance, I've been having some fun compiling old versions of stuff on Ubuntu and trying to figure out what library versions it was compiled against. The fat binary blob is not such a bad idea when you have terrabytes of space...<nobr> <wbr></nobr>:)</p></htmltext>
<tokenext>A lot of admins are pretty wary of throwing the latest and greatest on their boxes for the simple reason that it may , or shall I say , will break things .
Its no fun to throw a service pack on to find it has nuked your installation , or upgrading your mail server to find out that your configuration is n't global to the new version .
Now that sort of thing happens .
I 'm just saying there are all kinds of little issues ( or huge ones ) that can arrive .
At least with older software you already know the faults and are prepared to work around them .
Security has become the number 1 reason that software is now a continuous version stream with patches rolling out every 6 minutes .
The UNIX-like OSes of the world have always handled this concept more gracefully , but when you look at windows that wants to reboot 4 times a week for updates it seems much more like an afterthought .
Even linux can handle most updates without a reboot or hiccup .
You do n't even have to know that they occur of you like .
If they can figure out how to swap the kernel live , we might start to see some really insane up times .
I do n't understand his argument .
Most server type operating systems have few issues with updating themselves on the fly .
There are a lot of insecure , unpatched boxes out there , but that is more bad administration than anything .
Is there something that I am missing here or is he talking about ease of migration with data and new versions of software and keeping types universal so that they will interface with different versions ?
THAT is a problem .
Like , for instance , I 've been having some fun compiling old versions of stuff on Ubuntu and trying to figure out what library versions it was compiled against .
The fat binary blob is not such a bad idea when you have terrabytes of space... : )</tokentext>
<sentencetext>A lot of admins are pretty wary of throwing the latest and greatest on their boxes for the simple reason that it may, or shall I say, will break things.
Its no fun to throw a service pack on to find it has nuked your installation, or upgrading your mail server to find out that your configuration isn't global to the new version.
Now that sort of thing happens.
I'm just saying there are all kinds of little issues (or huge ones) that can arrive.
At least with older software you already know the faults and are prepared to work around them.
Security has become the number 1 reason that software is now a continuous version stream with patches rolling out every 6 minutes.
The UNIX-like OSes of the world have always handled this concept more gracefully, but when you look at windows that wants to reboot 4 times a week for updates it seems much more like an afterthought.
Even linux can handle most updates without a reboot or hiccup.
You don't even have to know that they occur of you like.
If they can figure out how to swap the kernel live, we might start to see some really insane up times.
I don't understand his argument.
Most server type operating systems have few issues with updating themselves on the fly.
There are a lot of insecure, unpatched boxes out there, but that is more bad administration than anything.
Is there something that I am missing here or is he talking about ease of migration with data and new versions of software and keeping types universal so that they will interface with different versions?
THAT is a problem.
Like, for instance, I've been having some fun compiling old versions of stuff on Ubuntu and trying to figure out what library versions it was compiled against.
The fat binary blob is not such a bad idea when you have terrabytes of space... :)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128538</id>
	<title>lol</title>
	<author>Anonymous</author>
	<datestamp>1258471680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>way to tell the entire internet that you, Brian Gordon, don't know jack about computers.</p></htmltext>
<tokenext>way to tell the entire internet that you , Brian Gordon , do n't know jack about computers .</tokentext>
<sentencetext>way to tell the entire internet that you, Brian Gordon, don't know jack about computers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125418</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126082</id>
	<title>Re:"Everyone knows maintenance is boring"</title>
	<author>syousef</author>
	<datestamp>1258396020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><i>Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure. </i></p><p>Clearly you've worked only on code that needs a bit of tidy up. Try reading code that hasn't been documented well if at all, and looks like it's been run through a code obfuscator (ie not just poor formatting), then realising that not only is the task the code is suppose to accomplish not documented, but the people who wrote the original code left while you were still in primary school. Oh by the way it's part of a poorly integrated but critical system and if any part doesn't work exactly the way the old part did, you're in trouble because the whole system falls apart.</p><p>The trouble is even a gifted coder is likely to miss something, and those that review will have a shallower not deeper understanding so while they MIGHT pick up something important don't hold your breath. Realistically your only hope in many cases is to start fresh with a new analysis and design and replace your critical system big bang style (while trying not to go grey worrying over that approaching day).</p><p><i>It's all in the mindset. It's only boring if you limit yourself to the boring parts.</i></p><p>Most of the time, I'd kill for boring. I don't come to work for excitement.</p></htmltext>
<tokenext>Taking code and cutting its size by half , fixing up all the screwed-up inconsistent formatting , while adding functionality and reducing bug counts , is a pleasure .
Clearly you 've worked only on code that needs a bit of tidy up .
Try reading code that has n't been documented well if at all , and looks like it 's been run through a code obfuscator ( ie not just poor formatting ) , then realising that not only is the task the code is suppose to accomplish not documented , but the people who wrote the original code left while you were still in primary school .
Oh by the way it 's part of a poorly integrated but critical system and if any part does n't work exactly the way the old part did , you 're in trouble because the whole system falls apart.The trouble is even a gifted coder is likely to miss something , and those that review will have a shallower not deeper understanding so while they MIGHT pick up something important do n't hold your breath .
Realistically your only hope in many cases is to start fresh with a new analysis and design and replace your critical system big bang style ( while trying not to go grey worrying over that approaching day ) .It 's all in the mindset .
It 's only boring if you limit yourself to the boring parts.Most of the time , I 'd kill for boring .
I do n't come to work for excitement .</tokentext>
<sentencetext>Taking code and cutting its size by half, fixing up all the screwed-up inconsistent formatting, while adding functionality and reducing bug counts, is a pleasure.
Clearly you've worked only on code that needs a bit of tidy up.
Try reading code that hasn't been documented well if at all, and looks like it's been run through a code obfuscator (ie not just poor formatting), then realising that not only is the task the code is suppose to accomplish not documented, but the people who wrote the original code left while you were still in primary school.
Oh by the way it's part of a poorly integrated but critical system and if any part doesn't work exactly the way the old part did, you're in trouble because the whole system falls apart.The trouble is even a gifted coder is likely to miss something, and those that review will have a shallower not deeper understanding so while they MIGHT pick up something important don't hold your breath.
Realistically your only hope in many cases is to start fresh with a new analysis and design and replace your critical system big bang style (while trying not to go grey worrying over that approaching day).It's all in the mindset.
It's only boring if you limit yourself to the boring parts.Most of the time, I'd kill for boring.
I don't come to work for excitement.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127528</id>
	<title>Different maintenance..</title>
	<author>renoX</author>
	<datestamp>1258460640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>He is talking about the need to version protocols to simplify future change, you're talking about code refactoring which usually don't change the interface..</p><p>I've needed worked on a project where we used 'versionned protocols' though<nobr> <wbr></nobr>:-(</p></htmltext>
<tokenext>He is talking about the need to version protocols to simplify future change , you 're talking about code refactoring which usually do n't change the interface..I 've needed worked on a project where we used 'versionned protocols ' though : - (</tokentext>
<sentencetext>He is talking about the need to version protocols to simplify future change, you're talking about code refactoring which usually don't change the interface..I've needed worked on a project where we used 'versionned protocols' though :-(</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30132308</id>
	<title>Re:Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258487100000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>""Software maintenance" has absolutely nothing to do with computer science. "</p><p>And that attitude is EXACTLY why computing still sucks.</p><p>If it involves computers, and it's an interesting unsolved problem - and guess what, a LOT of real-world problems turn out to be extremely interesting and extremely unsolved, full of all sorts of corner cases and exceptions to previously supposed 'laws' - then it's computer science.</p></div><p>No true. Software Engineering solves a lot of unsolved problems without having to do computer science. Computer Science is about theory, not implementation. Computer Science deals with the Universal Turing Machine and treats all computers like it. Computer Science programs tend to not discuss how to do things with efficiency or with limited resources.
<br> <br>
Computer Engineering programs tend to talk a little about Computer Programming; but mostly focus on the engineering behind computer hardware (e.g. PCI boards, processors, etc.).
<br> <br>
Software Engineering is about producing products that resolve unresolved problems using standard practices. It's about architecting, designing, and otherwise engineering a product to meet that problem and overcome it. It's done with computers, solves interesting unsolved problems, and has a lot of corner cases and exceptions - far more than you find in most any Computer Science theory since the problems Software Engineering addresses are typically for limited memory/processor/etc, making the challenge that much more.
<br> <br>
And no, this is not a <i>new</i> definition of Computer Science, or Computer Engineering. It's just that so many Computer Scientists fail to understand the differences between Science and Engineering.</p></div>
	</htmltext>
<tokenext>" " Software maintenance " has absolutely nothing to do with computer science .
" And that attitude is EXACTLY why computing still sucks.If it involves computers , and it 's an interesting unsolved problem - and guess what , a LOT of real-world problems turn out to be extremely interesting and extremely unsolved , full of all sorts of corner cases and exceptions to previously supposed 'laws ' - then it 's computer science.No true .
Software Engineering solves a lot of unsolved problems without having to do computer science .
Computer Science is about theory , not implementation .
Computer Science deals with the Universal Turing Machine and treats all computers like it .
Computer Science programs tend to not discuss how to do things with efficiency or with limited resources .
Computer Engineering programs tend to talk a little about Computer Programming ; but mostly focus on the engineering behind computer hardware ( e.g .
PCI boards , processors , etc. ) .
Software Engineering is about producing products that resolve unresolved problems using standard practices .
It 's about architecting , designing , and otherwise engineering a product to meet that problem and overcome it .
It 's done with computers , solves interesting unsolved problems , and has a lot of corner cases and exceptions - far more than you find in most any Computer Science theory since the problems Software Engineering addresses are typically for limited memory/processor/etc , making the challenge that much more .
And no , this is not a new definition of Computer Science , or Computer Engineering .
It 's just that so many Computer Scientists fail to understand the differences between Science and Engineering .</tokentext>
<sentencetext>""Software maintenance" has absolutely nothing to do with computer science.
"And that attitude is EXACTLY why computing still sucks.If it involves computers, and it's an interesting unsolved problem - and guess what, a LOT of real-world problems turn out to be extremely interesting and extremely unsolved, full of all sorts of corner cases and exceptions to previously supposed 'laws' - then it's computer science.No true.
Software Engineering solves a lot of unsolved problems without having to do computer science.
Computer Science is about theory, not implementation.
Computer Science deals with the Universal Turing Machine and treats all computers like it.
Computer Science programs tend to not discuss how to do things with efficiency or with limited resources.
Computer Engineering programs tend to talk a little about Computer Programming; but mostly focus on the engineering behind computer hardware (e.g.
PCI boards, processors, etc.).
Software Engineering is about producing products that resolve unresolved problems using standard practices.
It's about architecting, designing, and otherwise engineering a product to meet that problem and overcome it.
It's done with computers, solves interesting unsolved problems, and has a lot of corner cases and exceptions - far more than you find in most any Computer Science theory since the problems Software Engineering addresses are typically for limited memory/processor/etc, making the challenge that much more.
And no, this is not a new definition of Computer Science, or Computer Engineering.
It's just that so many Computer Scientists fail to understand the differences between Science and Engineering.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125574</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125266</id>
	<title>Re:Important forgotten steps</title>
	<author>NoYob</author>
	<datestamp>1258387080000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>You know, if you numbered them, then you can write a book (of course add a lot of fluff and unsubstantiated horseshit) called "The 7 Habits of Highly Ineffective Software Teams", have it published, be a huge hit, milk the fucker with another book called the "8th Habit", workbooks, do lectures at $50,000 a pop, and after a couple years, retire rich!<p>Dipshit PHBs would be buying them left and right!</p></htmltext>
<tokenext>You know , if you numbered them , then you can write a book ( of course add a lot of fluff and unsubstantiated horseshit ) called " The 7 Habits of Highly Ineffective Software Teams " , have it published , be a huge hit , milk the fucker with another book called the " 8th Habit " , workbooks , do lectures at $ 50,000 a pop , and after a couple years , retire rich ! Dipshit PHBs would be buying them left and right !</tokentext>
<sentencetext>You know, if you numbered them, then you can write a book (of course add a lot of fluff and unsubstantiated horseshit) called "The 7 Habits of Highly Ineffective Software Teams", have it published, be a huge hit, milk the fucker with another book called the "8th Habit", workbooks, do lectures at $50,000 a pop, and after a couple years, retire rich!Dipshit PHBs would be buying them left and right!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30139404</id>
	<title>Wow!</title>
	<author>gbutler69</author>
	<datestamp>1258476900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This sounds like a familiar story. You've got the right attitude now.</htmltext>
<tokenext>This sounds like a familiar story .
You 've got the right attitude now .</tokentext>
<sentencetext>This sounds like a familiar story.
You've got the right attitude now.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127562</id>
	<title>Not a hot field of study either</title>
	<author>Acer500</author>
	<datestamp>1258461300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Like many others, most of my work is maintaining legacy code (and we're talking everything from SUN's old Fort&#233; UDS to Visual Basic 6 and everything in between).
<br> <br>
I wanted to do a Master's degree in CS, and during my interviews, they asked what would I be interested in researching... I told them I found software maintenance to be a line of study that hasn't been properly studied, and they dismissed it (mostly for it not being "sexy" enough). So it's not exactly a "hot" field of study...</htmltext>
<tokenext>Like many others , most of my work is maintaining legacy code ( and we 're talking everything from SUN 's old Fort   UDS to Visual Basic 6 and everything in between ) .
I wanted to do a Master 's degree in CS , and during my interviews , they asked what would I be interested in researching... I told them I found software maintenance to be a line of study that has n't been properly studied , and they dismissed it ( mostly for it not being " sexy " enough ) .
So it 's not exactly a " hot " field of study.. .</tokentext>
<sentencetext>Like many others, most of my work is maintaining legacy code (and we're talking everything from SUN's old Forté UDS to Visual Basic 6 and everything in between).
I wanted to do a Master's degree in CS, and during my interviews, they asked what would I be interested in researching... I told them I found software maintenance to be a line of study that hasn't been properly studied, and they dismissed it (mostly for it not being "sexy" enough).
So it's not exactly a "hot" field of study...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125424</id>
	<title>Re:Wait a second...</title>
	<author>Anonymous</author>
	<datestamp>1258388700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>0</modscore>
	<htmltext><p>Modularity is one of those things that sounds great when you're an academic, when you're a manager who has never touched code, or when you're an accountant.</p><p>Such people think of real-world code as being completely interchangeable. To them, it's nothing more than the nuts or bolts they'd see at a hardware store. They think that programmers just grab some of these "modules", some of those "modules", put them in the same source file and BAM, we have working software.</p><p>Of course, reality gets in the way and makes their theoretical world disappear instantly. Such modularity typically comes at a great cost. Even when using dependency injection and techniques like that, modularity is always a pipe dream.</p></htmltext>
<tokenext>Modularity is one of those things that sounds great when you 're an academic , when you 're a manager who has never touched code , or when you 're an accountant.Such people think of real-world code as being completely interchangeable .
To them , it 's nothing more than the nuts or bolts they 'd see at a hardware store .
They think that programmers just grab some of these " modules " , some of those " modules " , put them in the same source file and BAM , we have working software.Of course , reality gets in the way and makes their theoretical world disappear instantly .
Such modularity typically comes at a great cost .
Even when using dependency injection and techniques like that , modularity is always a pipe dream .</tokentext>
<sentencetext>Modularity is one of those things that sounds great when you're an academic, when you're a manager who has never touched code, or when you're an accountant.Such people think of real-world code as being completely interchangeable.
To them, it's nothing more than the nuts or bolts they'd see at a hardware store.
They think that programmers just grab some of these "modules", some of those "modules", put them in the same source file and BAM, we have working software.Of course, reality gets in the way and makes their theoretical world disappear instantly.
Such modularity typically comes at a great cost.
Even when using dependency injection and techniques like that, modularity is always a pipe dream.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125708</id>
	<title>No offense..</title>
	<author>Anonymous</author>
	<datestamp>1258392060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Hey, look, no offense, but this kind of just seems a bit like self promotion to me?</p><p>Communications of The ACM publishes lots of awesome articles quite often, and those of us interested often subscribe.  I guess I just don't see how the thoughts of two software professionals on software maintenance really needs to be a front page slashdot article.</p><p>*watches as he is modded troll*</p></htmltext>
<tokenext>Hey , look , no offense , but this kind of just seems a bit like self promotion to me ? Communications of The ACM publishes lots of awesome articles quite often , and those of us interested often subscribe .
I guess I just do n't see how the thoughts of two software professionals on software maintenance really needs to be a front page slashdot article .
* watches as he is modded troll *</tokentext>
<sentencetext>Hey, look, no offense, but this kind of just seems a bit like self promotion to me?Communications of The ACM publishes lots of awesome articles quite often, and those of us interested often subscribe.
I guess I just don't see how the thoughts of two software professionals on software maintenance really needs to be a front page slashdot article.
*watches as he is modded troll*</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30139280</id>
	<title>Re:Theory vs practice</title>
	<author>Lotana</author>
	<datestamp>1258476120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is just spot on!</p></htmltext>
<tokenext>This is just spot on !</tokentext>
<sentencetext>This is just spot on!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125454</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127844</id>
	<title>Great article</title>
	<author>gander666</author>
	<datestamp>1258466160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Just wanted to say that the article was probably one of the best I had read in a while.  I am a former member of the ACM (and may renew because of articles such as this).  <br> <br>Great reading!</htmltext>
<tokenext>Just wanted to say that the article was probably one of the best I had read in a while .
I am a former member of the ACM ( and may renew because of articles such as this ) .
Great reading !</tokentext>
<sentencetext>Just wanted to say that the article was probably one of the best I had read in a while.
I am a former member of the ACM (and may renew because of articles such as this).
Great reading!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125386</id>
	<title>Re:Important forgotten steps</title>
	<author>steelfood</author>
	<datestamp>1258388220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And nobody to take charge and responsibility for it all.</p><p>A project done well needs a strong leader who can manage both the needs of the users, the coders, and upper management. Only then can things happen. Without somebody like that, all you'll get out of it is an office tug-of-war between all of the interests. It's why leadership and direction are such important qualities in management, and why companies try to hire and keep the best.</p><p>In fact, it's why the CEO having a vision of where the company's going, and able to keep everybody sold on that vision, is so important. There are probably a million people with the kind of charisma and intelligence as Steve Jobs. But there's only one Steve Jobs, because he's the only one who knows where Apple is going--he's the only one who knows where he wants to go. He's made mistakes in the past perhaps, but only he's fully able to comprehend the lessons learned from those mistakes and meld it into his vision.</p></htmltext>
<tokenext>And nobody to take charge and responsibility for it all.A project done well needs a strong leader who can manage both the needs of the users , the coders , and upper management .
Only then can things happen .
Without somebody like that , all you 'll get out of it is an office tug-of-war between all of the interests .
It 's why leadership and direction are such important qualities in management , and why companies try to hire and keep the best.In fact , it 's why the CEO having a vision of where the company 's going , and able to keep everybody sold on that vision , is so important .
There are probably a million people with the kind of charisma and intelligence as Steve Jobs .
But there 's only one Steve Jobs , because he 's the only one who knows where Apple is going--he 's the only one who knows where he wants to go .
He 's made mistakes in the past perhaps , but only he 's fully able to comprehend the lessons learned from those mistakes and meld it into his vision .</tokentext>
<sentencetext>And nobody to take charge and responsibility for it all.A project done well needs a strong leader who can manage both the needs of the users, the coders, and upper management.
Only then can things happen.
Without somebody like that, all you'll get out of it is an office tug-of-war between all of the interests.
It's why leadership and direction are such important qualities in management, and why companies try to hire and keep the best.In fact, it's why the CEO having a vision of where the company's going, and able to keep everybody sold on that vision, is so important.
There are probably a million people with the kind of charisma and intelligence as Steve Jobs.
But there's only one Steve Jobs, because he's the only one who knows where Apple is going--he's the only one who knows where he wants to go.
He's made mistakes in the past perhaps, but only he's fully able to comprehend the lessons learned from those mistakes and meld it into his vision.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125372</id>
	<title>Stopped reading right here</title>
	<author>Anonymous</author>
	<datestamp>1258388100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>Software in particular must be written to evolve as changes happen, using a weakly typed high-level language and, in older programs, a good macro assembler.</p></div></blockquote><p>When you start claiming that the ability to add 1 to "1" and get 2 instead of a compile-time or even runtime type error makes software <i>more maintainable</i> (or is even useful in any way), I stop listening to your advice.</p></div>
	</htmltext>
<tokenext>Software in particular must be written to evolve as changes happen , using a weakly typed high-level language and , in older programs , a good macro assembler.When you start claiming that the ability to add 1 to " 1 " and get 2 instead of a compile-time or even runtime type error makes software more maintainable ( or is even useful in any way ) , I stop listening to your advice .</tokentext>
<sentencetext>Software in particular must be written to evolve as changes happen, using a weakly typed high-level language and, in older programs, a good macro assembler.When you start claiming that the ability to add 1 to "1" and get 2 instead of a compile-time or even runtime type error makes software more maintainable (or is even useful in any way), I stop listening to your advice.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30153006</id>
	<title>re: We Really Don't Know Jack About Maintenance</title>
	<author>ps2os2</author>
	<datestamp>1257097020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This is nothing new. I have been in the IT industry for about 40 years. I cannot tell you the number of times I have run into this in various installations. I can also tell you the horror stories that would leave you wondering what were they thinking.</p><p>For about 20-30 years IBM was pretty much in the same mode until user groups united and screamed at IBM to come up with a solution. Mind you it was not overnite that IBM (and their customers) came up with a pretty darn good solution. *IF* you followed the rules you could pretty much bring a new system in and reapply all the local modifications within (most of the time) with either a small amount of work or a reasonable amount of work to get the local modifications onto the new system in usually less than a weeks effort by one person. There are some exceptions I know but if you kept a orderly system and followed the rules you were pretty much a minor clerical work on local modifications to install a new release of the OS or a major OS upgrade. BUT everyone had to follow the rules (yes even IBM) the rules are quite easy and straightforward. No need to list them here as only a person with IBM OS background would understand them, but they are reasonably simple. Depending on how you chose the system type to be installed it was for the most part straight forward. It also took thumping of management heads to get into the mode of either complete replacement of the the OS or upgrading the OS with another release. Also, the fact that (currently) if I recall correctly IBM drops support every two years on their flag ship OS so you are on a treadmill (so to speak) of keeping everything reasonably current.</p></htmltext>
<tokenext>This is nothing new .
I have been in the IT industry for about 40 years .
I can not tell you the number of times I have run into this in various installations .
I can also tell you the horror stories that would leave you wondering what were they thinking.For about 20-30 years IBM was pretty much in the same mode until user groups united and screamed at IBM to come up with a solution .
Mind you it was not overnite that IBM ( and their customers ) came up with a pretty darn good solution .
* IF * you followed the rules you could pretty much bring a new system in and reapply all the local modifications within ( most of the time ) with either a small amount of work or a reasonable amount of work to get the local modifications onto the new system in usually less than a weeks effort by one person .
There are some exceptions I know but if you kept a orderly system and followed the rules you were pretty much a minor clerical work on local modifications to install a new release of the OS or a major OS upgrade .
BUT everyone had to follow the rules ( yes even IBM ) the rules are quite easy and straightforward .
No need to list them here as only a person with IBM OS background would understand them , but they are reasonably simple .
Depending on how you chose the system type to be installed it was for the most part straight forward .
It also took thumping of management heads to get into the mode of either complete replacement of the the OS or upgrading the OS with another release .
Also , the fact that ( currently ) if I recall correctly IBM drops support every two years on their flag ship OS so you are on a treadmill ( so to speak ) of keeping everything reasonably current .</tokentext>
<sentencetext>This is nothing new.
I have been in the IT industry for about 40 years.
I cannot tell you the number of times I have run into this in various installations.
I can also tell you the horror stories that would leave you wondering what were they thinking.For about 20-30 years IBM was pretty much in the same mode until user groups united and screamed at IBM to come up with a solution.
Mind you it was not overnite that IBM (and their customers) came up with a pretty darn good solution.
*IF* you followed the rules you could pretty much bring a new system in and reapply all the local modifications within (most of the time) with either a small amount of work or a reasonable amount of work to get the local modifications onto the new system in usually less than a weeks effort by one person.
There are some exceptions I know but if you kept a orderly system and followed the rules you were pretty much a minor clerical work on local modifications to install a new release of the OS or a major OS upgrade.
BUT everyone had to follow the rules (yes even IBM) the rules are quite easy and straightforward.
No need to list them here as only a person with IBM OS background would understand them, but they are reasonably simple.
Depending on how you chose the system type to be installed it was for the most part straight forward.
It also took thumping of management heads to get into the mode of either complete replacement of the the OS or upgrading the OS with another release.
Also, the fact that (currently) if I recall correctly IBM drops support every two years on their flag ship OS so you are on a treadmill (so to speak) of keeping everything reasonably current.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127176</id>
	<title>Re:Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258454880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>So then why is it (Software Engineering) a major part of my university Computer Science bachelor (and an often picked Master course)?</p></htmltext>
<tokenext>So then why is it ( Software Engineering ) a major part of my university Computer Science bachelor ( and an often picked Master course ) ?</tokentext>
<sentencetext>So then why is it (Software Engineering) a major part of my university Computer Science bachelor (and an often picked Master course)?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125212</id>
	<title>Re:Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258386660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>And really if you are excluding software maintenance from the field of computer science, you pretty much have to exclude every other software technique. Techniques for writing maintainable code go hand in hand with every other development technique.</p></div></blockquote><p>I don't see the problem here. Software development is not computer science. Software development is to computer science as engineering is to physics. <a href="http://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811/ref=sr\_1\_1?ie=UTF8&amp;s=books&amp;qid=1258426108&amp;sr=1-1" title="amazon.com" rel="nofollow">This</a> [amazon.com] is computer science. <a href="http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr\_1\_1?ie=UTF8&amp;s=books&amp;qid=1258426126&amp;sr=1-1" title="amazon.com" rel="nofollow">This</a> [amazon.com] is not.</p></div>
	</htmltext>
<tokenext>And really if you are excluding software maintenance from the field of computer science , you pretty much have to exclude every other software technique .
Techniques for writing maintainable code go hand in hand with every other development technique.I do n't see the problem here .
Software development is not computer science .
Software development is to computer science as engineering is to physics .
This [ amazon.com ] is computer science .
This [ amazon.com ] is not .</tokentext>
<sentencetext>And really if you are excluding software maintenance from the field of computer science, you pretty much have to exclude every other software technique.
Techniques for writing maintainable code go hand in hand with every other development technique.I don't see the problem here.
Software development is not computer science.
Software development is to computer science as engineering is to physics.
This [amazon.com] is computer science.
This [amazon.com] is not.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125060</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125506</id>
	<title>Re:"Everyone knows maintenance is boring"</title>
	<author>Anonymous</author>
	<datestamp>1258389780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Well, I once realized, that <em>all</em> code basically is "throwaway code". Meaning, that you only can do proper evolution of a software project, if you do a complete rewrite from time to time.<br>That is, because the basic usage and purpose of the program changes with time. New, better paradigms get discovered, etc. And they don't fit with the old basic architecture.<br>If you just endlessly patch them on top, you get something like Windows ME, Internet Explorer, or MS Office.</p><p>So you make clear cuts: You stay with the old paradigms in the old code base, and just perfect that one, fix all the bugs, etc. Meanwhile you slowly use more and more resources to transition to the new code base, written with a really proper foundation of design, adapted to the new usage patterns and purposes. Backwards compatibility really should <em>not</em> even be considered here! Importers, yes. Real compatibility: No way. Because that would be the opposite of a clear cut, by not allowing 100\% freedom to redesign it properly. Which means you drag along the old crap anyway, despite it not fitting into the new ideas.</p><p>That's why I now always use a 4.1-part versioning scheme:<br>"G.M.m.p b", where<br>b: Build number. Including "beta"/"alpha"/"RC" status, etc.<br>p: Patch number. Drop-in update with no functionality change at all. Only bug/security fixes.<br>m: Minor version number. Drop-in update with functionality changes.<br>M: Major version number. Can not be dropped in just like that. Big functionality changes. But no paradigm changes.<br>G: Generation number. Complete rewrite with paradigm changes. Up to being a completely new program. Comparable to the number in movies or games. Like GTA 2, GTA 3, GTA 4.</p><p>Also as with games and movies, different generations can co-exist for a long time. Allowing the old version to become perfected and allowing people their own choice of when to move.<br>The rule is that the old generation can only be abandoned, when each and <em>every single function</em> of it is available in the new generation. They can be different, or not needed anymore because of the new paradigms. But they have to be there. No exceptions!<br>That is one big reason why people do not want to switch to Linux, Firefox or OpenOffice from Windows, Internet Explorer and MS Office. They still lack that tiny feature that makes it more effort to switch, than to stay an suffer the shitty product. It's human nature of inertia-caused efficiency.</p><p>That is why it's so bad that how KDE3 now gets abandoned, despite KDE4 still being close to alpha state (yes I talk about KDE 4.3) in terms of comparable fullness of functionality and all-around polishing.</p></htmltext>
<tokenext>Well , I once realized , that all code basically is " throwaway code " .
Meaning , that you only can do proper evolution of a software project , if you do a complete rewrite from time to time.That is , because the basic usage and purpose of the program changes with time .
New , better paradigms get discovered , etc .
And they do n't fit with the old basic architecture.If you just endlessly patch them on top , you get something like Windows ME , Internet Explorer , or MS Office.So you make clear cuts : You stay with the old paradigms in the old code base , and just perfect that one , fix all the bugs , etc .
Meanwhile you slowly use more and more resources to transition to the new code base , written with a really proper foundation of design , adapted to the new usage patterns and purposes .
Backwards compatibility really should not even be considered here !
Importers , yes .
Real compatibility : No way .
Because that would be the opposite of a clear cut , by not allowing 100 \ % freedom to redesign it properly .
Which means you drag along the old crap anyway , despite it not fitting into the new ideas.That 's why I now always use a 4.1-part versioning scheme : " G.M.m.p b " , whereb : Build number .
Including " beta " / " alpha " / " RC " status , etc.p : Patch number .
Drop-in update with no functionality change at all .
Only bug/security fixes.m : Minor version number .
Drop-in update with functionality changes.M : Major version number .
Can not be dropped in just like that .
Big functionality changes .
But no paradigm changes.G : Generation number .
Complete rewrite with paradigm changes .
Up to being a completely new program .
Comparable to the number in movies or games .
Like GTA 2 , GTA 3 , GTA 4.Also as with games and movies , different generations can co-exist for a long time .
Allowing the old version to become perfected and allowing people their own choice of when to move.The rule is that the old generation can only be abandoned , when each and every single function of it is available in the new generation .
They can be different , or not needed anymore because of the new paradigms .
But they have to be there .
No exceptions ! That is one big reason why people do not want to switch to Linux , Firefox or OpenOffice from Windows , Internet Explorer and MS Office .
They still lack that tiny feature that makes it more effort to switch , than to stay an suffer the shitty product .
It 's human nature of inertia-caused efficiency.That is why it 's so bad that how KDE3 now gets abandoned , despite KDE4 still being close to alpha state ( yes I talk about KDE 4.3 ) in terms of comparable fullness of functionality and all-around polishing .</tokentext>
<sentencetext>Well, I once realized, that all code basically is "throwaway code".
Meaning, that you only can do proper evolution of a software project, if you do a complete rewrite from time to time.That is, because the basic usage and purpose of the program changes with time.
New, better paradigms get discovered, etc.
And they don't fit with the old basic architecture.If you just endlessly patch them on top, you get something like Windows ME, Internet Explorer, or MS Office.So you make clear cuts: You stay with the old paradigms in the old code base, and just perfect that one, fix all the bugs, etc.
Meanwhile you slowly use more and more resources to transition to the new code base, written with a really proper foundation of design, adapted to the new usage patterns and purposes.
Backwards compatibility really should not even be considered here!
Importers, yes.
Real compatibility: No way.
Because that would be the opposite of a clear cut, by not allowing 100\% freedom to redesign it properly.
Which means you drag along the old crap anyway, despite it not fitting into the new ideas.That's why I now always use a 4.1-part versioning scheme:"G.M.m.p b", whereb: Build number.
Including "beta"/"alpha"/"RC" status, etc.p: Patch number.
Drop-in update with no functionality change at all.
Only bug/security fixes.m: Minor version number.
Drop-in update with functionality changes.M: Major version number.
Can not be dropped in just like that.
Big functionality changes.
But no paradigm changes.G: Generation number.
Complete rewrite with paradigm changes.
Up to being a completely new program.
Comparable to the number in movies or games.
Like GTA 2, GTA 3, GTA 4.Also as with games and movies, different generations can co-exist for a long time.
Allowing the old version to become perfected and allowing people their own choice of when to move.The rule is that the old generation can only be abandoned, when each and every single function of it is available in the new generation.
They can be different, or not needed anymore because of the new paradigms.
But they have to be there.
No exceptions!That is one big reason why people do not want to switch to Linux, Firefox or OpenOffice from Windows, Internet Explorer and MS Office.
They still lack that tiny feature that makes it more effort to switch, than to stay an suffer the shitty product.
It's human nature of inertia-caused efficiency.That is why it's so bad that how KDE3 now gets abandoned, despite KDE4 still being close to alpha state (yes I talk about KDE 4.3) in terms of comparable fullness of functionality and all-around polishing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127550</id>
	<title>Re:After the software is written it gets maintaine</title>
	<author>elnyka</author>
	<datestamp>1258461180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>And that means the validation people run through their test book and create maybe 1000 or 2000 bug reports. These bug reports bounce around through the development teams acquiring cruft along the way. When the bug eventually stops bouncing somebody might have a go at fixing it. So they change something and if they can't see the bug anymore they go <b>cvs commit</b> right then and there. At the same time the other 1999 bugs are bouncing around, looking for a home.</p><p>At the end of the (as we call it) bug fixing process the original software doesn't exist in its original form. It appears to pass most of the test sbut you would not be advised to lean against it or anything because something else might break.</p></div><p>software maintenance =/= bug fixing.</p></div>
	</htmltext>
<tokenext>And that means the validation people run through their test book and create maybe 1000 or 2000 bug reports .
These bug reports bounce around through the development teams acquiring cruft along the way .
When the bug eventually stops bouncing somebody might have a go at fixing it .
So they change something and if they ca n't see the bug anymore they go cvs commit right then and there .
At the same time the other 1999 bugs are bouncing around , looking for a home.At the end of the ( as we call it ) bug fixing process the original software does n't exist in its original form .
It appears to pass most of the test sbut you would not be advised to lean against it or anything because something else might break.software maintenance = / = bug fixing .</tokentext>
<sentencetext>And that means the validation people run through their test book and create maybe 1000 or 2000 bug reports.
These bug reports bounce around through the development teams acquiring cruft along the way.
When the bug eventually stops bouncing somebody might have a go at fixing it.
So they change something and if they can't see the bug anymore they go cvs commit right then and there.
At the same time the other 1999 bugs are bouncing around, looking for a home.At the end of the (as we call it) bug fixing process the original software doesn't exist in its original form.
It appears to pass most of the test sbut you would not be advised to lean against it or anything because something else might break.software maintenance =/= bug fixing.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124978</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125688</id>
	<title>Not only PHB</title>
	<author>omb</author>
	<datestamp>1258391700000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>In the early 70's I had the pleasure of working with both Prof. Tony Brooker and I.R, MacCallum, both of whom had made major contributions to the Atlas timesharing system, Brooker had designed and MacCallum implemented most of the Compiler-Compiler, a meta system that included a parser generator and an MDL with interpreter to walk the parse tree and generate code. I bring these guys up to make a simple point, both were skilled technologists in their own areas, but as many University academics, they were narrow; an could not understand the need for maintenance, incomprehensible looks, the software will ROT<nobr> <wbr></nobr>... etc etc.<br><br>They just could NOT get their minds around changing external circumstances, working in tiny groups, version control, V2... was easy as was getting their all 3 systems updated. Pre/Post/Co - requisites, SCM, package management, bug-tracking were all to come as the world started to really use this stuff and they also had no communication disconnect, because there were less than 1000 and they all knew each other,<br><br>Yes its a HUGE problem, but unfortunately does need real understanding!</htmltext>
<tokenext>In the early 70 's I had the pleasure of working with both Prof. Tony Brooker and I.R , MacCallum , both of whom had made major contributions to the Atlas timesharing system , Brooker had designed and MacCallum implemented most of the Compiler-Compiler , a meta system that included a parser generator and an MDL with interpreter to walk the parse tree and generate code .
I bring these guys up to make a simple point , both were skilled technologists in their own areas , but as many University academics , they were narrow ; an could not understand the need for maintenance , incomprehensible looks , the software will ROT ... etc etc.They just could NOT get their minds around changing external circumstances , working in tiny groups , version control , V2... was easy as was getting their all 3 systems updated .
Pre/Post/Co - requisites , SCM , package management , bug-tracking were all to come as the world started to really use this stuff and they also had no communication disconnect , because there were less than 1000 and they all knew each other,Yes its a HUGE problem , but unfortunately does need real understanding !</tokentext>
<sentencetext>In the early 70's I had the pleasure of working with both Prof. Tony Brooker and I.R, MacCallum, both of whom had made major contributions to the Atlas timesharing system, Brooker had designed and MacCallum implemented most of the Compiler-Compiler, a meta system that included a parser generator and an MDL with interpreter to walk the parse tree and generate code.
I bring these guys up to make a simple point, both were skilled technologists in their own areas, but as many University academics, they were narrow; an could not understand the need for maintenance, incomprehensible looks, the software will ROT ... etc etc.They just could NOT get their minds around changing external circumstances, working in tiny groups, version control, V2... was easy as was getting their all 3 systems updated.
Pre/Post/Co - requisites, SCM, package management, bug-tracking were all to come as the world started to really use this stuff and they also had no communication disconnect, because there were less than 1000 and they all knew each other,Yes its a HUGE problem, but unfortunately does need real understanding!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128856</id>
	<title>"Software Maintenance" - worst metaphor ever</title>
	<author>jc42</author>
	<datestamp>1258473180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The real problem here is the use of an atrociously bad metaphor.  The term "maintenance" refers to keeping something in its original state, so that it continues to perform its original function.  Software never needs this, because software doesn't wear out or degrade. Except for the occasional dropped bit, which usually totally destroys the software so you have to restore it from backup, software stays the same forever, without change.  I have programs that I wrote 25 years ago that still do their original task perfectly, despite constant use.</p><p>The problems is that we're using "maintenance" to mean making changes to the software, to change its behavior so that it can do new things.  Before software, such changes were never called "maintenance".  They was called things like "revisions" or "alterations" or "redesigns", something with a "re-" prefix to remind you that you're changing things.</p><p>To use the usual transport metaphor, it's like you have a very functional road that has long been maintained by fixing the usual cracks, potholes, and other degradation that happens to all roads due to traffic and weather.  Then management comes along, and decides that the road needs to be usable by trains, and this is a simple enough enhancement that the Maintenance Department can do it in a day or so.  The maintenance folks have no experience with railway building, but they dutifully rush out, dig up the road, and install tracks.  They don't have the training or time, so they haven't properly rebuilt the roadbed to support the much heavier traffic, and nobody had told them about the need for a much larger turn radius that trains need than cars do, so trains can hardly use the result.  It takes several weeks, so management criticises them for not adhering to the scheduled two-day delivery time, as well as for building a low-quality railway that constantly needs more "maintenance" work.</p><p>Then, some time later, management decides that the road should also be "slightly augmented" to handle boat traffic.  Never mind that it goes over a hill; that can be handled by building a system of locks.  So the "maintenance" crew sets out to do the job, again without any training in canal building, using tools designed for maintaining auto roadways.  And again, they're criticised for getting behind schedule and doing a poor job.  And the water supply for the lock system is a constant resource hog.</p><p>Of course, with roads, railroads and canals, people can see the physical results.  Even the dumbest manager can see that they're not at all similar (and why you try to avoid building canals over hills).  A problem with software is that it's just bits hidden inside the computer's memory, so it all looks the same from the outside.  This makes it hard to understand the difference between small bug fixes and total redesign and rewrite.  It's all just "maintenance", right?  How hard can it be?  And why are the software maintenance people always so slow and behind schedule?  They can't be very good at their job, right?</p><p>I suppose there's no chance that we can ban the use of the word "maintenance" in software. That would be the best approach.  But it would require admitting that we'd made a major blunder in our terminology.  So we're probably stuck with doing "maintenance" to make major revisions and retargeting of software.</p></htmltext>
<tokenext>The real problem here is the use of an atrociously bad metaphor .
The term " maintenance " refers to keeping something in its original state , so that it continues to perform its original function .
Software never needs this , because software does n't wear out or degrade .
Except for the occasional dropped bit , which usually totally destroys the software so you have to restore it from backup , software stays the same forever , without change .
I have programs that I wrote 25 years ago that still do their original task perfectly , despite constant use.The problems is that we 're using " maintenance " to mean making changes to the software , to change its behavior so that it can do new things .
Before software , such changes were never called " maintenance " .
They was called things like " revisions " or " alterations " or " redesigns " , something with a " re- " prefix to remind you that you 're changing things.To use the usual transport metaphor , it 's like you have a very functional road that has long been maintained by fixing the usual cracks , potholes , and other degradation that happens to all roads due to traffic and weather .
Then management comes along , and decides that the road needs to be usable by trains , and this is a simple enough enhancement that the Maintenance Department can do it in a day or so .
The maintenance folks have no experience with railway building , but they dutifully rush out , dig up the road , and install tracks .
They do n't have the training or time , so they have n't properly rebuilt the roadbed to support the much heavier traffic , and nobody had told them about the need for a much larger turn radius that trains need than cars do , so trains can hardly use the result .
It takes several weeks , so management criticises them for not adhering to the scheduled two-day delivery time , as well as for building a low-quality railway that constantly needs more " maintenance " work.Then , some time later , management decides that the road should also be " slightly augmented " to handle boat traffic .
Never mind that it goes over a hill ; that can be handled by building a system of locks .
So the " maintenance " crew sets out to do the job , again without any training in canal building , using tools designed for maintaining auto roadways .
And again , they 're criticised for getting behind schedule and doing a poor job .
And the water supply for the lock system is a constant resource hog.Of course , with roads , railroads and canals , people can see the physical results .
Even the dumbest manager can see that they 're not at all similar ( and why you try to avoid building canals over hills ) .
A problem with software is that it 's just bits hidden inside the computer 's memory , so it all looks the same from the outside .
This makes it hard to understand the difference between small bug fixes and total redesign and rewrite .
It 's all just " maintenance " , right ?
How hard can it be ?
And why are the software maintenance people always so slow and behind schedule ?
They ca n't be very good at their job , right ? I suppose there 's no chance that we can ban the use of the word " maintenance " in software .
That would be the best approach .
But it would require admitting that we 'd made a major blunder in our terminology .
So we 're probably stuck with doing " maintenance " to make major revisions and retargeting of software .</tokentext>
<sentencetext>The real problem here is the use of an atrociously bad metaphor.
The term "maintenance" refers to keeping something in its original state, so that it continues to perform its original function.
Software never needs this, because software doesn't wear out or degrade.
Except for the occasional dropped bit, which usually totally destroys the software so you have to restore it from backup, software stays the same forever, without change.
I have programs that I wrote 25 years ago that still do their original task perfectly, despite constant use.The problems is that we're using "maintenance" to mean making changes to the software, to change its behavior so that it can do new things.
Before software, such changes were never called "maintenance".
They was called things like "revisions" or "alterations" or "redesigns", something with a "re-" prefix to remind you that you're changing things.To use the usual transport metaphor, it's like you have a very functional road that has long been maintained by fixing the usual cracks, potholes, and other degradation that happens to all roads due to traffic and weather.
Then management comes along, and decides that the road needs to be usable by trains, and this is a simple enough enhancement that the Maintenance Department can do it in a day or so.
The maintenance folks have no experience with railway building, but they dutifully rush out, dig up the road, and install tracks.
They don't have the training or time, so they haven't properly rebuilt the roadbed to support the much heavier traffic, and nobody had told them about the need for a much larger turn radius that trains need than cars do, so trains can hardly use the result.
It takes several weeks, so management criticises them for not adhering to the scheduled two-day delivery time, as well as for building a low-quality railway that constantly needs more "maintenance" work.Then, some time later, management decides that the road should also be "slightly augmented" to handle boat traffic.
Never mind that it goes over a hill; that can be handled by building a system of locks.
So the "maintenance" crew sets out to do the job, again without any training in canal building, using tools designed for maintaining auto roadways.
And again, they're criticised for getting behind schedule and doing a poor job.
And the water supply for the lock system is a constant resource hog.Of course, with roads, railroads and canals, people can see the physical results.
Even the dumbest manager can see that they're not at all similar (and why you try to avoid building canals over hills).
A problem with software is that it's just bits hidden inside the computer's memory, so it all looks the same from the outside.
This makes it hard to understand the difference between small bug fixes and total redesign and rewrite.
It's all just "maintenance", right?
How hard can it be?
And why are the software maintenance people always so slow and behind schedule?
They can't be very good at their job, right?I suppose there's no chance that we can ban the use of the word "maintenance" in software.
That would be the best approach.
But it would require admitting that we'd made a major blunder in our terminology.
So we're probably stuck with doing "maintenance" to make major revisions and retargeting of software.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125202</id>
	<title>That's mighty elitist of you</title>
	<author>Anonymous</author>
	<datestamp>1258386540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p><i>"Software maintenance" has absolutely nothing to do with computer science.</i></p><p>Actually, it does.</p><p>I have a real Computer Science degree, so I know what computer science is about.  And while a lot of corporate programming is more drudgery and form assembly than anything, there are a lot of applications of computer science in the real world - from scalability issues in large systems, to proper use of encryption.</p><p>Furthermore the supposedly boring area of "Software maintenance" has a ton of research potential focused around the optimal path to producing correct code.   Do code review help?  How to team dynamics factor in to code quality?  Does Test First really improve code?  What even defines code quality?  There are programs within companies that experiment with different methods to improve code output, and those experiments are even more valid than ones performed at research institutions since they work on a real-world code base solving a real problem using real people.  In fact I  would go so far as to say and research being conducted outside of a company on aspect of code quality improvement is pretty much worthless, which is why it's important for researchers to partner with real companies for some studies.</p></htmltext>
<tokenext>" Software maintenance " has absolutely nothing to do with computer science.Actually , it does.I have a real Computer Science degree , so I know what computer science is about .
And while a lot of corporate programming is more drudgery and form assembly than anything , there are a lot of applications of computer science in the real world - from scalability issues in large systems , to proper use of encryption.Furthermore the supposedly boring area of " Software maintenance " has a ton of research potential focused around the optimal path to producing correct code .
Do code review help ?
How to team dynamics factor in to code quality ?
Does Test First really improve code ?
What even defines code quality ?
There are programs within companies that experiment with different methods to improve code output , and those experiments are even more valid than ones performed at research institutions since they work on a real-world code base solving a real problem using real people .
In fact I would go so far as to say and research being conducted outside of a company on aspect of code quality improvement is pretty much worthless , which is why it 's important for researchers to partner with real companies for some studies .</tokentext>
<sentencetext>"Software maintenance" has absolutely nothing to do with computer science.Actually, it does.I have a real Computer Science degree, so I know what computer science is about.
And while a lot of corporate programming is more drudgery and form assembly than anything, there are a lot of applications of computer science in the real world - from scalability issues in large systems, to proper use of encryption.Furthermore the supposedly boring area of "Software maintenance" has a ton of research potential focused around the optimal path to producing correct code.
Do code review help?
How to team dynamics factor in to code quality?
Does Test First really improve code?
What even defines code quality?
There are programs within companies that experiment with different methods to improve code output, and those experiments are even more valid than ones performed at research institutions since they work on a real-world code base solving a real problem using real people.
In fact I  would go so far as to say and research being conducted outside of a company on aspect of code quality improvement is pretty much worthless, which is why it's important for researchers to partner with real companies for some studies.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30134672</id>
	<title>Re:That's mighty elitist of you</title>
	<author>mhelander</author>
	<datestamp>1258451820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What if the problem of software mainteinance could be broken down into sub problems, each of which having an algorithmic solution?</p></htmltext>
<tokenext>What if the problem of software mainteinance could be broken down into sub problems , each of which having an algorithmic solution ?</tokentext>
<sentencetext>What if the problem of software mainteinance could be broken down into sub problems, each of which having an algorithmic solution?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30137396</id>
	<title>Re:Good luck</title>
	<author>steveha</author>
	<datestamp>1258462560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>I think Unix got lucky, in that it grew up in a world where computer security was much less of an issue than nowadays.</i></p><p>I disagree completely.</p><p>UNIX was designed as a time-sharing system, with many users sharing the same (very expensive) computer.  Thus, from the first day, it had security designed in.</p><p>Where UNIX got lucky was that its initial deployments were in low-threat environments, where the security didn't really need to be bulletproof.  So, people found security holes and it wasn't a huge deal; the UNIX guys just fixed them.  Bored university student finds a way to gain root on the computer, hole gets patched, continue for a couple of decades.  By the time of the Internet, UNIX was reasonably solid.</p><p>In comparison, Windows was initially designed to own your whole computer; remember that the earliest versions ran on top of DOS!  The design was, just like DOS, that you had full privileges over everything at all times; it was your computer.  And, on top of that, Microsoft added every feature they could think of.  Then, with Windows NT, they started trying to retrofit multi-user security on top of Windows.  By the time of the Internet, Windows was far from secure, and we have been dealing with the consequences ever since.  (Remember how the "WinPopup" service used to be <em>enabled by default</em> and people got spam popped up in their faces?  Oh, boy.)  And there really isn't any good excuse for the way Windows requires you to reboot so often; my Linux systems only require rebooting when I update the kernel.</p><p>Microsoft would have done well to study UNIX and copy it's ideas from day 0.  As Henry Spencer famously observed: "Those who don't understand UNIX are compelled to re-invent it, poorly."</p><p><i>So you don't see a lot of malware targeting Unix, because it isn't such a big target</i></p><p>But Linux is a big target (running lots of web servers) and you still don't see a lot of malware targeting it.  It's much easier to attack Windows, and there are <em>so many</em> Windows machines out there, that most of the effort goes into attacking Windows.  But if Linux was a soft target, crackers (or even automated worms) would be taking down web servers in much greater numbers than we are seeing.</p><p><i>The beauty of the Unix universe is that you can have it your way. You can have a stable system with few bugs and little maintenance, or you can have a cutting edge system with the latest features, at the cost of more bugs and time spent on maintenance.</i></p><p>I agree.</p><p>steveha</p></htmltext>
<tokenext>I think Unix got lucky , in that it grew up in a world where computer security was much less of an issue than nowadays.I disagree completely.UNIX was designed as a time-sharing system , with many users sharing the same ( very expensive ) computer .
Thus , from the first day , it had security designed in.Where UNIX got lucky was that its initial deployments were in low-threat environments , where the security did n't really need to be bulletproof .
So , people found security holes and it was n't a huge deal ; the UNIX guys just fixed them .
Bored university student finds a way to gain root on the computer , hole gets patched , continue for a couple of decades .
By the time of the Internet , UNIX was reasonably solid.In comparison , Windows was initially designed to own your whole computer ; remember that the earliest versions ran on top of DOS !
The design was , just like DOS , that you had full privileges over everything at all times ; it was your computer .
And , on top of that , Microsoft added every feature they could think of .
Then , with Windows NT , they started trying to retrofit multi-user security on top of Windows .
By the time of the Internet , Windows was far from secure , and we have been dealing with the consequences ever since .
( Remember how the " WinPopup " service used to be enabled by default and people got spam popped up in their faces ?
Oh , boy .
) And there really is n't any good excuse for the way Windows requires you to reboot so often ; my Linux systems only require rebooting when I update the kernel.Microsoft would have done well to study UNIX and copy it 's ideas from day 0 .
As Henry Spencer famously observed : " Those who do n't understand UNIX are compelled to re-invent it , poorly .
" So you do n't see a lot of malware targeting Unix , because it is n't such a big targetBut Linux is a big target ( running lots of web servers ) and you still do n't see a lot of malware targeting it .
It 's much easier to attack Windows , and there are so many Windows machines out there , that most of the effort goes into attacking Windows .
But if Linux was a soft target , crackers ( or even automated worms ) would be taking down web servers in much greater numbers than we are seeing.The beauty of the Unix universe is that you can have it your way .
You can have a stable system with few bugs and little maintenance , or you can have a cutting edge system with the latest features , at the cost of more bugs and time spent on maintenance.I agree.steveha</tokentext>
<sentencetext>I think Unix got lucky, in that it grew up in a world where computer security was much less of an issue than nowadays.I disagree completely.UNIX was designed as a time-sharing system, with many users sharing the same (very expensive) computer.
Thus, from the first day, it had security designed in.Where UNIX got lucky was that its initial deployments were in low-threat environments, where the security didn't really need to be bulletproof.
So, people found security holes and it wasn't a huge deal; the UNIX guys just fixed them.
Bored university student finds a way to gain root on the computer, hole gets patched, continue for a couple of decades.
By the time of the Internet, UNIX was reasonably solid.In comparison, Windows was initially designed to own your whole computer; remember that the earliest versions ran on top of DOS!
The design was, just like DOS, that you had full privileges over everything at all times; it was your computer.
And, on top of that, Microsoft added every feature they could think of.
Then, with Windows NT, they started trying to retrofit multi-user security on top of Windows.
By the time of the Internet, Windows was far from secure, and we have been dealing with the consequences ever since.
(Remember how the "WinPopup" service used to be enabled by default and people got spam popped up in their faces?
Oh, boy.
)  And there really isn't any good excuse for the way Windows requires you to reboot so often; my Linux systems only require rebooting when I update the kernel.Microsoft would have done well to study UNIX and copy it's ideas from day 0.
As Henry Spencer famously observed: "Those who don't understand UNIX are compelled to re-invent it, poorly.
"So you don't see a lot of malware targeting Unix, because it isn't such a big targetBut Linux is a big target (running lots of web servers) and you still don't see a lot of malware targeting it.
It's much easier to attack Windows, and there are so many Windows machines out there, that most of the effort goes into attacking Windows.
But if Linux was a soft target, crackers (or even automated worms) would be taking down web servers in much greater numbers than we are seeing.The beauty of the Unix universe is that you can have it your way.
You can have a stable system with few bugs and little maintenance, or you can have a cutting edge system with the latest features, at the cost of more bugs and time spent on maintenance.I agree.steveha</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30129894</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125300</id>
	<title>Cooling Laptop CPU Fans for Acer HP Dell IBM</title>
	<author>keyboard2009</author>
	<datestamp>1258387380000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext>Cooling Laptop CPU Fans for Acer HP Dell IBM

HP Laptop CPU Fans : <a href="http://www.ukeyboard.co.uk/hplaptoppartshplaptopcpufans-c-5\_22.html" title="ukeyboard.co.uk" rel="nofollow">http://www.ukeyboard.co.uk/hplaptoppartshplaptopcpufans-c-5\_22.html</a> [ukeyboard.co.uk]
Acer Laptop CPU Fans: <a href="http://www.ukeyboard.co.uk/acerlaptoppartsacerlaptopcpufans-c-1\_28.html" title="ukeyboard.co.uk" rel="nofollow">http://www.ukeyboard.co.uk/acerlaptoppartsacerlaptopcpufans-c-1\_28.html</a> [ukeyboard.co.uk]
Dell Laptop CPU Fans : <a href="http://www.ukeyboard.co.uk/delllaptoppartsdelllaptopcpufans-c-4\_18.html" title="ukeyboard.co.uk" rel="nofollow">http://www.ukeyboard.co.uk/delllaptoppartsdelllaptopcpufans-c-4\_18.html</a> [ukeyboard.co.uk]
IBM Laptop CPU Fans : <a href="http://www.ukeyboard.co.uk/ibmlaptoppartsibmlaptopcpufans-c-6\_47.html" title="ukeyboard.co.uk" rel="nofollow">http://www.ukeyboard.co.uk/ibmlaptoppartsibmlaptopcpufans-c-6\_47.html</a> [ukeyboard.co.uk]
TOSHIBA Laptop CPU Fans: <a href="http://www.ukeyboard.co.uk/toshibalaptoppartstoshibalaptopcpufans-c-9\_66.html" title="ukeyboard.co.uk" rel="nofollow">http://www.ukeyboard.co.uk/toshibalaptoppartstoshibalaptopcpufans-c-9\_66.html</a> [ukeyboard.co.uk]</htmltext>
<tokenext>Cooling Laptop CPU Fans for Acer HP Dell IBM HP Laptop CPU Fans : http : //www.ukeyboard.co.uk/hplaptoppartshplaptopcpufans-c-5 \ _22.html [ ukeyboard.co.uk ] Acer Laptop CPU Fans : http : //www.ukeyboard.co.uk/acerlaptoppartsacerlaptopcpufans-c-1 \ _28.html [ ukeyboard.co.uk ] Dell Laptop CPU Fans : http : //www.ukeyboard.co.uk/delllaptoppartsdelllaptopcpufans-c-4 \ _18.html [ ukeyboard.co.uk ] IBM Laptop CPU Fans : http : //www.ukeyboard.co.uk/ibmlaptoppartsibmlaptopcpufans-c-6 \ _47.html [ ukeyboard.co.uk ] TOSHIBA Laptop CPU Fans : http : //www.ukeyboard.co.uk/toshibalaptoppartstoshibalaptopcpufans-c-9 \ _66.html [ ukeyboard.co.uk ]</tokentext>
<sentencetext>Cooling Laptop CPU Fans for Acer HP Dell IBM

HP Laptop CPU Fans : http://www.ukeyboard.co.uk/hplaptoppartshplaptopcpufans-c-5\_22.html [ukeyboard.co.uk]
Acer Laptop CPU Fans: http://www.ukeyboard.co.uk/acerlaptoppartsacerlaptopcpufans-c-1\_28.html [ukeyboard.co.uk]
Dell Laptop CPU Fans : http://www.ukeyboard.co.uk/delllaptoppartsdelllaptopcpufans-c-4\_18.html [ukeyboard.co.uk]
IBM Laptop CPU Fans : http://www.ukeyboard.co.uk/ibmlaptoppartsibmlaptopcpufans-c-6\_47.html [ukeyboard.co.uk]
TOSHIBA Laptop CPU Fans: http://www.ukeyboard.co.uk/toshibalaptoppartstoshibalaptopcpufans-c-9\_66.html [ukeyboard.co.uk]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</id>
	<title>Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258384440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>"Software maintenance" has absolutely nothing to do with computer science. I wish people would stop calling business programming computer science. Computer science work gets done at universities and research institutions, not at Initech.</p></htmltext>
<tokenext>" Software maintenance " has absolutely nothing to do with computer science .
I wish people would stop calling business programming computer science .
Computer science work gets done at universities and research institutions , not at Initech .</tokentext>
<sentencetext>"Software maintenance" has absolutely nothing to do with computer science.
I wish people would stop calling business programming computer science.
Computer science work gets done at universities and research institutions, not at Initech.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30130674</id>
	<title>Poor Assumptions</title>
	<author>jasenj1</author>
	<datestamp>1258481220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>FTFA:<p><div class="quote"><p>Traditional (or "everyone's first project"). This one is easy: don't even think about the possibility of maintenance. Hard-code constants, avoid subroutines, use all global variables, use short and non-meaningful variable names. In other words, make it difficult to change any one thing without changing everything.</p></div><p>
Sorry, they already lost me. They start out with the assumption that "traditionally" people write bad code. Sorry, but if you're writing code like this you need to go back to school and learn not to. Then come try to get a programming job again.
</p><p>
To make an opening statement of "your code sucks" turns me right off.
</p><p>
- Jasen.
</p></div>
	</htmltext>
<tokenext>FTFA : Traditional ( or " everyone 's first project " ) .
This one is easy : do n't even think about the possibility of maintenance .
Hard-code constants , avoid subroutines , use all global variables , use short and non-meaningful variable names .
In other words , make it difficult to change any one thing without changing everything .
Sorry , they already lost me .
They start out with the assumption that " traditionally " people write bad code .
Sorry , but if you 're writing code like this you need to go back to school and learn not to .
Then come try to get a programming job again .
To make an opening statement of " your code sucks " turns me right off .
- Jasen .</tokentext>
<sentencetext>FTFA:Traditional (or "everyone's first project").
This one is easy: don't even think about the possibility of maintenance.
Hard-code constants, avoid subroutines, use all global variables, use short and non-meaningful variable names.
In other words, make it difficult to change any one thing without changing everything.
Sorry, they already lost me.
They start out with the assumption that "traditionally" people write bad code.
Sorry, but if you're writing code like this you need to go back to school and learn not to.
Then come try to get a programming job again.
To make an opening statement of "your code sucks" turns me right off.
- Jasen.

	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126826</id>
	<title>Re:Grrr</title>
	<author>NewbieProgrammerMan</author>
	<datestamp>1258449120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Warning: This message may contain cynicism that some people may find offensive.  Viewer discretion is advised.</i> </p><p><div class="quote"><p>But they were so blind to see that the work I did while it was an expense, it saved then millions of dollars in lost productivity, lost CPU time, cost savings in not needing to buy faster processors and more memory as my code ran tight and compact in lower ones, and days if not weeks of downtime and a dysfunctional system and software that takes them years to fix by hiring high priced contractors to do the work I would have done for my small salary.</p></div><p>It seems like it takes an inordinate amount of effort to sell doing maintenance/cleanup to management types, and I don't know enough about psychology or the "business" mindset to understand why that is.   Let us know if you figure out the secret to being a high-priced contractor while still having a conscience and some integrity.  I suspect that the most essential component of success as a high-paid contractor is being able to oversell yourself.  Being able to deliver on any of it is optional.</p><p>(Note: I'm just taking you at your word that you were that valuable...I've seen others (and, at times, I've done it myself) that looked at themselves that way, but couldn't code their way out of a wet paper bag.)</p></div>
	</htmltext>
<tokenext>Warning : This message may contain cynicism that some people may find offensive .
Viewer discretion is advised .
But they were so blind to see that the work I did while it was an expense , it saved then millions of dollars in lost productivity , lost CPU time , cost savings in not needing to buy faster processors and more memory as my code ran tight and compact in lower ones , and days if not weeks of downtime and a dysfunctional system and software that takes them years to fix by hiring high priced contractors to do the work I would have done for my small salary.It seems like it takes an inordinate amount of effort to sell doing maintenance/cleanup to management types , and I do n't know enough about psychology or the " business " mindset to understand why that is .
Let us know if you figure out the secret to being a high-priced contractor while still having a conscience and some integrity .
I suspect that the most essential component of success as a high-paid contractor is being able to oversell yourself .
Being able to deliver on any of it is optional .
( Note : I 'm just taking you at your word that you were that valuable...I 've seen others ( and , at times , I 've done it myself ) that looked at themselves that way , but could n't code their way out of a wet paper bag .
)</tokentext>
<sentencetext>Warning: This message may contain cynicism that some people may find offensive.
Viewer discretion is advised.
But they were so blind to see that the work I did while it was an expense, it saved then millions of dollars in lost productivity, lost CPU time, cost savings in not needing to buy faster processors and more memory as my code ran tight and compact in lower ones, and days if not weeks of downtime and a dysfunctional system and software that takes them years to fix by hiring high priced contractors to do the work I would have done for my small salary.It seems like it takes an inordinate amount of effort to sell doing maintenance/cleanup to management types, and I don't know enough about psychology or the "business" mindset to understand why that is.
Let us know if you figure out the secret to being a high-priced contractor while still having a conscience and some integrity.
I suspect that the most essential component of success as a high-paid contractor is being able to oversell yourself.
Being able to deliver on any of it is optional.
(Note: I'm just taking you at your word that you were that valuable...I've seen others (and, at times, I've done it myself) that looked at themselves that way, but couldn't code their way out of a wet paper bag.
)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127012</id>
	<title>Old stuff? The Rules of Two</title>
	<author>Tim99</author>
	<datestamp>1258452120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Back in the days when RAD and 4GL were new and shiny, I was the second-in-charge of a number of internal scientific/engineering internal software projects for a very large public utility.<br>
We used FORTRAN, C, SQL and BASIC (for serial line stuff). My really bright boss gave us the following two bits of advice:<br> <br>

* Understanding code is at least twice as hard as writing it, so write code at half the level that you are capable of - That way, if someone (possibly you) has to look at a couple of years later, you can probably understand it.<br>
* Mistakes take at least twice the effort to fix, compared with getting it right the first time.<br> <br>
We extended this and documented what we christened the "Rules of Two". We added:<br>
* At least two comment lines for every line of code.<br>
* Under no circumstances have a line of code do two or more things.<br>
* And, my personal favourite, no more than two global variables.<br> <br>
The worrying thing is that this very simplistic regime did produce readable, maintainable code.</htmltext>
<tokenext>Back in the days when RAD and 4GL were new and shiny , I was the second-in-charge of a number of internal scientific/engineering internal software projects for a very large public utility .
We used FORTRAN , C , SQL and BASIC ( for serial line stuff ) .
My really bright boss gave us the following two bits of advice : * Understanding code is at least twice as hard as writing it , so write code at half the level that you are capable of - That way , if someone ( possibly you ) has to look at a couple of years later , you can probably understand it .
* Mistakes take at least twice the effort to fix , compared with getting it right the first time .
We extended this and documented what we christened the " Rules of Two " .
We added : * At least two comment lines for every line of code .
* Under no circumstances have a line of code do two or more things .
* And , my personal favourite , no more than two global variables .
The worrying thing is that this very simplistic regime did produce readable , maintainable code .</tokentext>
<sentencetext>Back in the days when RAD and 4GL were new and shiny, I was the second-in-charge of a number of internal scientific/engineering internal software projects for a very large public utility.
We used FORTRAN, C, SQL and BASIC (for serial line stuff).
My really bright boss gave us the following two bits of advice: 

* Understanding code is at least twice as hard as writing it, so write code at half the level that you are capable of - That way, if someone (possibly you) has to look at a couple of years later, you can probably understand it.
* Mistakes take at least twice the effort to fix, compared with getting it right the first time.
We extended this and documented what we christened the "Rules of Two".
We added:
* At least two comment lines for every line of code.
* Under no circumstances have a line of code do two or more things.
* And, my personal favourite, no more than two global variables.
The worrying thing is that this very simplistic regime did produce readable, maintainable code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125454</id>
	<title>Theory vs practice</title>
	<author>Anonymous</author>
	<datestamp>1258389180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p><i>Doesn't modular programming solve this problem?</i></p><p>That is one of those answers that sound great in theory but in practice suffer from all the same problems from which all the other answers suffer.</p><p>Too much upfront cost is a contract-killer, so compromises in designing for scalability must be made.</p><p>Furthermore, today you have ideas about how the software will be used, and tomorrow those ideas will be changed, and you will discover that the dividing lines you have set up between your modules are not optimally efficient.  This will result in simple-seeming enhancements being prohibitively expensive....unless you start crossing your module boundaries directly.  The pressure to do this is too intense to resist, and you wind up violating the modularity of your design in the name of getting it out the door in time.</p><p>Sooner or later your system will get complaints that it is too slow, and you will need to open further holes through your module boundaries in order to optimize performance within acceptable delivery deadlines.  You will warn that these are quick fixes which must be refactored properly after their release, but the opportunity to do this never comes.</p><p>As such changes form layers around your ever-growing onion, the core modules will be come too precious to change.  Every little tweak you make to a core module will conflict with assumptions made by other modules, and will cause surprising bugs that are hard to detect in QA testing (since test case count grows exponentially with each new feature).  This will result in more demand to fix problems without adjusting the core modules, or by making minimal adjustments to them, which will wind up forcing you to further compromise the modularity of your design.</p><p>As the complexity of your system increases, the cost of each new feature also increases, which will displease management and prompt them to say "we used to be able to do this sort of thing in a few hours...now it takes weeks!"  They will continue to make unreasonable demands of their senior staff until they push said staff right out the door, leaving the ongoing maintenance of this (now very un-)modular system to the junior level programmers who never shared in the original vision of the system, and hence have no sense for where the module boundaries should be, and just fold to managerial pressure to hack in changes as quickly as possible.</p><p>Eventually the slow turnaround times and general bugginess of the system will drive clients to start looking for alternatives.  Some brand-new ones will be available (some of which written by the disgruntled senior staff, in fact).  Thus begins the end of the product, and of the company if this was their flagship.</p></htmltext>
<tokenext>Does n't modular programming solve this problem ? That is one of those answers that sound great in theory but in practice suffer from all the same problems from which all the other answers suffer.Too much upfront cost is a contract-killer , so compromises in designing for scalability must be made.Furthermore , today you have ideas about how the software will be used , and tomorrow those ideas will be changed , and you will discover that the dividing lines you have set up between your modules are not optimally efficient .
This will result in simple-seeming enhancements being prohibitively expensive....unless you start crossing your module boundaries directly .
The pressure to do this is too intense to resist , and you wind up violating the modularity of your design in the name of getting it out the door in time.Sooner or later your system will get complaints that it is too slow , and you will need to open further holes through your module boundaries in order to optimize performance within acceptable delivery deadlines .
You will warn that these are quick fixes which must be refactored properly after their release , but the opportunity to do this never comes.As such changes form layers around your ever-growing onion , the core modules will be come too precious to change .
Every little tweak you make to a core module will conflict with assumptions made by other modules , and will cause surprising bugs that are hard to detect in QA testing ( since test case count grows exponentially with each new feature ) .
This will result in more demand to fix problems without adjusting the core modules , or by making minimal adjustments to them , which will wind up forcing you to further compromise the modularity of your design.As the complexity of your system increases , the cost of each new feature also increases , which will displease management and prompt them to say " we used to be able to do this sort of thing in a few hours...now it takes weeks !
" They will continue to make unreasonable demands of their senior staff until they push said staff right out the door , leaving the ongoing maintenance of this ( now very un- ) modular system to the junior level programmers who never shared in the original vision of the system , and hence have no sense for where the module boundaries should be , and just fold to managerial pressure to hack in changes as quickly as possible.Eventually the slow turnaround times and general bugginess of the system will drive clients to start looking for alternatives .
Some brand-new ones will be available ( some of which written by the disgruntled senior staff , in fact ) .
Thus begins the end of the product , and of the company if this was their flagship .</tokentext>
<sentencetext>Doesn't modular programming solve this problem?That is one of those answers that sound great in theory but in practice suffer from all the same problems from which all the other answers suffer.Too much upfront cost is a contract-killer, so compromises in designing for scalability must be made.Furthermore, today you have ideas about how the software will be used, and tomorrow those ideas will be changed, and you will discover that the dividing lines you have set up between your modules are not optimally efficient.
This will result in simple-seeming enhancements being prohibitively expensive....unless you start crossing your module boundaries directly.
The pressure to do this is too intense to resist, and you wind up violating the modularity of your design in the name of getting it out the door in time.Sooner or later your system will get complaints that it is too slow, and you will need to open further holes through your module boundaries in order to optimize performance within acceptable delivery deadlines.
You will warn that these are quick fixes which must be refactored properly after their release, but the opportunity to do this never comes.As such changes form layers around your ever-growing onion, the core modules will be come too precious to change.
Every little tweak you make to a core module will conflict with assumptions made by other modules, and will cause surprising bugs that are hard to detect in QA testing (since test case count grows exponentially with each new feature).
This will result in more demand to fix problems without adjusting the core modules, or by making minimal adjustments to them, which will wind up forcing you to further compromise the modularity of your design.As the complexity of your system increases, the cost of each new feature also increases, which will displease management and prompt them to say "we used to be able to do this sort of thing in a few hours...now it takes weeks!
"  They will continue to make unreasonable demands of their senior staff until they push said staff right out the door, leaving the ongoing maintenance of this (now very un-)modular system to the junior level programmers who never shared in the original vision of the system, and hence have no sense for where the module boundaries should be, and just fold to managerial pressure to hack in changes as quickly as possible.Eventually the slow turnaround times and general bugginess of the system will drive clients to start looking for alternatives.
Some brand-new ones will be available (some of which written by the disgruntled senior staff, in fact).
Thus begins the end of the product, and of the company if this was their flagship.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124978</id>
	<title>After the software is written it gets maintained</title>
	<author>MichaelSmith</author>
	<datestamp>1258384380000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>And that means the validation people run through their test book and create maybe 1000 or 2000 bug reports. These bug reports bounce around through the development teams acquiring cruft along the way. When the bug eventually stops bouncing somebody might have a go at fixing it. So they change something and if they can't see the bug anymore they go <b>cvs commit</b> right then and there. At the same time the other 1999 bugs are bouncing around, looking for a home.</p><p>At the end of the (as we call it) bug fixing process the original software doesn't exist in its original form. It appears to pass most of the test sbut you would not be advised to lean against it or anything because something else might break.</p></htmltext>
<tokenext>And that means the validation people run through their test book and create maybe 1000 or 2000 bug reports .
These bug reports bounce around through the development teams acquiring cruft along the way .
When the bug eventually stops bouncing somebody might have a go at fixing it .
So they change something and if they ca n't see the bug anymore they go cvs commit right then and there .
At the same time the other 1999 bugs are bouncing around , looking for a home.At the end of the ( as we call it ) bug fixing process the original software does n't exist in its original form .
It appears to pass most of the test sbut you would not be advised to lean against it or anything because something else might break .</tokentext>
<sentencetext>And that means the validation people run through their test book and create maybe 1000 or 2000 bug reports.
These bug reports bounce around through the development teams acquiring cruft along the way.
When the bug eventually stops bouncing somebody might have a go at fixing it.
So they change something and if they can't see the bug anymore they go cvs commit right then and there.
At the same time the other 1999 bugs are bouncing around, looking for a home.At the end of the (as we call it) bug fixing process the original software doesn't exist in its original form.
It appears to pass most of the test sbut you would not be advised to lean against it or anything because something else might break.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127148</id>
	<title>Re:That is not maintenance.</title>
	<author>Aceticon</author>
	<datestamp>1258454580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>I believe that no developer can ever become a good or great developer without having done significant maintenance on someone else's code - your really only learn the true value of "coding for maintainability" (i.e. basics like commenting complex code, avoiding copy and paste, fail-fast code and such) when you're landed with fixing/improving code that was done without any such concerns.</p><p>That said, software maintenance is often a frustrating, painful process in anything but the freshest of code (and sometimes even is code "just out of the over").</p><p>It's especially unpleasant when one is faced with fixing/changing software where some or all of the design or the code were done by (often long gone) less experienced software developers.</p><p>The bad news is that as you become more experienced you see more and more "glaring problems" with the design/coding on any system you have to fix/improve, which can be infuriating at times (for example, when the design and development of an important sub-system was given to a team composed wholly of average/below-average developers with 4 years of less of experience and you are tasked with fixing it)</p><p>The good news is that the outsourcing wave has caused a bubble in IT in India, resulting in loads of people joining IT for the money (most of which should never have done so) so there is a whole lot of really, really bad code out there which will be providing freelancers (like me) with highly-paid maintenance work for years to come.</p></htmltext>
<tokenext>I believe that no developer can ever become a good or great developer without having done significant maintenance on someone else 's code - your really only learn the true value of " coding for maintainability " ( i.e .
basics like commenting complex code , avoiding copy and paste , fail-fast code and such ) when you 're landed with fixing/improving code that was done without any such concerns.That said , software maintenance is often a frustrating , painful process in anything but the freshest of code ( and sometimes even is code " just out of the over " ) .It 's especially unpleasant when one is faced with fixing/changing software where some or all of the design or the code were done by ( often long gone ) less experienced software developers.The bad news is that as you become more experienced you see more and more " glaring problems " with the design/coding on any system you have to fix/improve , which can be infuriating at times ( for example , when the design and development of an important sub-system was given to a team composed wholly of average/below-average developers with 4 years of less of experience and you are tasked with fixing it ) The good news is that the outsourcing wave has caused a bubble in IT in India , resulting in loads of people joining IT for the money ( most of which should never have done so ) so there is a whole lot of really , really bad code out there which will be providing freelancers ( like me ) with highly-paid maintenance work for years to come .</tokentext>
<sentencetext>I believe that no developer can ever become a good or great developer without having done significant maintenance on someone else's code - your really only learn the true value of "coding for maintainability" (i.e.
basics like commenting complex code, avoiding copy and paste, fail-fast code and such) when you're landed with fixing/improving code that was done without any such concerns.That said, software maintenance is often a frustrating, painful process in anything but the freshest of code (and sometimes even is code "just out of the over").It's especially unpleasant when one is faced with fixing/changing software where some or all of the design or the code were done by (often long gone) less experienced software developers.The bad news is that as you become more experienced you see more and more "glaring problems" with the design/coding on any system you have to fix/improve, which can be infuriating at times (for example, when the design and development of an important sub-system was given to a team composed wholly of average/below-average developers with 4 years of less of experience and you are tasked with fixing it)The good news is that the outsourcing wave has caused a bubble in IT in India, resulting in loads of people joining IT for the money (most of which should never have done so) so there is a whole lot of really, really bad code out there which will be providing freelancers (like me) with highly-paid maintenance work for years to come.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125870</id>
	<title>Re:That's mighty elitist of you</title>
	<author>Anonymous</author>
	<datestamp>1258393680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Subfield of Computer Science that are to be excluded by your arbitrary definition:</p><p>Computer graphics, computer vision, operating systems, human-computer interaction, database, networking, natural language processing, artificial intelligence, computer security, computer architecture, and yes, software engineering.</p><p>(You disagree?  Then describe me an algorithmic requirement for realtime 3D rendering, or task scheduling under interactive load.)</p><p><div class="quote"><p>A Turing machine cannot solve the problem of software maintenance.  You cannot model software maintenance as a finite state machine.  There is no algorithmic solution.  There is no space-time trade-off that you can make improve the situation.</p><p>You can say your totally arbitrary definition of computer science excludes SE.  Whatever.  That doesn't change the fact that SE is considered a valid field of computer science and studied throughout computer science departments in the world's universities.</p></div></div>
	</htmltext>
<tokenext>Subfield of Computer Science that are to be excluded by your arbitrary definition : Computer graphics , computer vision , operating systems , human-computer interaction , database , networking , natural language processing , artificial intelligence , computer security , computer architecture , and yes , software engineering .
( You disagree ?
Then describe me an algorithmic requirement for realtime 3D rendering , or task scheduling under interactive load .
) A Turing machine can not solve the problem of software maintenance .
You can not model software maintenance as a finite state machine .
There is no algorithmic solution .
There is no space-time trade-off that you can make improve the situation.You can say your totally arbitrary definition of computer science excludes SE .
Whatever. That does n't change the fact that SE is considered a valid field of computer science and studied throughout computer science departments in the world 's universities .</tokentext>
<sentencetext>Subfield of Computer Science that are to be excluded by your arbitrary definition:Computer graphics, computer vision, operating systems, human-computer interaction, database, networking, natural language processing, artificial intelligence, computer security, computer architecture, and yes, software engineering.
(You disagree?
Then describe me an algorithmic requirement for realtime 3D rendering, or task scheduling under interactive load.
)A Turing machine cannot solve the problem of software maintenance.
You cannot model software maintenance as a finite state machine.
There is no algorithmic solution.
There is no space-time trade-off that you can make improve the situation.You can say your totally arbitrary definition of computer science excludes SE.
Whatever.  That doesn't change the fact that SE is considered a valid field of computer science and studied throughout computer science departments in the world's universities.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30144320</id>
	<title>Re:Different Kinds of Companies</title>
	<author>tehcyder</author>
	<datestamp>1257093960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Is it a surprise that when MS brought programming to the masses that the masses failed to learn engineering?</p></div>
</blockquote><p>
Ah, the return of slashdot sanity...I knew it had to be Microsoft's fault somehow.</p></div>
	</htmltext>
<tokenext>Is it a surprise that when MS brought programming to the masses that the masses failed to learn engineering ?
Ah , the return of slashdot sanity...I knew it had to be Microsoft 's fault somehow .</tokentext>
<sentencetext>Is it a surprise that when MS brought programming to the masses that the masses failed to learn engineering?
Ah, the return of slashdot sanity...I knew it had to be Microsoft's fault somehow.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30139256</id>
	<title>Re:Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258475940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Amen to that. Even in Alan Turing's notion of computing, the computer was a person and not a computer alone. That means that from day one what is exciting about computer science has included the human factor in it. Maintenance is heavy on that part.</p></htmltext>
<tokenext>Amen to that .
Even in Alan Turing 's notion of computing , the computer was a person and not a computer alone .
That means that from day one what is exciting about computer science has included the human factor in it .
Maintenance is heavy on that part .</tokentext>
<sentencetext>Amen to that.
Even in Alan Turing's notion of computing, the computer was a person and not a computer alone.
That means that from day one what is exciting about computer science has included the human factor in it.
Maintenance is heavy on that part.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125574</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125060</id>
	<title>Re:Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258385160000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>How do you design software that is able to be maintained? Many of the techniques for software maintenance are designed by these institutions, so saying "Software Maintenance" is not computer science is a bit far fetched. Writing maintainable software isn't only in the Initech domain.</p><p>And really if you are excluding software maintenance from the field of computer science, you pretty much have to exclude every other software technique. Techniques for writing maintainable code go hand in hand with every other development technique.</p></htmltext>
<tokenext>How do you design software that is able to be maintained ?
Many of the techniques for software maintenance are designed by these institutions , so saying " Software Maintenance " is not computer science is a bit far fetched .
Writing maintainable software is n't only in the Initech domain.And really if you are excluding software maintenance from the field of computer science , you pretty much have to exclude every other software technique .
Techniques for writing maintainable code go hand in hand with every other development technique .</tokentext>
<sentencetext>How do you design software that is able to be maintained?
Many of the techniques for software maintenance are designed by these institutions, so saying "Software Maintenance" is not computer science is a bit far fetched.
Writing maintainable software isn't only in the Initech domain.And really if you are excluding software maintenance from the field of computer science, you pretty much have to exclude every other software technique.
Techniques for writing maintainable code go hand in hand with every other development technique.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125532</id>
	<title>Delete the word 'software' from TFA title</title>
	<author>riprjak</author>
	<datestamp>1258390020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>and the sentiment is no less true.</p><p>My observation is that we shaven monkeys that make up the human race are fundamentally incapable of maintenance in any sense.   Rather than maintain something in as-new functional condition (maintenance) so it does not fail, we choose to either fix it (fixenance) or replace it (buyenance) when it does.</p><p>A factory that makes plastic widgets is just as likely to make these same mistakes in relation to their machinery.</p><p>Just my $0.02<br>err!<br>jak.</p></htmltext>
<tokenext>and the sentiment is no less true.My observation is that we shaven monkeys that make up the human race are fundamentally incapable of maintenance in any sense .
Rather than maintain something in as-new functional condition ( maintenance ) so it does not fail , we choose to either fix it ( fixenance ) or replace it ( buyenance ) when it does.A factory that makes plastic widgets is just as likely to make these same mistakes in relation to their machinery.Just my $ 0.02err ! jak .</tokentext>
<sentencetext>and the sentiment is no less true.My observation is that we shaven monkeys that make up the human race are fundamentally incapable of maintenance in any sense.
Rather than maintain something in as-new functional condition (maintenance) so it does not fail, we choose to either fix it (fixenance) or replace it (buyenance) when it does.A factory that makes plastic widgets is just as likely to make these same mistakes in relation to their machinery.Just my $0.02err!jak.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125210</id>
	<title>Numeric function calls</title>
	<author>argent</author>
	<datestamp>1258386600000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p>FreeBSD 1 and FreeBSD 2 had slightly different semantics for some system calls, but FreeBSD 2 changed the system call numbers, so it was possible to modify the FreeBSD 1.1.5.1 kernel to run the binary Netscape for FreeBSD 2.x by implementing the new API for one call in the old kernel. Alas, I can't find the patch now, which is embarrassing because I was the one hosting it... about 15 years ago.</p></htmltext>
<tokenext>FreeBSD 1 and FreeBSD 2 had slightly different semantics for some system calls , but FreeBSD 2 changed the system call numbers , so it was possible to modify the FreeBSD 1.1.5.1 kernel to run the binary Netscape for FreeBSD 2.x by implementing the new API for one call in the old kernel .
Alas , I ca n't find the patch now , which is embarrassing because I was the one hosting it... about 15 years ago .</tokentext>
<sentencetext>FreeBSD 1 and FreeBSD 2 had slightly different semantics for some system calls, but FreeBSD 2 changed the system call numbers, so it was possible to modify the FreeBSD 1.1.5.1 kernel to run the binary Netscape for FreeBSD 2.x by implementing the new API for one call in the old kernel.
Alas, I can't find the patch now, which is embarrassing because I was the one hosting it... about 15 years ago.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126158</id>
	<title>Re:That's mighty elitist of you</title>
	<author>tolkienfan</author>
	<datestamp>1258397040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Computer Science is not limited to things that can execute inside a turing machine. A large body of computer science is made up of correctness proofs - which, strangely, weren't written by programs running on a universal turing machine, for one example...<br>What is and what is not in the realm of Computer Science is not defined by what can run inside a turning machine.<br>I also doubt that the turing machine will be the end of Computer Science.</p></htmltext>
<tokenext>Computer Science is not limited to things that can execute inside a turing machine .
A large body of computer science is made up of correctness proofs - which , strangely , were n't written by programs running on a universal turing machine , for one example...What is and what is not in the realm of Computer Science is not defined by what can run inside a turning machine.I also doubt that the turing machine will be the end of Computer Science .</tokentext>
<sentencetext>Computer Science is not limited to things that can execute inside a turing machine.
A large body of computer science is made up of correctness proofs - which, strangely, weren't written by programs running on a universal turing machine, for one example...What is and what is not in the realm of Computer Science is not defined by what can run inside a turning machine.I also doubt that the turing machine will be the end of Computer Science.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125182</id>
	<title>Re:Grrr</title>
	<author>Anonymous</author>
	<datestamp>1258386360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Computer science "work".</p></htmltext>
<tokenext>Computer science " work " .</tokentext>
<sentencetext>Computer science "work".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125374</id>
	<title>Re:Grrr</title>
	<author>SparafucileMan</author>
	<datestamp>1258388100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Don't kid yourself, genius.</p><p>Efficient software maintenance is directly related to the Halting Problem. I'm sure you could figure out a thesis about it. Or at least a proof.</p><p>Besides, "business programming" involves many things, some of which includes problems (for example, my field, aerospace) that are ridiculously complex, certainly at least as much as a good 80\% of any CS degree or thesis.</p></htmltext>
<tokenext>Do n't kid yourself , genius.Efficient software maintenance is directly related to the Halting Problem .
I 'm sure you could figure out a thesis about it .
Or at least a proof.Besides , " business programming " involves many things , some of which includes problems ( for example , my field , aerospace ) that are ridiculously complex , certainly at least as much as a good 80 \ % of any CS degree or thesis .</tokentext>
<sentencetext>Don't kid yourself, genius.Efficient software maintenance is directly related to the Halting Problem.
I'm sure you could figure out a thesis about it.
Or at least a proof.Besides, "business programming" involves many things, some of which includes problems (for example, my field, aerospace) that are ridiculously complex, certainly at least as much as a good 80\% of any CS degree or thesis.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125762</id>
	<title>Re:Wait a second...</title>
	<author>jaxtherat</author>
	<datestamp>1258392660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Have a look at the code for the source engine. The code for this allegedly awesome engine if full of spaghetti and brain fail.</htmltext>
<tokenext>Have a look at the code for the source engine .
The code for this allegedly awesome engine if full of spaghetti and brain fail .</tokentext>
<sentencetext>Have a look at the code for the source engine.
The code for this allegedly awesome engine if full of spaghetti and brain fail.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126068</id>
	<title>Re:Different Kinds of Companies</title>
	<author>Anonymous</author>
	<datestamp>1258395840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>You probably didn't mean it, but this is the kind of egoistic baiting that drives me nuts. Software is a tool. If it is cost effective it is used. Otherwise it is not. Last I checked, this is still somewhat a free economy. If software quality was the be-all and end-all, then we'd have higher quality software. As it stands, the majority of code is pretty bad, but generally performs the intended function. Companies realized a long time ago that it 100\% perfect "engineered" software is freaking expensive. Because those experienced systems engineers are freaking expensive (and in limited supply). Imagine how *little* software would be created if only the top performers were allowed to create it.</p></htmltext>
<tokenext>You probably did n't mean it , but this is the kind of egoistic baiting that drives me nuts .
Software is a tool .
If it is cost effective it is used .
Otherwise it is not .
Last I checked , this is still somewhat a free economy .
If software quality was the be-all and end-all , then we 'd have higher quality software .
As it stands , the majority of code is pretty bad , but generally performs the intended function .
Companies realized a long time ago that it 100 \ % perfect " engineered " software is freaking expensive .
Because those experienced systems engineers are freaking expensive ( and in limited supply ) .
Imagine how * little * software would be created if only the top performers were allowed to create it .</tokentext>
<sentencetext>You probably didn't mean it, but this is the kind of egoistic baiting that drives me nuts.
Software is a tool.
If it is cost effective it is used.
Otherwise it is not.
Last I checked, this is still somewhat a free economy.
If software quality was the be-all and end-all, then we'd have higher quality software.
As it stands, the majority of code is pretty bad, but generally performs the intended function.
Companies realized a long time ago that it 100\% perfect "engineered" software is freaking expensive.
Because those experienced systems engineers are freaking expensive (and in limited supply).
Imagine how *little* software would be created if only the top performers were allowed to create it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126134</id>
	<title>Re:Grrr</title>
	<author>SpaceLifeForm</author>
	<datestamp>1258396620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You got it dude.</p><p>The problem is management is flat out fucking stupid<br>and only worried about their stock options.</p><p>Fucking stock options have screwed everything up for<br>over 20 years now.</p><p>The dumb ass pointy hairs can not recognize a<br>good programmer because they are push-button.</p><p>Worthless.</p><p>Proper software development is properly done correctly<br>up front, with *PLANS* for maintenance.</p></htmltext>
<tokenext>You got it dude.The problem is management is flat out fucking stupidand only worried about their stock options.Fucking stock options have screwed everything up forover 20 years now.The dumb ass pointy hairs can not recognize agood programmer because they are push-button.Worthless.Proper software development is properly done correctlyup front , with * PLANS * for maintenance .</tokentext>
<sentencetext>You got it dude.The problem is management is flat out fucking stupidand only worried about their stock options.Fucking stock options have screwed everything up forover 20 years now.The dumb ass pointy hairs can not recognize agood programmer because they are push-button.Worthless.Proper software development is properly done correctlyup front, with *PLANS* for maintenance.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128208
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125424
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127426
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30139404
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128538
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125418
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125060
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126068
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128314
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125386
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125812
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125288
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127550
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124978
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125688
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30144320
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30139280
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125454
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127176
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30137396
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30129894
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125208
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125492
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125212
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125060
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30133996
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125532
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30136118
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127528
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125306
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125970
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125766
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125182
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30134672
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126826
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128578
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126792
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125266
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30132308
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127506
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125336
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126158
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126026
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125100
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30132916
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125842
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30139256
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125574
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125498
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125870
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125202
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126082
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126134
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127452
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127148
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125768
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125374
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30131090
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126954
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125404
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_17_005210_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128554
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125098
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125768
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125306
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125386
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125404
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125266
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125492
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125208
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30129894
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30137396
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124980
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125762
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125454
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30139280
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127426
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125424
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128208
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125842
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30132916
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127012
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124990
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128314
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126082
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125232
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127148
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128578
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128554
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126954
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30131090
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125288
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125812
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125688
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127908
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127528
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125506
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125336
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127506
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126334
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124978
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127550
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125300
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125372
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125408
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126068
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30144320
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125970
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126026
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125532
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30133996
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_17_005210.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30124984
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125498
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125374
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125252
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30136118
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30139404
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126134
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126826
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127452
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125574
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30132308
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30139256
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125182
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125202
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125614
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126158
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125766
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125870
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30126792
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30134672
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30127176
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125060
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125418
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30128538
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125212
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_17_005210.30125100
</commentlist>
</conversation>
