<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_06_06_0210229</id>
	<title>How Software Engineering Differs From Computer Science</title>
	<author>Soulskill</author>
	<datestamp>1244311500000</datestamp>
	<htmltext><a href="http://www.chc-3.com/" rel="nofollow">cconnell</a> sends in a piece he wrote for Dr. Dobb's which "argues that software development will <a href="http://www.ddj.com/architect/217701907">never be a fully formal, rigorous discipline</a>, and the reason is that software engineering involves humans as central to the process." Quoting:
<i>"Software maintainability, for example, is the ability of people to understand, find, and repair defects in a software system. The maintainability of software may be influenced by some formal notions of computer science &mdash; perhaps the cyclomatic complexity of the software's control graph. But maintainability crucially involves humans, and their ability to grasp the meaning and intention of source code. The question of whether a particular software system is highly maintainable cannot be answered just by mechanically examining the software. The same is true for safety. Researchers have used some formal methods to learn about a software system's impact on people's health and property. But no discussion of software safety is complete without appeal to the human component of the system under examination."</i></htmltext>
<tokenext>cconnell sends in a piece he wrote for Dr. Dobb 's which " argues that software development will never be a fully formal , rigorous discipline , and the reason is that software engineering involves humans as central to the process .
" Quoting : " Software maintainability , for example , is the ability of people to understand , find , and repair defects in a software system .
The maintainability of software may be influenced by some formal notions of computer science    perhaps the cyclomatic complexity of the software 's control graph .
But maintainability crucially involves humans , and their ability to grasp the meaning and intention of source code .
The question of whether a particular software system is highly maintainable can not be answered just by mechanically examining the software .
The same is true for safety .
Researchers have used some formal methods to learn about a software system 's impact on people 's health and property .
But no discussion of software safety is complete without appeal to the human component of the system under examination .
"</tokentext>
<sentencetext>cconnell sends in a piece he wrote for Dr. Dobb's which "argues that software development will never be a fully formal, rigorous discipline, and the reason is that software engineering involves humans as central to the process.
" Quoting:
"Software maintainability, for example, is the ability of people to understand, find, and repair defects in a software system.
The maintainability of software may be influenced by some formal notions of computer science — perhaps the cyclomatic complexity of the software's control graph.
But maintainability crucially involves humans, and their ability to grasp the meaning and intention of source code.
The question of whether a particular software system is highly maintainable cannot be answered just by mechanically examining the software.
The same is true for safety.
Researchers have used some formal methods to learn about a software system's impact on people's health and property.
But no discussion of software safety is complete without appeal to the human component of the system under examination.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230767</id>
	<title>Re:Software Engineering is trying</title>
	<author>Anonymous</author>
	<datestamp>1244319000000</datestamp>
	<modclass>Troll</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>.. to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be. Writing software is a creative process, arguably even an artistic one. Well understood rules can be followed,  provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.<br>Computer Science compared to Software Engineering?<br>Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.<br>Engineering aeronautics is all about building the damn aircraft.</p></div><p> <a href="http://blog.soufun.com/blogweb/blog\_manage/gratulate.aspx/userid=23799432" title="soufun.com" rel="nofollow">http://blog.soufun.com/blogweb/blog\_manage/gratulate.aspx/userid=23799432</a> [soufun.com]<br><a href="http://my.home.news.cn/blog/control/home.do" title="home.news.cn" rel="nofollow">http://my.home.news.cn/blog/control/home.do</a> [home.news.cn]<br><a href="http://home.myspace.cn/index.cfm?fuseaction=user" title="myspace.cn" rel="nofollow">http://home.myspace.cn/index.cfm?fuseaction=user</a> [myspace.cn]<br><a href="http://my.51.com/webim/index.php" title="51.com" rel="nofollow">http://my.51.com/webim/index.php</a> [51.com]<br><a href="http://10553007.blog.hexun.com/32715836\_d.html" title="hexun.com" rel="nofollow">http://10553007.blog.hexun.com/32715836\_d.html</a> [hexun.com]<br><a href="http://sys2.blogcn.com/control/article.do?method=list" title="blogcn.com" rel="nofollow">http://sys2.blogcn.com/control/article.do?method=list</a> [blogcn.com]<br><a href="http://blog.chinamil.com.cn/user\_index.asp" title="chinamil.com.cn" rel="nofollow">http://blog.chinamil.com.cn/user\_index.asp</a> [chinamil.com.cn]<br><a href="http://blog.sanfo.com/user\_index.asp" title="sanfo.com" rel="nofollow">http://blog.sanfo.com/user\_index.asp</a> [sanfo.com]<br><a href="http://blog.titan24.com/blog.php?uid=414198" title="titan24.com" rel="nofollow">http://blog.titan24.com/blog.php?uid=414198</a> [titan24.com]<br><a href="http://liulangqiuxie.blog.china.com/index.html" title="china.com" rel="nofollow">http://liulangqiuxie.blog.china.com/index.html</a> [china.com]<br><a href="http://blog.zjol.com.cn/spacecp.php?docp=me" title="zjol.com.cn" rel="nofollow">http://blog.zjol.com.cn/spacecp.php?docp=me</a> [zjol.com.cn]<br><a href="http://www.blogbus.com/user/?blogid=4969180&amp;mm=Post&amp;page=&amp;sortid=" title="blogbus.com" rel="nofollow">http://www.blogbus.com/user/?blogid=4969180&amp;mm=Post&amp;page=&amp;sortid=</a> [blogbus.com]<br><a href="http://www.mastv.cc/mastvblog/user\_index.asp" title="mastv.cc" rel="nofollow">http://www.mastv.cc/mastvblog/user\_index.asp</a> [mastv.cc]<br><a href="http://blog.sina.com.cn/u/1192639293" title="sina.com.cn" rel="nofollow">http://blog.sina.com.cn/u/1192639293</a> [sina.com.cn]<br><a href="http://blogs.albawaba.com/admin.php" title="albawaba.com" rel="nofollow">http://blogs.albawaba.com/admin.php</a> [albawaba.com]<br><a href="http://blog.ycool.com/index.php" title="ycool.com" rel="nofollow">http://blog.ycool.com/index.php</a> [ycool.com]<br><a href="http://home.q.yesky.com/space-4194762.html" title="yesky.com" rel="nofollow">http://home.q.yesky.com/space-4194762.html</a> [yesky.com]<br><a href="http://blogs.66law.cn/users/liulangqiuxie/" title="66law.cn" rel="nofollow">http://blogs.66law.cn/users/liulangqiuxie/</a> [66law.cn]<br><a href="http://blog.aweb.com.cn/user/manage/articles.jsp" title="aweb.com.cn" rel="nofollow">http://blog.aweb.com.cn/user/manage/articles.jsp</a> [aweb.com.cn]</p></div>
	</htmltext>
<tokenext>.. to become a rigorous engineering discipline .
It 's not quite there yet .
I am not convinced that it ever will be .
Writing software is a creative process , arguably even an artistic one .
Well understood rules can be followed , provably correct algorithms applied , formal design methods used , but it is still a human creative process , and as such , I suspect inherently non-rigorous.Computer Science compared to Software Engineering ? Think aeronautics .
The science of aeronautics ponders the laws of aerodynamics and the laws of flight.Engineering aeronautics is all about building the damn aircraft .
http : //blog.soufun.com/blogweb/blog \ _manage/gratulate.aspx/userid = 23799432 [ soufun.com ] http : //my.home.news.cn/blog/control/home.do [ home.news.cn ] http : //home.myspace.cn/index.cfm ? fuseaction = user [ myspace.cn ] http : //my.51.com/webim/index.php [ 51.com ] http : //10553007.blog.hexun.com/32715836 \ _d.html [ hexun.com ] http : //sys2.blogcn.com/control/article.do ? method = list [ blogcn.com ] http : //blog.chinamil.com.cn/user \ _index.asp [ chinamil.com.cn ] http : //blog.sanfo.com/user \ _index.asp [ sanfo.com ] http : //blog.titan24.com/blog.php ? uid = 414198 [ titan24.com ] http : //liulangqiuxie.blog.china.com/index.html [ china.com ] http : //blog.zjol.com.cn/spacecp.php ? docp = me [ zjol.com.cn ] http : //www.blogbus.com/user/ ? blogid = 4969180&amp;mm = Post&amp;page = &amp;sortid = [ blogbus.com ] http : //www.mastv.cc/mastvblog/user \ _index.asp [ mastv.cc ] http : //blog.sina.com.cn/u/1192639293 [ sina.com.cn ] http : //blogs.albawaba.com/admin.php [ albawaba.com ] http : //blog.ycool.com/index.php [ ycool.com ] http : //home.q.yesky.com/space-4194762.html [ yesky.com ] http : //blogs.66law.cn/users/liulangqiuxie/ [ 66law.cn ] http : //blog.aweb.com.cn/user/manage/articles.jsp [ aweb.com.cn ]</tokentext>
<sentencetext>.. to become a rigorous engineering discipline.
It's not quite there yet.
I am not convinced that it ever will be.
Writing software is a creative process, arguably even an artistic one.
Well understood rules can be followed,  provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.Computer Science compared to Software Engineering?Think aeronautics.
The science of aeronautics ponders the laws of aerodynamics and the laws of flight.Engineering aeronautics is all about building the damn aircraft.
http://blog.soufun.com/blogweb/blog\_manage/gratulate.aspx/userid=23799432 [soufun.com]http://my.home.news.cn/blog/control/home.do [home.news.cn]http://home.myspace.cn/index.cfm?fuseaction=user [myspace.cn]http://my.51.com/webim/index.php [51.com]http://10553007.blog.hexun.com/32715836\_d.html [hexun.com]http://sys2.blogcn.com/control/article.do?method=list [blogcn.com]http://blog.chinamil.com.cn/user\_index.asp [chinamil.com.cn]http://blog.sanfo.com/user\_index.asp [sanfo.com]http://blog.titan24.com/blog.php?uid=414198 [titan24.com]http://liulangqiuxie.blog.china.com/index.html [china.com]http://blog.zjol.com.cn/spacecp.php?docp=me [zjol.com.cn]http://www.blogbus.com/user/?blogid=4969180&amp;mm=Post&amp;page=&amp;sortid= [blogbus.com]http://www.mastv.cc/mastvblog/user\_index.asp [mastv.cc]http://blog.sina.com.cn/u/1192639293 [sina.com.cn]http://blogs.albawaba.com/admin.php [albawaba.com]http://blog.ycool.com/index.php [ycool.com]http://home.q.yesky.com/space-4194762.html [yesky.com]http://blogs.66law.cn/users/liulangqiuxie/ [66law.cn]http://blog.aweb.com.cn/user/manage/articles.jsp [aweb.com.cn]
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232419</id>
	<title>Re:Before we get all sweaty about terms</title>
	<author>russotto</author>
	<datestamp>1244299800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>If you can be counted on to design a system that reliably works without killing people, you're an engineer.</p></div></blockquote><p>That's only half of it.  You need to design it so when used within specs it reliably works, but when used outside specs (by some margin X) it fails.  As the saying goes, any fool can build a bridge that will stand, but it takes an engineer to build one which will just barely stand.</p></div>
	</htmltext>
<tokenext>If you can be counted on to design a system that reliably works without killing people , you 're an engineer.That 's only half of it .
You need to design it so when used within specs it reliably works , but when used outside specs ( by some margin X ) it fails .
As the saying goes , any fool can build a bridge that will stand , but it takes an engineer to build one which will just barely stand .</tokentext>
<sentencetext>If you can be counted on to design a system that reliably works without killing people, you're an engineer.That's only half of it.
You need to design it so when used within specs it reliably works, but when used outside specs (by some margin X) it fails.
As the saying goes, any fool can build a bridge that will stand, but it takes an engineer to build one which will just barely stand.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231135</id>
	<title>Memory or IQ</title>
	<author>Anonymous</author>
	<datestamp>1244281620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The old argument of knowledge vs inteligence !</p><p>Knowledge = the ability to REMEMBER answers to standard questions to pass exams.</p><p>Inteligence = the ability to understand and solve problems and be able to find answers ( e.g. IQ)</p><p>The 2 have no direct link - I would rather a person has the latter than the former but that's rare with societys obsession with memory based qualifications</p></htmltext>
<tokenext>The old argument of knowledge vs inteligence ! Knowledge = the ability to REMEMBER answers to standard questions to pass exams.Inteligence = the ability to understand and solve problems and be able to find answers ( e.g .
IQ ) The 2 have no direct link - I would rather a person has the latter than the former but that 's rare with societys obsession with memory based qualifications</tokentext>
<sentencetext>The old argument of knowledge vs inteligence !Knowledge = the ability to REMEMBER answers to standard questions to pass exams.Inteligence = the ability to understand and solve problems and be able to find answers ( e.g.
IQ)The 2 have no direct link - I would rather a person has the latter than the former but that's rare with societys obsession with memory based qualifications</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231415</id>
	<title>Re:First!</title>
	<author>RDW</author>
	<datestamp>1244286360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>'Wouldn't it still be as much a science as say... human psychology?'</p><p>Pretty much:</p><p>'...and this area is maddeningly slippery. No concept is precisely defined. Results are qualified with "usually" or "in general". Today's research may, or may not, help tomorrow's work. New approaches often overturn earlier methods, with the new approaches burning brightly for a while and then falling out of fashion as their limitations emerge.'</p></htmltext>
<tokenext>'Would n't it still be as much a science as say... human psychology ?
'Pretty much : '...and this area is maddeningly slippery .
No concept is precisely defined .
Results are qualified with " usually " or " in general " .
Today 's research may , or may not , help tomorrow 's work .
New approaches often overturn earlier methods , with the new approaches burning brightly for a while and then falling out of fashion as their limitations emerge .
'</tokentext>
<sentencetext>'Wouldn't it still be as much a science as say... human psychology?
'Pretty much:'...and this area is maddeningly slippery.
No concept is precisely defined.
Results are qualified with "usually" or "in general".
Today's research may, or may not, help tomorrow's work.
New approaches often overturn earlier methods, with the new approaches burning brightly for a while and then falling out of fashion as their limitations emerge.
'</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230519</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230943</id>
	<title>The difference between Engineering and Development</title>
	<author>Chris Snook</author>
	<datestamp>1244278980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>...is about a 1000x difference in cost per line of code.  There's a lot of pure software engineering going on out there, but the products are relatively few (and usually heavily re-used) because the cost of being reasonably certain no one will die is really quite astronomical.  Most people who call themselves software engineers with a straight face are really doing something in between, which is why we have entire libraries full of books describing methods that trade off varying degrees of safety for economy.</p><p>In one sense, software engineering can be considered a more formal discipline than other forms of engineering, because software engineering has studied in much greater depth the tradeoffs between formality and economy, since the spread between them is so much wider.</p></htmltext>
<tokenext>...is about a 1000x difference in cost per line of code .
There 's a lot of pure software engineering going on out there , but the products are relatively few ( and usually heavily re-used ) because the cost of being reasonably certain no one will die is really quite astronomical .
Most people who call themselves software engineers with a straight face are really doing something in between , which is why we have entire libraries full of books describing methods that trade off varying degrees of safety for economy.In one sense , software engineering can be considered a more formal discipline than other forms of engineering , because software engineering has studied in much greater depth the tradeoffs between formality and economy , since the spread between them is so much wider .</tokentext>
<sentencetext>...is about a 1000x difference in cost per line of code.
There's a lot of pure software engineering going on out there, but the products are relatively few (and usually heavily re-used) because the cost of being reasonably certain no one will die is really quite astronomical.
Most people who call themselves software engineers with a straight face are really doing something in between, which is why we have entire libraries full of books describing methods that trade off varying degrees of safety for economy.In one sense, software engineering can be considered a more formal discipline than other forms of engineering, because software engineering has studied in much greater depth the tradeoffs between formality and economy, since the spread between them is so much wider.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232221</id>
	<title>Re:Software Development is actually an art</title>
	<author>rbrightwell</author>
	<datestamp>1244298240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I agree.  Here is a math example. It is like bad, ugly, non-artistic code but it works. It makes some people impressed with the creator due to apparent complexity. They must be a GENIUS!
<br> <br>
(4-1)/(SQRT(9)) + (28-(3^3))=2
<br> <br>
Good code can be beautifuly in its brevity and symetry. Makes the unintiated say, "duh!"
<br> <br>
1+1=2</htmltext>
<tokenext>I agree .
Here is a math example .
It is like bad , ugly , non-artistic code but it works .
It makes some people impressed with the creator due to apparent complexity .
They must be a GENIUS !
( 4-1 ) / ( SQRT ( 9 ) ) + ( 28- ( 3 ^ 3 ) ) = 2 Good code can be beautifuly in its brevity and symetry .
Makes the unintiated say , " duh !
" 1 + 1 = 2</tokentext>
<sentencetext>I agree.
Here is a math example.
It is like bad, ugly, non-artistic code but it works.
It makes some people impressed with the creator due to apparent complexity.
They must be a GENIUS!
(4-1)/(SQRT(9)) + (28-(3^3))=2
 
Good code can be beautifuly in its brevity and symetry.
Makes the unintiated say, "duh!
"
 
1+1=2</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747</id>
	<title>Software Development is actually an art</title>
	<author>bill\_kress</author>
	<datestamp>1244318700000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>So, I'm sure, are a lot of things I don't recognize, like designing a sky-scraper or space shuttle.</p><p>Programming is an art, Anyone can follow instructions and follow an existing style or try to paint a realistic scene, but to come up with a skilled interpretation that really conveys a meaning takes a better painter.  To bring together 20 painters, outline a collaboration and manage the production of some giant, detailed interpretation takes a master--at this point natural talent starts to mean more than training, and no level of training can improve someone without talent.</p><p>Anyone can write a small program.  You can fit 20 generic programmers in a room and have them each write a small program.  You might even be able to get them to join the programs somewhat-properly, but the whole thing will never go smoothly.</p><p>One or two really good programmers will probably out-produce 20 people that "know how to program".</p><p>How many amateur painters do you need to create something like the sistine chapel?</p><p>Just because most people can't see the art that allows large programs to work doesn't mean it's not there.  In fact, most people can't tell any type of good art from bad without some training.</p></htmltext>
<tokenext>So , I 'm sure , are a lot of things I do n't recognize , like designing a sky-scraper or space shuttle.Programming is an art , Anyone can follow instructions and follow an existing style or try to paint a realistic scene , but to come up with a skilled interpretation that really conveys a meaning takes a better painter .
To bring together 20 painters , outline a collaboration and manage the production of some giant , detailed interpretation takes a master--at this point natural talent starts to mean more than training , and no level of training can improve someone without talent.Anyone can write a small program .
You can fit 20 generic programmers in a room and have them each write a small program .
You might even be able to get them to join the programs somewhat-properly , but the whole thing will never go smoothly.One or two really good programmers will probably out-produce 20 people that " know how to program " .How many amateur painters do you need to create something like the sistine chapel ? Just because most people ca n't see the art that allows large programs to work does n't mean it 's not there .
In fact , most people ca n't tell any type of good art from bad without some training .</tokentext>
<sentencetext>So, I'm sure, are a lot of things I don't recognize, like designing a sky-scraper or space shuttle.Programming is an art, Anyone can follow instructions and follow an existing style or try to paint a realistic scene, but to come up with a skilled interpretation that really conveys a meaning takes a better painter.
To bring together 20 painters, outline a collaboration and manage the production of some giant, detailed interpretation takes a master--at this point natural talent starts to mean more than training, and no level of training can improve someone without talent.Anyone can write a small program.
You can fit 20 generic programmers in a room and have them each write a small program.
You might even be able to get them to join the programs somewhat-properly, but the whole thing will never go smoothly.One or two really good programmers will probably out-produce 20 people that "know how to program".How many amateur painters do you need to create something like the sistine chapel?Just because most people can't see the art that allows large programs to work doesn't mean it's not there.
In fact, most people can't tell any type of good art from bad without some training.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233203</id>
	<title>Re:Not engineering, but it SHOULD be</title>
	<author>turbidostato</author>
	<datestamp>1244304780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Cheaper, faster, easier is the motto of most programs written today.</p><p>It's the motto for bridges or highways too, so your point was, again?</p></htmltext>
<tokenext>Cheaper , faster , easier is the motto of most programs written today.It 's the motto for bridges or highways too , so your point was , again ?</tokentext>
<sentencetext>Cheaper, faster, easier is the motto of most programs written today.It's the motto for bridges or highways too, so your point was, again?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232283</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230691</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>dov\_0</author>
	<datestamp>1244231580000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>Soft skill? Depends how well it's done. Lets use car repairs as an example. There are many times I've known or heard tell of where well trained city mechanics throw up their hands in defeat before the car is taken to either a 'mate who knows something about cars' or a 'bush mechanic' and fixed in 15 minutes. Ie. Sometimes the ability to observe, sort information well and problem solve is worth a lot more than a piece of paper with 'engineer' written on it.</p><p>Another example. I run a computer repair business with a 'no fix, no fee' policy. Even though I've never had a single day of formal training in the field, I have never, ever had to bring that policy into action. Meanwhile it's surprising how often my mates who have done IT or computer science ask me for help on something because they just don't know how to THINK.</p></htmltext>
<tokenext>Soft skill ?
Depends how well it 's done .
Lets use car repairs as an example .
There are many times I 've known or heard tell of where well trained city mechanics throw up their hands in defeat before the car is taken to either a 'mate who knows something about cars ' or a 'bush mechanic ' and fixed in 15 minutes .
Ie. Sometimes the ability to observe , sort information well and problem solve is worth a lot more than a piece of paper with 'engineer ' written on it.Another example .
I run a computer repair business with a 'no fix , no fee ' policy .
Even though I 've never had a single day of formal training in the field , I have never , ever had to bring that policy into action .
Meanwhile it 's surprising how often my mates who have done IT or computer science ask me for help on something because they just do n't know how to THINK .</tokentext>
<sentencetext>Soft skill?
Depends how well it's done.
Lets use car repairs as an example.
There are many times I've known or heard tell of where well trained city mechanics throw up their hands in defeat before the car is taken to either a 'mate who knows something about cars' or a 'bush mechanic' and fixed in 15 minutes.
Ie. Sometimes the ability to observe, sort information well and problem solve is worth a lot more than a piece of paper with 'engineer' written on it.Another example.
I run a computer repair business with a 'no fix, no fee' policy.
Even though I've never had a single day of formal training in the field, I have never, ever had to bring that policy into action.
Meanwhile it's surprising how often my mates who have done IT or computer science ask me for help on something because they just don't know how to THINK.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232145</id>
	<title>Misleading Title</title>
	<author>prefec2</author>
	<datestamp>1244297520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Software engineering is a part of computer science. Everyone who thinks computer science is only formal methods is totally wrong. Its like saying theoretical physics is physics but experimental physics is something else than physics. Computer science has a core based on formal methods. This core comprises logic, turing machines, grammars, L-systems, petri nets, my-recursion all the other thinky stuff. Most of that stuff was borrowed from other disciplines. Languages were borrowed from Noam Chomsky and the linguists, the Turing machine was developmed by A. turing a mathematician, L-Systems comes from biology, logic from philosophy.</p><p>Around this nice set of formal methods, we computer scientists developed different ways to use them to solve real world problems. our job is to develop tools and methods to process data and information. We do this with formal methods. However, to find out what the information is and what we shall do with it, we have to ask the user. This is requirement engineering. therefore we make interviews, give out questionnaires and read literature of other disciplines. So interview techniques, questionnaires, and text analysis become part of our discipline's tool-set as well.</p><p>And the development of software is a complex process. Therefore we thought it might be helpful to use the shoes we made for other for ourselves. This is also part of software engineering. And therefore it is part of computer science.</p></htmltext>
<tokenext>Software engineering is a part of computer science .
Everyone who thinks computer science is only formal methods is totally wrong .
Its like saying theoretical physics is physics but experimental physics is something else than physics .
Computer science has a core based on formal methods .
This core comprises logic , turing machines , grammars , L-systems , petri nets , my-recursion all the other thinky stuff .
Most of that stuff was borrowed from other disciplines .
Languages were borrowed from Noam Chomsky and the linguists , the Turing machine was developmed by A. turing a mathematician , L-Systems comes from biology , logic from philosophy.Around this nice set of formal methods , we computer scientists developed different ways to use them to solve real world problems .
our job is to develop tools and methods to process data and information .
We do this with formal methods .
However , to find out what the information is and what we shall do with it , we have to ask the user .
This is requirement engineering .
therefore we make interviews , give out questionnaires and read literature of other disciplines .
So interview techniques , questionnaires , and text analysis become part of our discipline 's tool-set as well.And the development of software is a complex process .
Therefore we thought it might be helpful to use the shoes we made for other for ourselves .
This is also part of software engineering .
And therefore it is part of computer science .</tokentext>
<sentencetext>Software engineering is a part of computer science.
Everyone who thinks computer science is only formal methods is totally wrong.
Its like saying theoretical physics is physics but experimental physics is something else than physics.
Computer science has a core based on formal methods.
This core comprises logic, turing machines, grammars, L-systems, petri nets, my-recursion all the other thinky stuff.
Most of that stuff was borrowed from other disciplines.
Languages were borrowed from Noam Chomsky and the linguists, the Turing machine was developmed by A. turing a mathematician, L-Systems comes from biology, logic from philosophy.Around this nice set of formal methods, we computer scientists developed different ways to use them to solve real world problems.
our job is to develop tools and methods to process data and information.
We do this with formal methods.
However, to find out what the information is and what we shall do with it, we have to ask the user.
This is requirement engineering.
therefore we make interviews, give out questionnaires and read literature of other disciplines.
So interview techniques, questionnaires, and text analysis become part of our discipline's tool-set as well.And the development of software is a complex process.
Therefore we thought it might be helpful to use the shoes we made for other for ourselves.
This is also part of software engineering.
And therefore it is part of computer science.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231913</id>
	<title>Software engineers can get jobs</title>
	<author>petes\_PoV</author>
	<datestamp>1244294820000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Whereas computer scientists go into research or teaching - to produce more computer scientists.</htmltext>
<tokenext>Whereas computer scientists go into research or teaching - to produce more computer scientists .</tokentext>
<sentencetext>Whereas computer scientists go into research or teaching - to produce more computer scientists.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523</id>
	<title>Perspective?</title>
	<author>dov\_0</author>
	<datestamp>1244229000000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>How about a rigorous, ever changing, ever intriguing discipline? It already is and will be more so.</htmltext>
<tokenext>How about a rigorous , ever changing , ever intriguing discipline ?
It already is and will be more so .</tokentext>
<sentencetext>How about a rigorous, ever changing, ever intriguing discipline?
It already is and will be more so.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230723</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244318400000</datestamp>
	<modclass>None</modclass>
	<modscore>2</modscore>
	<htmltext>How much of software writing is software engineering. To deserve the name engineering
take a problem that has to deeply analysised calculating a method of solution, programming
is sometimes like that. But often i find i can start programming the solution straight away
with just a bit of thinking about the class/object structure of the eventual program. When its
like that is more like authoring a book, then engineering a machine.</htmltext>
<tokenext>How much of software writing is software engineering .
To deserve the name engineering take a problem that has to deeply analysised calculating a method of solution , programming is sometimes like that .
But often i find i can start programming the solution straight away with just a bit of thinking about the class/object structure of the eventual program .
When its like that is more like authoring a book , then engineering a machine .</tokentext>
<sentencetext>How much of software writing is software engineering.
To deserve the name engineering
take a problem that has to deeply analysised calculating a method of solution, programming
is sometimes like that.
But often i find i can start programming the solution straight away
with just a bit of thinking about the class/object structure of the eventual program.
When its
like that is more like authoring a book, then engineering a machine.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232339</id>
	<title>Re:You're not Engineers. Get over it.</title>
	<author>Anonymous</author>
	<datestamp>1244299200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That's funny, as a software engineer that works at a classic engineering firm I can't say I've ever been laughed at. On the contrary, the fact I have to learn their trade as well as mine to be able to implement systems to help automate solving of some of the problems they face I've managed to gain quite a lot of respect.</p><p>It's not like engineering is an inherently harder discipline or anything so I've no idea why engineers would ever laugh at them anymore than a physicist would laugh at an engineer or a mathematician would laugh at a physicist.</p><p>I've been able to modernise many of the methods the engineers at our firm use to solve problems in fact because they've been doing things the way they've always done things and yet there are better ways of doing them using math and computing. The problem with the way they've always done it is there are margins of error and when those margins of error can cost us contracts over our competitors who in some cases manage to offer a solution with a smaller margin of error my solutions have won the company millions in contracts we'd have otherwise lost.</p><p>Perhaps some better advice for you would be that engineers aren't anything special, get over it.</p></htmltext>
<tokenext>That 's funny , as a software engineer that works at a classic engineering firm I ca n't say I 've ever been laughed at .
On the contrary , the fact I have to learn their trade as well as mine to be able to implement systems to help automate solving of some of the problems they face I 've managed to gain quite a lot of respect.It 's not like engineering is an inherently harder discipline or anything so I 've no idea why engineers would ever laugh at them anymore than a physicist would laugh at an engineer or a mathematician would laugh at a physicist.I 've been able to modernise many of the methods the engineers at our firm use to solve problems in fact because they 've been doing things the way they 've always done things and yet there are better ways of doing them using math and computing .
The problem with the way they 've always done it is there are margins of error and when those margins of error can cost us contracts over our competitors who in some cases manage to offer a solution with a smaller margin of error my solutions have won the company millions in contracts we 'd have otherwise lost.Perhaps some better advice for you would be that engineers are n't anything special , get over it .</tokentext>
<sentencetext>That's funny, as a software engineer that works at a classic engineering firm I can't say I've ever been laughed at.
On the contrary, the fact I have to learn their trade as well as mine to be able to implement systems to help automate solving of some of the problems they face I've managed to gain quite a lot of respect.It's not like engineering is an inherently harder discipline or anything so I've no idea why engineers would ever laugh at them anymore than a physicist would laugh at an engineer or a mathematician would laugh at a physicist.I've been able to modernise many of the methods the engineers at our firm use to solve problems in fact because they've been doing things the way they've always done things and yet there are better ways of doing them using math and computing.
The problem with the way they've always done it is there are margins of error and when those margins of error can cost us contracts over our competitors who in some cases manage to offer a solution with a smaller margin of error my solutions have won the company millions in contracts we'd have otherwise lost.Perhaps some better advice for you would be that engineers aren't anything special, get over it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230659</id>
	<title>Chuck Connel does not understand Simon's work</title>
	<author>tyrr</author>
	<datestamp>1244231040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>The author of the article should study a Noble prize-winning work <a href="http://www.amazon.com/Administrative-Behavior-4th-Herbert-Simon/dp/0684835827" title="amazon.com">"Administrative Behavior"</a> [amazon.com].
<br> <br>
There is nothing secret about human cognition. The fact that software engineering relies on human resources and not on binary logic is in no way a limitation. Many modern algorithms rely on heavily on probability and work with uncertainty. <a href="http://en.wikipedia.org/wiki/Herbert\_A.\_Simon" title="wikipedia.org">Herbert A. Simon</a> [wikipedia.org] built a solid framework for understanding human decision making process. This framework is just as solid as mathematical formulas behind computer science.</htmltext>
<tokenext>The author of the article should study a Noble prize-winning work " Administrative Behavior " [ amazon.com ] .
There is nothing secret about human cognition .
The fact that software engineering relies on human resources and not on binary logic is in no way a limitation .
Many modern algorithms rely on heavily on probability and work with uncertainty .
Herbert A. Simon [ wikipedia.org ] built a solid framework for understanding human decision making process .
This framework is just as solid as mathematical formulas behind computer science .</tokentext>
<sentencetext>The author of the article should study a Noble prize-winning work "Administrative Behavior" [amazon.com].
There is nothing secret about human cognition.
The fact that software engineering relies on human resources and not on binary logic is in no way a limitation.
Many modern algorithms rely on heavily on probability and work with uncertainty.
Herbert A. Simon [wikipedia.org] built a solid framework for understanding human decision making process.
This framework is just as solid as mathematical formulas behind computer science.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28237941</id>
	<title>No formal methods indeed</title>
	<author>Anonymous</author>
	<datestamp>1244296560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>certainly explains Slashdot's screwy CSS layout<br><tt><br>-1 Truth too Painful<br></tt></p></htmltext>
<tokenext>certainly explains Slashdot 's screwy CSS layout-1 Truth too Painful</tokentext>
<sentencetext>certainly explains Slashdot's screwy CSS layout-1 Truth too Painful</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233933</id>
	<title>Re:Professional Engineer</title>
	<author>dodobh</author>
	<datestamp>1244309220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My software will work, with specific hardware, within certain hard tolerances. It will not work on a generic PC, or if you change anything, or do not follow instructions in the manual.</p></htmltext>
<tokenext>My software will work , with specific hardware , within certain hard tolerances .
It will not work on a generic PC , or if you change anything , or do not follow instructions in the manual .</tokentext>
<sentencetext>My software will work, with specific hardware, within certain hard tolerances.
It will not work on a generic PC, or if you change anything, or do not follow instructions in the manual.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232177</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231475</id>
	<title>Re:Software Engineering is trying</title>
	<author>Anonymous</author>
	<datestamp>1244287500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Software engineering is trying to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be."</p><p>I'm certain that it is, the problem is not software developers, the problem is the complexity and cost of engineering.  I'm sure given an infinite budget and the right people software development would become software engineering, the problem really is that:</p><p>1) No one wants to pay the true cost<br>2) Technology changes too fast and Ccrtain technologies go obsolete very quickly</p><p>The real problem with most software development ("engineerng") is time and budget, not the fact that it's impossible to engineer great software, just that the costs to do a good job as project complexity increases, increases enormously.</p></htmltext>
<tokenext>" Software engineering is trying to become a rigorous engineering discipline .
It 's not quite there yet .
I am not convinced that it ever will be .
" I 'm certain that it is , the problem is not software developers , the problem is the complexity and cost of engineering .
I 'm sure given an infinite budget and the right people software development would become software engineering , the problem really is that : 1 ) No one wants to pay the true cost2 ) Technology changes too fast and Ccrtain technologies go obsolete very quicklyThe real problem with most software development ( " engineerng " ) is time and budget , not the fact that it 's impossible to engineer great software , just that the costs to do a good job as project complexity increases , increases enormously .</tokentext>
<sentencetext>"Software engineering is trying to become a rigorous engineering discipline.
It's not quite there yet.
I am not convinced that it ever will be.
"I'm certain that it is, the problem is not software developers, the problem is the complexity and cost of engineering.
I'm sure given an infinite budget and the right people software development would become software engineering, the problem really is that:1) No one wants to pay the true cost2) Technology changes too fast and Ccrtain technologies go obsolete very quicklyThe real problem with most software development ("engineerng") is time and budget, not the fact that it's impossible to engineer great software, just that the costs to do a good job as project complexity increases, increases enormously.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230811</id>
	<title>Re:You're not Engineers. Get over it.</title>
	<author>ufoolme</author>
	<datestamp>1244319720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Master of Engineering (Magister in Ingeniaria), often abbreviated M.Eng.
<a href="http://en.wikipedia.org/wiki/Master\_of\_Engineering" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/Master\_of\_Engineering</a> [wikipedia.org]</htmltext>
<tokenext>Master of Engineering ( Magister in Ingeniaria ) , often abbreviated M.Eng .
http : //en.wikipedia.org/wiki/Master \ _of \ _Engineering [ wikipedia.org ]</tokentext>
<sentencetext>Master of Engineering (Magister in Ingeniaria), often abbreviated M.Eng.
http://en.wikipedia.org/wiki/Master\_of\_Engineering [wikipedia.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230655</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231157</id>
	<title>Multidisciplined</title>
	<author>sesteel</author>
	<datestamp>1244281920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I personally like the term software developer; though, my company formally calls me a software engineer.  I am reading these comments about defining software engineering/development and it is obvious that it is difficult to quantify this discipline in terms of any other discipline.  Software development is an inherently unique endeavor that requires I wide range of abilities and ways of thinking to solve difficult problems.  Sometimes it requires rigor and a deep understanding of mathematical concepts.  At other times it requires artistry and extreme creativity.  And yet at other times it truly feels like working the line in a factory.  It is beautiful in its exactness, many times revealing unexpected consequences.    The latest US financial crisis has been contributed to unexpected consequences relating to software written in the 80's and 90's.  At its core, however, is the goal of automation and thus freedom.  We automate so we are free to perform other, hopefully, more desirable tasks.  In order to accomplish this, software developers must learn about processes, machines, relationships between abstract concepts, communication, etc, etc, etc.  Most importantly, however, we get to learn about people, learn about ourselves, and in the process learn about new things to automate</htmltext>
<tokenext>I personally like the term software developer ; though , my company formally calls me a software engineer .
I am reading these comments about defining software engineering/development and it is obvious that it is difficult to quantify this discipline in terms of any other discipline .
Software development is an inherently unique endeavor that requires I wide range of abilities and ways of thinking to solve difficult problems .
Sometimes it requires rigor and a deep understanding of mathematical concepts .
At other times it requires artistry and extreme creativity .
And yet at other times it truly feels like working the line in a factory .
It is beautiful in its exactness , many times revealing unexpected consequences .
The latest US financial crisis has been contributed to unexpected consequences relating to software written in the 80 's and 90 's .
At its core , however , is the goal of automation and thus freedom .
We automate so we are free to perform other , hopefully , more desirable tasks .
In order to accomplish this , software developers must learn about processes , machines , relationships between abstract concepts , communication , etc , etc , etc .
Most importantly , however , we get to learn about people , learn about ourselves , and in the process learn about new things to automate</tokentext>
<sentencetext>I personally like the term software developer; though, my company formally calls me a software engineer.
I am reading these comments about defining software engineering/development and it is obvious that it is difficult to quantify this discipline in terms of any other discipline.
Software development is an inherently unique endeavor that requires I wide range of abilities and ways of thinking to solve difficult problems.
Sometimes it requires rigor and a deep understanding of mathematical concepts.
At other times it requires artistry and extreme creativity.
And yet at other times it truly feels like working the line in a factory.
It is beautiful in its exactness, many times revealing unexpected consequences.
The latest US financial crisis has been contributed to unexpected consequences relating to software written in the 80's and 90's.
At its core, however, is the goal of automation and thus freedom.
We automate so we are free to perform other, hopefully, more desirable tasks.
In order to accomplish this, software developers must learn about processes, machines, relationships between abstract concepts, communication, etc, etc, etc.
Most importantly, however, we get to learn about people, learn about ourselves, and in the process learn about new things to automate</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231219</id>
	<title>Software Development is a CRAFT</title>
	<author>Anonymous</author>
	<datestamp>1244282760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Let's face it. Most (if not all) programs we write are "made-to-measure" software, not mass production programs. You need craftsmen for that. Artists are usually only interested in the looks.</p><p>Software development is a skill that can only be trained. Trained to think like a hacker, to think like a newbie user, tothink like a client (client!=user), to know when to optimize and especially when NOT to optimize, trained to think in modules and their relations (I encountered far too many programmers who have difficulties with this). Trained to think in responsibilities. Trained to abstract. Trained to trust the unit tests. Trained to write them.</p><p>A good programmer is a craftsman. Someone who can build the wish of a client not exactly as the client has sketched it, but as a robust and working structure that does what the client wants.</p><p>An artist is someone who designs the famous "Z" chair and dares not sit on it.</p><p>A craftsman is someone who takes the idea of the "Z" chair and dimensions it right so it becomes a chair instead of an idea.</p></htmltext>
<tokenext>Let 's face it .
Most ( if not all ) programs we write are " made-to-measure " software , not mass production programs .
You need craftsmen for that .
Artists are usually only interested in the looks.Software development is a skill that can only be trained .
Trained to think like a hacker , to think like a newbie user , tothink like a client ( client ! = user ) , to know when to optimize and especially when NOT to optimize , trained to think in modules and their relations ( I encountered far too many programmers who have difficulties with this ) .
Trained to think in responsibilities .
Trained to abstract .
Trained to trust the unit tests .
Trained to write them.A good programmer is a craftsman .
Someone who can build the wish of a client not exactly as the client has sketched it , but as a robust and working structure that does what the client wants.An artist is someone who designs the famous " Z " chair and dares not sit on it.A craftsman is someone who takes the idea of the " Z " chair and dimensions it right so it becomes a chair instead of an idea .</tokentext>
<sentencetext>Let's face it.
Most (if not all) programs we write are "made-to-measure" software, not mass production programs.
You need craftsmen for that.
Artists are usually only interested in the looks.Software development is a skill that can only be trained.
Trained to think like a hacker, to think like a newbie user, tothink like a client (client!=user), to know when to optimize and especially when NOT to optimize, trained to think in modules and their relations (I encountered far too many programmers who have difficulties with this).
Trained to think in responsibilities.
Trained to abstract.
Trained to trust the unit tests.
Trained to write them.A good programmer is a craftsman.
Someone who can build the wish of a client not exactly as the client has sketched it, but as a robust and working structure that does what the client wants.An artist is someone who designs the famous "Z" chair and dares not sit on it.A craftsman is someone who takes the idea of the "Z" chair and dimensions it right so it becomes a chair instead of an idea.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230765</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244319000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I absolutely agree: "real" engineering involves people and unpredictable/artistic/intuitive decision making processes as well (the difference is that designing code is almost ENTIRELY unpredictable). Perhaps other trained engineers in the software industry share my frustration with the general reluctance to apply ANY formal rigour to the process, using arguments like the one in this article as the general excuse?</p></htmltext>
<tokenext>I absolutely agree : " real " engineering involves people and unpredictable/artistic/intuitive decision making processes as well ( the difference is that designing code is almost ENTIRELY unpredictable ) .
Perhaps other trained engineers in the software industry share my frustration with the general reluctance to apply ANY formal rigour to the process , using arguments like the one in this article as the general excuse ?</tokentext>
<sentencetext>I absolutely agree: "real" engineering involves people and unpredictable/artistic/intuitive decision making processes as well (the difference is that designing code is almost ENTIRELY unpredictable).
Perhaps other trained engineers in the software industry share my frustration with the general reluctance to apply ANY formal rigour to the process, using arguments like the one in this article as the general excuse?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232177</id>
	<title>Professional Engineer</title>
	<author>non-registered</author>
	<datestamp>1244297760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>As a degreed engineer with 30 years of work in computer hardware and software, I firmly believe there will be no such thing as a "Software Engineer" until such engineer has a "PE" after his/her name. That's "Professional Engineer" (wiki it); a responsible party who can be put in jail if the software kills someone. There's nothing like the threat of punishment to put rigor in your processes.</htmltext>
<tokenext>As a degreed engineer with 30 years of work in computer hardware and software , I firmly believe there will be no such thing as a " Software Engineer " until such engineer has a " PE " after his/her name .
That 's " Professional Engineer " ( wiki it ) ; a responsible party who can be put in jail if the software kills someone .
There 's nothing like the threat of punishment to put rigor in your processes .</tokentext>
<sentencetext>As a degreed engineer with 30 years of work in computer hardware and software, I firmly believe there will be no such thing as a "Software Engineer" until such engineer has a "PE" after his/her name.
That's "Professional Engineer" (wiki it); a responsible party who can be put in jail if the software kills someone.
There's nothing like the threat of punishment to put rigor in your processes.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230965</id>
	<title>ognaa</title>
	<author>Anonymous</author>
	<datestamp>1244279220000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><A HREF="http://goat.cx/" title="goat.cx" rel="nofollow">very 5ick and its</a> [goat.cx]</htmltext>
<tokenext>very 5ick and its [ goat.cx ]</tokentext>
<sentencetext>very 5ick and its [goat.cx]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231133</id>
	<title>Re:Before we get all sweaty about terms</title>
	<author>torako</author>
	<datestamp>1244281620000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p><nobr> <wbr></nobr></p><div class="quote"><p>...
</p><p>If you can observe phenomena, reliably document previously unobserved phenomena, and from that produce useful but not mathematically precise practices or products you're a scientist.
</p><p>If you can gather observed facts into a sheaf of postulates and a system of symbols that can predict unobserved phenomena, you're a mathematician....</p></div><p>Both describe a (natural) scientist. Mathematicians do entirely different things (they don't work with observed facts, they don't make postulates based on said facts, they definitely don't predict unobserved phenomena. That's all what science is for).</p></div>
	</htmltext>
<tokenext>.. . If you can observe phenomena , reliably document previously unobserved phenomena , and from that produce useful but not mathematically precise practices or products you 're a scientist .
If you can gather observed facts into a sheaf of postulates and a system of symbols that can predict unobserved phenomena , you 're a mathematician....Both describe a ( natural ) scientist .
Mathematicians do entirely different things ( they do n't work with observed facts , they do n't make postulates based on said facts , they definitely do n't predict unobserved phenomena .
That 's all what science is for ) .</tokentext>
<sentencetext> ...
If you can observe phenomena, reliably document previously unobserved phenomena, and from that produce useful but not mathematically precise practices or products you're a scientist.
If you can gather observed facts into a sheaf of postulates and a system of symbols that can predict unobserved phenomena, you're a mathematician....Both describe a (natural) scientist.
Mathematicians do entirely different things (they don't work with observed facts, they don't make postulates based on said facts, they definitely don't predict unobserved phenomena.
That's all what science is for).
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231179</id>
	<title>Re:Perspective?</title>
	<author>pallmall1</author>
	<datestamp>1244282220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Software Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be.</p></div></blockquote><p>
After watching the ISO debacle approving microsoft's OOXML, I must agree with you.</p></div>
	</htmltext>
<tokenext>Software Engineering is trying to become a rigorous engineering discipline .
It 's not quite there yet .
I am not convinced that it ever will be .
After watching the ISO debacle approving microsoft 's OOXML , I must agree with you .</tokentext>
<sentencetext>Software Engineering is trying to become a rigorous engineering discipline.
It's not quite there yet.
I am not convinced that it ever will be.
After watching the ISO debacle approving microsoft's OOXML, I must agree with you.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233049</id>
	<title>PE certification for Software Engineering</title>
	<author>WWE-TicK</author>
	<datestamp>1244304060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I believe some places up in Canada are now doing PE certifications for Software Engineering as well.  Last time I researched this, I believe Texas was going to do the same thing for some reason failed.  But PE certs for SE will be coming in not too distant future.  Will that finally shut up the "software engineers are not real engineers" crowd?  Probably not.  I find the kind of people who even make such complaints are usually "paper engineers" anyway and haven't done any actual real work "in the field" and their entire self esteem is built on having a degree that says "engineer" on it.  IMHO, just because your degree says "engineer" on it doesn't make you a "real" engineer either.  After working in the field for about 7 years, with many different kinds of engineers, I have to say I've met quite a few "paper engineers" during that time.</htmltext>
<tokenext>I believe some places up in Canada are now doing PE certifications for Software Engineering as well .
Last time I researched this , I believe Texas was going to do the same thing for some reason failed .
But PE certs for SE will be coming in not too distant future .
Will that finally shut up the " software engineers are not real engineers " crowd ?
Probably not .
I find the kind of people who even make such complaints are usually " paper engineers " anyway and have n't done any actual real work " in the field " and their entire self esteem is built on having a degree that says " engineer " on it .
IMHO , just because your degree says " engineer " on it does n't make you a " real " engineer either .
After working in the field for about 7 years , with many different kinds of engineers , I have to say I 've met quite a few " paper engineers " during that time .</tokentext>
<sentencetext>I believe some places up in Canada are now doing PE certifications for Software Engineering as well.
Last time I researched this, I believe Texas was going to do the same thing for some reason failed.
But PE certs for SE will be coming in not too distant future.
Will that finally shut up the "software engineers are not real engineers" crowd?
Probably not.
I find the kind of people who even make such complaints are usually "paper engineers" anyway and haven't done any actual real work "in the field" and their entire self esteem is built on having a degree that says "engineer" on it.
IMHO, just because your degree says "engineer" on it doesn't make you a "real" engineer either.
After working in the field for about 7 years, with many different kinds of engineers, I have to say I've met quite a few "paper engineers" during that time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231269</id>
	<title>Re:Before we get all sweaty about terms</title>
	<author>TheLink</author>
	<datestamp>1244283660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It's not that hard to design a system that doesn't kill people. I can't recall the last time my DHCP server killed someone, even though I've killed it so many times.<br><br>In fact I'd say it's hard to design an autonomous system that can keep killing people despite everyone else trying to stop it.<br><br>Y'know like one of those killer robots from the future.</htmltext>
<tokenext>It 's not that hard to design a system that does n't kill people .
I ca n't recall the last time my DHCP server killed someone , even though I 've killed it so many times.In fact I 'd say it 's hard to design an autonomous system that can keep killing people despite everyone else trying to stop it.Y'know like one of those killer robots from the future .</tokentext>
<sentencetext>It's not that hard to design a system that doesn't kill people.
I can't recall the last time my DHCP server killed someone, even though I've killed it so many times.In fact I'd say it's hard to design an autonomous system that can keep killing people despite everyone else trying to stop it.Y'know like one of those killer robots from the future.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231759</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Naerymdan</author>
	<datestamp>1244292420000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>On of the reason I love Quebec (in Canada):
<p>
Engineer is a reserved title, which makes it illegal for people not part of the "Ordre des ingenieurs du Quebec" to call themselves engineers.
</p><p>
You should have seen a couple years ago with the MCSE (Microsoft Certified Systems Engineer) certification... Hahahaha!
</p><p>
Here:<br>
<a href="http://www.microsoft.com/canada/learning/QuebecMCSE/default.mspx" title="microsoft.com" rel="nofollow">http://www.microsoft.com/canada/learning/QuebecMCSE/default.mspx</a> [microsoft.com]
</p><p>
ps.: To be part of the Order in Quebec, you need a 4-year (would be 5-years in USA) university degree in engineering.</p></htmltext>
<tokenext>On of the reason I love Quebec ( in Canada ) : Engineer is a reserved title , which makes it illegal for people not part of the " Ordre des ingenieurs du Quebec " to call themselves engineers .
You should have seen a couple years ago with the MCSE ( Microsoft Certified Systems Engineer ) certification... Hahahaha ! Here : http : //www.microsoft.com/canada/learning/QuebecMCSE/default.mspx [ microsoft.com ] ps .
: To be part of the Order in Quebec , you need a 4-year ( would be 5-years in USA ) university degree in engineering .</tokentext>
<sentencetext>On of the reason I love Quebec (in Canada):

Engineer is a reserved title, which makes it illegal for people not part of the "Ordre des ingenieurs du Quebec" to call themselves engineers.
You should have seen a couple years ago with the MCSE (Microsoft Certified Systems Engineer) certification... Hahahaha!

Here:
http://www.microsoft.com/canada/learning/QuebecMCSE/default.mspx [microsoft.com]

ps.
: To be part of the Order in Quebec, you need a 4-year (would be 5-years in USA) university degree in engineering.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230613</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236139</id>
	<title>Re:Professional Engineer</title>
	<author>Anonymous</author>
	<datestamp>1244280780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>In most states it's illegal to offer one's services to the public as a "software engineer" without a PE. (AFAIK, Texas is the only state that actually allows individuals to be specifically licensed as software engineers.) The last time I checked, there was disagreement between the IEEE and ACM about whether there should even be licensing of software engineers. (The IEEE was for licensing; the ACM against.) Personally, I think "software engineering" is not yet mature enough to claim to be an engineering discipline. (And I'm not even completely sure that engineering is the right model for software development.) I'd like to see the term "software engineer" discarded.</p></htmltext>
<tokenext>In most states it 's illegal to offer one 's services to the public as a " software engineer " without a PE .
( AFAIK , Texas is the only state that actually allows individuals to be specifically licensed as software engineers .
) The last time I checked , there was disagreement between the IEEE and ACM about whether there should even be licensing of software engineers .
( The IEEE was for licensing ; the ACM against .
) Personally , I think " software engineering " is not yet mature enough to claim to be an engineering discipline .
( And I 'm not even completely sure that engineering is the right model for software development .
) I 'd like to see the term " software engineer " discarded .</tokentext>
<sentencetext>In most states it's illegal to offer one's services to the public as a "software engineer" without a PE.
(AFAIK, Texas is the only state that actually allows individuals to be specifically licensed as software engineers.
) The last time I checked, there was disagreement between the IEEE and ACM about whether there should even be licensing of software engineers.
(The IEEE was for licensing; the ACM against.
) Personally, I think "software engineering" is not yet mature enough to claim to be an engineering discipline.
(And I'm not even completely sure that engineering is the right model for software development.
) I'd like to see the term "software engineer" discarded.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232177</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28256645</id>
	<title>Re:Software Engineering is trying</title>
	<author>DigitalCrackPipe</author>
	<datestamp>1244455740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I can't agree that software engineering is inherently non-rigorous.  It's just still too new, and the rigor isn't enforced.  We've been building bridges for thousands of years, but software for less than a century.  Most management and consumers don't understand it.
<br> <br>
Good programming requires creative problems solving, but without discipline, even extremely talented "artists" will produce absolutely unusable and worthless code.  While there is still some room for the lone cowboy coders to create a world-changing application, that's not the norm.  Most software is part of a large and complex system.  Without BOTH the creativity and the discipline, the results will be lackluster - and that's what you see in most organizations.  Maybe that's just because society demands far more software than there are talented developers to produce it.</htmltext>
<tokenext>I ca n't agree that software engineering is inherently non-rigorous .
It 's just still too new , and the rigor is n't enforced .
We 've been building bridges for thousands of years , but software for less than a century .
Most management and consumers do n't understand it .
Good programming requires creative problems solving , but without discipline , even extremely talented " artists " will produce absolutely unusable and worthless code .
While there is still some room for the lone cowboy coders to create a world-changing application , that 's not the norm .
Most software is part of a large and complex system .
Without BOTH the creativity and the discipline , the results will be lackluster - and that 's what you see in most organizations .
Maybe that 's just because society demands far more software than there are talented developers to produce it .</tokentext>
<sentencetext>I can't agree that software engineering is inherently non-rigorous.
It's just still too new, and the rigor isn't enforced.
We've been building bridges for thousands of years, but software for less than a century.
Most management and consumers don't understand it.
Good programming requires creative problems solving, but without discipline, even extremely talented "artists" will produce absolutely unusable and worthless code.
While there is still some room for the lone cowboy coders to create a world-changing application, that's not the norm.
Most software is part of a large and complex system.
Without BOTH the creativity and the discipline, the results will be lackluster - and that's what you see in most organizations.
Maybe that's just because society demands far more software than there are talented developers to produce it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230653</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244230920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>In this case, "Physical analysis" would be running tests, deployment, crash analysis, etc. If we're comparing software engineering to "real" engineering, I feel it would be disingenuous to knock down software engineering because it works with code instead of physical items. The complexity is still there.<br> <br>

For me, what delineates "engineer" is much better defined in my mind by "engineering type." While a software engineers, civil engineers, and mathematicians may vary quite a bit in average disposition, they are more similar than dissimilar compared to the rest of the population. I genuinely believe that there is a major difference between the engineering mind (or in my case, CS), and everyone else. Similar to how painters, composers, and photographers all may vary in general, yet they're more similar to each other than the rest of the population.</htmltext>
<tokenext>In this case , " Physical analysis " would be running tests , deployment , crash analysis , etc .
If we 're comparing software engineering to " real " engineering , I feel it would be disingenuous to knock down software engineering because it works with code instead of physical items .
The complexity is still there .
For me , what delineates " engineer " is much better defined in my mind by " engineering type .
" While a software engineers , civil engineers , and mathematicians may vary quite a bit in average disposition , they are more similar than dissimilar compared to the rest of the population .
I genuinely believe that there is a major difference between the engineering mind ( or in my case , CS ) , and everyone else .
Similar to how painters , composers , and photographers all may vary in general , yet they 're more similar to each other than the rest of the population .</tokentext>
<sentencetext>In this case, "Physical analysis" would be running tests, deployment, crash analysis, etc.
If we're comparing software engineering to "real" engineering, I feel it would be disingenuous to knock down software engineering because it works with code instead of physical items.
The complexity is still there.
For me, what delineates "engineer" is much better defined in my mind by "engineering type.
" While a software engineers, civil engineers, and mathematicians may vary quite a bit in average disposition, they are more similar than dissimilar compared to the rest of the population.
I genuinely believe that there is a major difference between the engineering mind (or in my case, CS), and everyone else.
Similar to how painters, composers, and photographers all may vary in general, yet they're more similar to each other than the rest of the population.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231033</id>
	<title>Re:Software Development is actually an art</title>
	<author>DNS-and-BIND</author>
	<datestamp>1244280360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>How can software engineers call themselves engineers?  If an engineer designs a car and it crashes due to easily-avoidable defects, he goes to jail.  If an "engineer" designs software and it crashes due to easily-avoidable defects, it's considered unavoidable.</htmltext>
<tokenext>How can software engineers call themselves engineers ?
If an engineer designs a car and it crashes due to easily-avoidable defects , he goes to jail .
If an " engineer " designs software and it crashes due to easily-avoidable defects , it 's considered unavoidable .</tokentext>
<sentencetext>How can software engineers call themselves engineers?
If an engineer designs a car and it crashes due to easily-avoidable defects, he goes to jail.
If an "engineer" designs software and it crashes due to easily-avoidable defects, it's considered unavoidable.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28243285</id>
	<title>Re:Software Engineering is trying</title>
	<author>sjames</author>
	<datestamp>1244405640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That exists in other disciplines as well. Wright and Hitler both designed buildings adequate to their task. Wright's are considered "beautiful" and are celebrated while Hitler's were called "brutal" and torn down. Wright was an artist while Hitler went through the motions with pretensions.</p></htmltext>
<tokenext>That exists in other disciplines as well .
Wright and Hitler both designed buildings adequate to their task .
Wright 's are considered " beautiful " and are celebrated while Hitler 's were called " brutal " and torn down .
Wright was an artist while Hitler went through the motions with pretensions .</tokentext>
<sentencetext>That exists in other disciplines as well.
Wright and Hitler both designed buildings adequate to their task.
Wright's are considered "beautiful" and are celebrated while Hitler's were called "brutal" and torn down.
Wright was an artist while Hitler went through the motions with pretensions.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231025</id>
	<title>The reason why we are doing it manualy</title>
	<author>Anonymous</author>
	<datestamp>1244280300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>... is that the Halting Problem and (verification of) Semanic Correctness of a program are formaly indecidable.</p></htmltext>
<tokenext>... is that the Halting Problem and ( verification of ) Semanic Correctness of a program are formaly indecidable .</tokentext>
<sentencetext>... is that the Halting Problem and (verification of) Semanic Correctness of a program are formaly indecidable.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232919</id>
	<title>Re:You're not Engineers. Get over it.</title>
	<author>Anonymous</author>
	<datestamp>1244303280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"No engineering degree = no engineer."</p><p>You are Spanish, ain't you?</p></htmltext>
<tokenext>" No engineering degree = no engineer .
" You are Spanish , ai n't you ?</tokentext>
<sentencetext>"No engineering degree = no engineer.
"You are Spanish, ain't you?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231711</id>
	<title>Why I prefer Computer Science</title>
	<author>Ben1220</author>
	<datestamp>1244291640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This article could have been renamed to "Why I chose to major in Computer Science instead of software engineering" and it would also make sense.</htmltext>
<tokenext>This article could have been renamed to " Why I chose to major in Computer Science instead of software engineering " and it would also make sense .</tokentext>
<sentencetext>This article could have been renamed to "Why I chose to major in Computer Science instead of software engineering" and it would also make sense.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230793</id>
	<title>Old debate</title>
	<author>jilles</author>
	<datestamp>1244319300000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I think more specifically, Software Engineering is an empirical discipline. All successful approaches in this field (scientific and practical) are about empirically measuring and adjusting what is going on rather than using mathematical models to analyze or predict things. This puts Software Engineering more in the realm of social sciences than that of mathematics. As a consequence, the current practice of old fashioned mathematicians that became computer scientist teaching software engineering in universities produces mediocre results since they typically lack the background for using empirical approaches. In other words they are effectively amateurs lacking both relevant experience in actually practicing software engineering (at least I observed this when studying CS) on large software systems and the necessary scientific background for studying software engineering in a empirical way.</p><p>Luckily this has been changing. Most of the better universities now have software engineering scientists that actually do have a clue when it comes to their topic. Also industrial practice is gradually progressing (although the number of cocky CS college dropouts ignoring 40 years of wisdom remains a problem). Methodologies like scrum and other agile approaches are solidly based on measuring what is going on and applying practices that have been demonstrated to actually work (as opposed to be predicted/assumed to work by some mathematician). Sadly most companies practicing these methodologies don't do so rigorously and only pay lip service to the whole notion. All the good software engineers I know combine excellent technical skills with good empirical and people skills. It's all about measuring what is going on rather than assuming or deducing from mathematical models. Good SEs use test suites, profilers and other means to find out how good/bad their code is.</p><p>So, maintainability is a function of how messy the software is (easy to measure with all sort of metrics), how well the code is covered with tests (easy to measure), number of bugs per kloc (easy to measure), and indeed experience of the people maintaining the software (not that difficult either). A typical mismanaged project will have some junior software engineer messing with the code until it works (sort of), lots of reported bugs, poor test coverage, and a manager who doesn't act on any of the things he/she should be measuring.</p><p>One of the interesting things about large open source projects is their Darwinist nature weeding out the bad ones. There's a lot to learn from how successful OSS projects operate. A lot of best practices find their origin in such projects. Things like version control, bug tracking, unit testing frameworks, etc are experimented with a lot in the OSS world. For example, Mozilla pioneered Bugzilla and was also quite early adopting continuous integration and automated tests. They developed a lot of technology and practices just to support knowing how they were doing. Most of that is now widely used across the industry. Ubuntu is doing similar things currently and projects like Eclipse maintain a very high pace of development with very consistent levels of quality in circumstances that most companies would be unable to handle.</p></htmltext>
<tokenext>I think more specifically , Software Engineering is an empirical discipline .
All successful approaches in this field ( scientific and practical ) are about empirically measuring and adjusting what is going on rather than using mathematical models to analyze or predict things .
This puts Software Engineering more in the realm of social sciences than that of mathematics .
As a consequence , the current practice of old fashioned mathematicians that became computer scientist teaching software engineering in universities produces mediocre results since they typically lack the background for using empirical approaches .
In other words they are effectively amateurs lacking both relevant experience in actually practicing software engineering ( at least I observed this when studying CS ) on large software systems and the necessary scientific background for studying software engineering in a empirical way.Luckily this has been changing .
Most of the better universities now have software engineering scientists that actually do have a clue when it comes to their topic .
Also industrial practice is gradually progressing ( although the number of cocky CS college dropouts ignoring 40 years of wisdom remains a problem ) .
Methodologies like scrum and other agile approaches are solidly based on measuring what is going on and applying practices that have been demonstrated to actually work ( as opposed to be predicted/assumed to work by some mathematician ) .
Sadly most companies practicing these methodologies do n't do so rigorously and only pay lip service to the whole notion .
All the good software engineers I know combine excellent technical skills with good empirical and people skills .
It 's all about measuring what is going on rather than assuming or deducing from mathematical models .
Good SEs use test suites , profilers and other means to find out how good/bad their code is.So , maintainability is a function of how messy the software is ( easy to measure with all sort of metrics ) , how well the code is covered with tests ( easy to measure ) , number of bugs per kloc ( easy to measure ) , and indeed experience of the people maintaining the software ( not that difficult either ) .
A typical mismanaged project will have some junior software engineer messing with the code until it works ( sort of ) , lots of reported bugs , poor test coverage , and a manager who does n't act on any of the things he/she should be measuring.One of the interesting things about large open source projects is their Darwinist nature weeding out the bad ones .
There 's a lot to learn from how successful OSS projects operate .
A lot of best practices find their origin in such projects .
Things like version control , bug tracking , unit testing frameworks , etc are experimented with a lot in the OSS world .
For example , Mozilla pioneered Bugzilla and was also quite early adopting continuous integration and automated tests .
They developed a lot of technology and practices just to support knowing how they were doing .
Most of that is now widely used across the industry .
Ubuntu is doing similar things currently and projects like Eclipse maintain a very high pace of development with very consistent levels of quality in circumstances that most companies would be unable to handle .</tokentext>
<sentencetext>I think more specifically, Software Engineering is an empirical discipline.
All successful approaches in this field (scientific and practical) are about empirically measuring and adjusting what is going on rather than using mathematical models to analyze or predict things.
This puts Software Engineering more in the realm of social sciences than that of mathematics.
As a consequence, the current practice of old fashioned mathematicians that became computer scientist teaching software engineering in universities produces mediocre results since they typically lack the background for using empirical approaches.
In other words they are effectively amateurs lacking both relevant experience in actually practicing software engineering (at least I observed this when studying CS) on large software systems and the necessary scientific background for studying software engineering in a empirical way.Luckily this has been changing.
Most of the better universities now have software engineering scientists that actually do have a clue when it comes to their topic.
Also industrial practice is gradually progressing (although the number of cocky CS college dropouts ignoring 40 years of wisdom remains a problem).
Methodologies like scrum and other agile approaches are solidly based on measuring what is going on and applying practices that have been demonstrated to actually work (as opposed to be predicted/assumed to work by some mathematician).
Sadly most companies practicing these methodologies don't do so rigorously and only pay lip service to the whole notion.
All the good software engineers I know combine excellent technical skills with good empirical and people skills.
It's all about measuring what is going on rather than assuming or deducing from mathematical models.
Good SEs use test suites, profilers and other means to find out how good/bad their code is.So, maintainability is a function of how messy the software is (easy to measure with all sort of metrics), how well the code is covered with tests (easy to measure), number of bugs per kloc (easy to measure), and indeed experience of the people maintaining the software (not that difficult either).
A typical mismanaged project will have some junior software engineer messing with the code until it works (sort of), lots of reported bugs, poor test coverage, and a manager who doesn't act on any of the things he/she should be measuring.One of the interesting things about large open source projects is their Darwinist nature weeding out the bad ones.
There's a lot to learn from how successful OSS projects operate.
A lot of best practices find their origin in such projects.
Things like version control, bug tracking, unit testing frameworks, etc are experimented with a lot in the OSS world.
For example, Mozilla pioneered Bugzilla and was also quite early adopting continuous integration and automated tests.
They developed a lot of technology and practices just to support knowing how they were doing.
Most of that is now widely used across the industry.
Ubuntu is doing similar things currently and projects like Eclipse maintain a very high pace of development with very consistent levels of quality in circumstances that most companies would be unable to handle.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28238545</id>
	<title>Re:Software Development is actually an art</title>
	<author>bill\_kress</author>
	<datestamp>1244302980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Of course it's true that it should be boring, rigorous and correct, but right now it can't be.  The first few thousand years of bridge building, they REALLY DID just build it and have guys walk across it until it collapsed, then rebuild it.</p><p>If you told someone to build a sky-scraper with only knowledge of the first 50 years of architecture to work on, it would be a really big FAIL.</p><p>And computer software can be many times more complex than anything else humanity's ever accomplished.  It's virtually impossible to get it ALL, so we build in layers.  The analogy would be trying to build a bridge to Hawaii.  You'd build out a little way, test, make sure stuff works, re-enforce it, then build on what's already been built.  Nobody could do the entire trip, but between different techniques, building on each others work, and some very crafty, creative artistic thought--it just might be doable (I'm not saying I'd want to USE it).</p><p>There are very few tasks in today's workplace that require as much thought as programming, and for most problems there is no "correct" solution.  A guy building a high performance 3-d game can't use a library built to be readable over fast.  I good server can't use a library built for speed, scalability and maintainability or more important.</p><p>Software engineering can't even build on the other engineering disciplines--it's too different so we're starting over from scratch.</p><p>So yeah, until we've been programming for a thousand years or so, I don't know if it's fair to expect to see the same kind of discipline.</p></htmltext>
<tokenext>Of course it 's true that it should be boring , rigorous and correct , but right now it ca n't be .
The first few thousand years of bridge building , they REALLY DID just build it and have guys walk across it until it collapsed , then rebuild it.If you told someone to build a sky-scraper with only knowledge of the first 50 years of architecture to work on , it would be a really big FAIL.And computer software can be many times more complex than anything else humanity 's ever accomplished .
It 's virtually impossible to get it ALL , so we build in layers .
The analogy would be trying to build a bridge to Hawaii .
You 'd build out a little way , test , make sure stuff works , re-enforce it , then build on what 's already been built .
Nobody could do the entire trip , but between different techniques , building on each others work , and some very crafty , creative artistic thought--it just might be doable ( I 'm not saying I 'd want to USE it ) .There are very few tasks in today 's workplace that require as much thought as programming , and for most problems there is no " correct " solution .
A guy building a high performance 3-d game ca n't use a library built to be readable over fast .
I good server ca n't use a library built for speed , scalability and maintainability or more important.Software engineering ca n't even build on the other engineering disciplines--it 's too different so we 're starting over from scratch.So yeah , until we 've been programming for a thousand years or so , I do n't know if it 's fair to expect to see the same kind of discipline .</tokentext>
<sentencetext>Of course it's true that it should be boring, rigorous and correct, but right now it can't be.
The first few thousand years of bridge building, they REALLY DID just build it and have guys walk across it until it collapsed, then rebuild it.If you told someone to build a sky-scraper with only knowledge of the first 50 years of architecture to work on, it would be a really big FAIL.And computer software can be many times more complex than anything else humanity's ever accomplished.
It's virtually impossible to get it ALL, so we build in layers.
The analogy would be trying to build a bridge to Hawaii.
You'd build out a little way, test, make sure stuff works, re-enforce it, then build on what's already been built.
Nobody could do the entire trip, but between different techniques, building on each others work, and some very crafty, creative artistic thought--it just might be doable (I'm not saying I'd want to USE it).There are very few tasks in today's workplace that require as much thought as programming, and for most problems there is no "correct" solution.
A guy building a high performance 3-d game can't use a library built to be readable over fast.
I good server can't use a library built for speed, scalability and maintainability or more important.Software engineering can't even build on the other engineering disciplines--it's too different so we're starting over from scratch.So yeah, until we've been programming for a thousand years or so, I don't know if it's fair to expect to see the same kind of discipline.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231389</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28289777</id>
	<title>Hate to inject some reality, but it needs doing...</title>
	<author>valdis</author>
	<datestamp>1244659500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"Economics generally failed to predict the mortgage meltdown."</p><p>Um. No.</p><p>There were a *lot* of economists that were saying a decade ago that nothing good could come from the deregulation craze, and the almost total lack of effective oversight over at the SEC.</p><p>You want to hang somebody out to dry, go after the financial execs that did the stuff, and the government people that acted as facilitators.</p></htmltext>
<tokenext>" Economics generally failed to predict the mortgage meltdown. " Um .
No.There were a * lot * of economists that were saying a decade ago that nothing good could come from the deregulation craze , and the almost total lack of effective oversight over at the SEC.You want to hang somebody out to dry , go after the financial execs that did the stuff , and the government people that acted as facilitators .</tokentext>
<sentencetext>"Economics generally failed to predict the mortgage meltdown."Um.
No.There were a *lot* of economists that were saying a decade ago that nothing good could come from the deregulation craze, and the almost total lack of effective oversight over at the SEC.You want to hang somebody out to dry, go after the financial execs that did the stuff, and the government people that acted as facilitators.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28237519</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230827</id>
	<title>Compare and contrast Comp Sci &amp; Comp Eng</title>
	<author>play\_in\_traffic</author>
	<datestamp>1244320020000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>One is not engineering. The other is not science.</htmltext>
<tokenext>One is not engineering .
The other is not science .</tokentext>
<sentencetext>One is not engineering.
The other is not science.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230613</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244230500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>From Wikipedia:</p><p>"Engineering is the discipline and profession of applying technical, scientific and mathematical knowledge in order to use natural laws and physical resources to help design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective."</p><p>When was the last time you saw your structural engineers do their work from first principles taught at uni, as opposed to spreadsheet design or computer simulation?</p><p>The next question is, why should they?</p><p>I am a "software engineer" by profession, but my basic training is electronics engineering.</p><p>Without formal rigour, is software engineering a trade/vocation or a profession?   My supervising senior engineer does a lot less maths and formal design than I do (which is mostly for sensor processing, which requires it), yet he solves most software implementation problems more efficiently and cleanly than I do.  Does that make him any less of an engineer than me? I think not.</p><p>Sometimes I think "software engineer" is a bit of a catch-all title given by HR to those that are required to write software as part of their jobs (and is the main tangible output of their job), when in reality the design that they do could be any number of fields, software or otherwise.</p></htmltext>
<tokenext>From Wikipedia : " Engineering is the discipline and profession of applying technical , scientific and mathematical knowledge in order to use natural laws and physical resources to help design and implement materials , structures , machines , devices , systems , and processes that safely realize a desired objective .
" When was the last time you saw your structural engineers do their work from first principles taught at uni , as opposed to spreadsheet design or computer simulation ? The next question is , why should they ? I am a " software engineer " by profession , but my basic training is electronics engineering.Without formal rigour , is software engineering a trade/vocation or a profession ?
My supervising senior engineer does a lot less maths and formal design than I do ( which is mostly for sensor processing , which requires it ) , yet he solves most software implementation problems more efficiently and cleanly than I do .
Does that make him any less of an engineer than me ?
I think not.Sometimes I think " software engineer " is a bit of a catch-all title given by HR to those that are required to write software as part of their jobs ( and is the main tangible output of their job ) , when in reality the design that they do could be any number of fields , software or otherwise .</tokentext>
<sentencetext>From Wikipedia:"Engineering is the discipline and profession of applying technical, scientific and mathematical knowledge in order to use natural laws and physical resources to help design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective.
"When was the last time you saw your structural engineers do their work from first principles taught at uni, as opposed to spreadsheet design or computer simulation?The next question is, why should they?I am a "software engineer" by profession, but my basic training is electronics engineering.Without formal rigour, is software engineering a trade/vocation or a profession?
My supervising senior engineer does a lot less maths and formal design than I do (which is mostly for sensor processing, which requires it), yet he solves most software implementation problems more efficiently and cleanly than I do.
Does that make him any less of an engineer than me?
I think not.Sometimes I think "software engineer" is a bit of a catch-all title given by HR to those that are required to write software as part of their jobs (and is the main tangible output of their job), when in reality the design that they do could be any number of fields, software or otherwise.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231943</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244295060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>If 3" C-Channel cost $0.05 per linear foot, how much checking would you do beyond "good enough"?</p></div><p>Unlike "Software Engineering", a "real" engineer might just actually consider whether the material could stand up under the expected strain. Plus at least 10\%. No just "good enough".</p></div>
	</htmltext>
<tokenext>If 3 " C-Channel cost $ 0.05 per linear foot , how much checking would you do beyond " good enough " ? Unlike " Software Engineering " , a " real " engineer might just actually consider whether the material could stand up under the expected strain .
Plus at least 10 \ % .
No just " good enough " .</tokentext>
<sentencetext>If 3" C-Channel cost $0.05 per linear foot, how much checking would you do beyond "good enough"?Unlike "Software Engineering", a "real" engineer might just actually consider whether the material could stand up under the expected strain.
Plus at least 10\%.
No just "good enough".
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230803</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233247</id>
	<title>The pain of software engineering</title>
	<author>janwedekind</author>
	<datestamp>1244305020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>When I studied software engineering as part of my degree I found it quite painful. It seemed quite interesting and relevant but it eerily reminded me of the "soft" sciences I had to learn to pass school (foreign languages, biology, chemistry).</p><p>For me the most frustrating thing in computer science is the many programming languages, each of them offering one compelling feature or another. But as Paul Graham said: <a href="http://www.paulgraham.com/hundred.html" title="paulgraham.com">Languages evolve slowly because they're not really technologies. Languages are notation.</a> [paulgraham.com]<br>The problem is, that it is not enough to create a better programming language or integrate a missing feature into an existing one, because then you have made the problem worse by introducing an additional language. So what you really need to do (at the same time) is to persuade other developers to adopt your language by providing a notation which is "powerful" and looks "nifty". And that is where the human factor comes in.</p></htmltext>
<tokenext>When I studied software engineering as part of my degree I found it quite painful .
It seemed quite interesting and relevant but it eerily reminded me of the " soft " sciences I had to learn to pass school ( foreign languages , biology , chemistry ) .For me the most frustrating thing in computer science is the many programming languages , each of them offering one compelling feature or another .
But as Paul Graham said : Languages evolve slowly because they 're not really technologies .
Languages are notation .
[ paulgraham.com ] The problem is , that it is not enough to create a better programming language or integrate a missing feature into an existing one , because then you have made the problem worse by introducing an additional language .
So what you really need to do ( at the same time ) is to persuade other developers to adopt your language by providing a notation which is " powerful " and looks " nifty " .
And that is where the human factor comes in .</tokentext>
<sentencetext>When I studied software engineering as part of my degree I found it quite painful.
It seemed quite interesting and relevant but it eerily reminded me of the "soft" sciences I had to learn to pass school (foreign languages, biology, chemistry).For me the most frustrating thing in computer science is the many programming languages, each of them offering one compelling feature or another.
But as Paul Graham said: Languages evolve slowly because they're not really technologies.
Languages are notation.
[paulgraham.com]The problem is, that it is not enough to create a better programming language or integrate a missing feature into an existing one, because then you have made the problem worse by introducing an additional language.
So what you really need to do (at the same time) is to persuade other developers to adopt your language by providing a notation which is "powerful" and looks "nifty".
And that is where the human factor comes in.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28239611</id>
	<title>Re:Professional Engineer</title>
	<author>tyrione</author>
	<datestamp>1244318040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>P.E. typically standards for Principle Engineer in ME, EE, CE, ChemE, MatSci, etc.</htmltext>
<tokenext>P.E .
typically standards for Principle Engineer in ME , EE , CE , ChemE , MatSci , etc .</tokentext>
<sentencetext>P.E.
typically standards for Principle Engineer in ME, EE, CE, ChemE, MatSci, etc.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232177</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230607</id>
	<title>Re:You're not Engineers. Got train?</title>
	<author>Anonymous</author>
	<datestamp>1244230260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>You need a choo choo train for that</htmltext>
<tokenext>You need a choo choo train for that</tokentext>
<sentencetext>You need a choo choo train for that</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231579</id>
	<title>Functionality &amp; Meaning, or Engineering &amp;</title>
	<author>mishiltu</author>
	<datestamp>1244289720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I agree with the author of the article, there are two levels in source code. On the one hand there is the formal side, the syntax level, if you will, which can be quite simply checked by tools. As programming language standards leave certain things undefined just because of the infinite amount of combinations in a language, so do compilers and linkers also. Static analysis tools, like lint, are much more nitpicking and try to uncover probable programmer mistakes for example through uncommon usage of certain structures.</p><p>But there is also the higher semantic level present in the source code. How well does the source code express its intent and how well is it structured. That is only directly visible internally, but does most likely have larger than generally understood indirect effects externally. The problem with software engineers is that they listen much too much to what the customers, testers and managers have to say. And all of them focus only on functionality. Most engineers also like to see something working and sometimes they do anything to get something working. Clarity and meaning in the source code are secondary concerns.</p><p>The results are clearly visible.</p><p>Software systems are working, kind of, but they cannot be changed too readily. Software isn't soft at all, because its internal clarity, maintainability is compromised. Using only simple names for variables (tmp, i, cnt, ret\_val, status) makes code not readable, as an example. How much bad naming hurts the understandability of a piece of code is not known but is probably underestimated.</p><p>There are certainly rules that could be used to limit the chaos in source code without limiting the necessary creativity. There are issues that 1) are Missing from the source code, 2) Extraneous, 3) make Risky assumptions, or 4) cause Chaos. Some examples:<br>1) Magic (hard-coded) numbers<br>2) Comments that repeat what the code clearly says<br>3) Not checking a pointer for NULL before dereferencing it<br>4) Nesting too deeply</p><p>The funny thing is that such things can be easily checked manually, locally within functions, on paper and massive amounts of findings can be made in almost any programming language. Ticking code (or marking rule violations) shows that almost all software developers are neglecting maintainability in their code. Tick-the-Code is one way of triggering refactoring, and improving the design of existing source code. For more information, check out www.tick-the-code.com.</p></htmltext>
<tokenext>I agree with the author of the article , there are two levels in source code .
On the one hand there is the formal side , the syntax level , if you will , which can be quite simply checked by tools .
As programming language standards leave certain things undefined just because of the infinite amount of combinations in a language , so do compilers and linkers also .
Static analysis tools , like lint , are much more nitpicking and try to uncover probable programmer mistakes for example through uncommon usage of certain structures.But there is also the higher semantic level present in the source code .
How well does the source code express its intent and how well is it structured .
That is only directly visible internally , but does most likely have larger than generally understood indirect effects externally .
The problem with software engineers is that they listen much too much to what the customers , testers and managers have to say .
And all of them focus only on functionality .
Most engineers also like to see something working and sometimes they do anything to get something working .
Clarity and meaning in the source code are secondary concerns.The results are clearly visible.Software systems are working , kind of , but they can not be changed too readily .
Software is n't soft at all , because its internal clarity , maintainability is compromised .
Using only simple names for variables ( tmp , i , cnt , ret \ _val , status ) makes code not readable , as an example .
How much bad naming hurts the understandability of a piece of code is not known but is probably underestimated.There are certainly rules that could be used to limit the chaos in source code without limiting the necessary creativity .
There are issues that 1 ) are Missing from the source code , 2 ) Extraneous , 3 ) make Risky assumptions , or 4 ) cause Chaos .
Some examples : 1 ) Magic ( hard-coded ) numbers2 ) Comments that repeat what the code clearly says3 ) Not checking a pointer for NULL before dereferencing it4 ) Nesting too deeplyThe funny thing is that such things can be easily checked manually , locally within functions , on paper and massive amounts of findings can be made in almost any programming language .
Ticking code ( or marking rule violations ) shows that almost all software developers are neglecting maintainability in their code .
Tick-the-Code is one way of triggering refactoring , and improving the design of existing source code .
For more information , check out www.tick-the-code.com .</tokentext>
<sentencetext>I agree with the author of the article, there are two levels in source code.
On the one hand there is the formal side, the syntax level, if you will, which can be quite simply checked by tools.
As programming language standards leave certain things undefined just because of the infinite amount of combinations in a language, so do compilers and linkers also.
Static analysis tools, like lint, are much more nitpicking and try to uncover probable programmer mistakes for example through uncommon usage of certain structures.But there is also the higher semantic level present in the source code.
How well does the source code express its intent and how well is it structured.
That is only directly visible internally, but does most likely have larger than generally understood indirect effects externally.
The problem with software engineers is that they listen much too much to what the customers, testers and managers have to say.
And all of them focus only on functionality.
Most engineers also like to see something working and sometimes they do anything to get something working.
Clarity and meaning in the source code are secondary concerns.The results are clearly visible.Software systems are working, kind of, but they cannot be changed too readily.
Software isn't soft at all, because its internal clarity, maintainability is compromised.
Using only simple names for variables (tmp, i, cnt, ret\_val, status) makes code not readable, as an example.
How much bad naming hurts the understandability of a piece of code is not known but is probably underestimated.There are certainly rules that could be used to limit the chaos in source code without limiting the necessary creativity.
There are issues that 1) are Missing from the source code, 2) Extraneous, 3) make Risky assumptions, or 4) cause Chaos.
Some examples:1) Magic (hard-coded) numbers2) Comments that repeat what the code clearly says3) Not checking a pointer for NULL before dereferencing it4) Nesting too deeplyThe funny thing is that such things can be easily checked manually, locally within functions, on paper and massive amounts of findings can be made in almost any programming language.
Ticking code (or marking rule violations) shows that almost all software developers are neglecting maintainability in their code.
Tick-the-Code is one way of triggering refactoring, and improving the design of existing source code.
For more information, check out www.tick-the-code.com.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230519</id>
	<title>First!</title>
	<author>Anonymous</author>
	<datestamp>1244228940000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Wouldn't it still be as much a science as say... human psychology?</p></htmltext>
<tokenext>Would n't it still be as much a science as say... human psychology ?</tokentext>
<sentencetext>Wouldn't it still be as much a science as say... human psychology?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230981</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244279640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Go through a few law suits, specs become more rigid and standardized, maybe impose a few regulations, it'd be like any other engineering field.  But then it won't be so "soft" - it would also become an oxymoron.  Such is life.</htmltext>
<tokenext>Go through a few law suits , specs become more rigid and standardized , maybe impose a few regulations , it 'd be like any other engineering field .
But then it wo n't be so " soft " - it would also become an oxymoron .
Such is life .</tokentext>
<sentencetext>Go through a few law suits, specs become more rigid and standardized, maybe impose a few regulations, it'd be like any other engineering field.
But then it won't be so "soft" - it would also become an oxymoron.
Such is life.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230655</id>
	<title>Re:You're not Engineers. Get over it.</title>
	<author>realnrh</author>
	<datestamp>1244230920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>So how about a degree that says "Master of Science in Engineering" for Computer Science? Does that count as an engineering degree?</htmltext>
<tokenext>So how about a degree that says " Master of Science in Engineering " for Computer Science ?
Does that count as an engineering degree ?</tokentext>
<sentencetext>So how about a degree that says "Master of Science in Engineering" for Computer Science?
Does that count as an engineering degree?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28235807</id>
	<title>Re:Not just software</title>
	<author>CreateWindowEx</author>
	<datestamp>1244321940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>In the previous era of console games before they started supporting patches, games were treated much more like hardware in this sense because once you made the gold master and started printing copies, you couldn't change it.  When you compare PC games of that era with console games, the rate of crashes and bugs was much higher on PC games.  This was partly, of course because they had to run on a zillion configurations and depend on buggy device drivers, but also because the console makers had fairly rigorous submission testing requirements, and could hold up a game from shipping if it didn't meet these requirements (In the case of 1st party games, of course, there is an inherent conflict of interest there, but typically the approval process was fairly independent of the console makers' publishing arms).  By contrast, PC games (like other PC software) have absolutely no oversight, so developers/publishers just do however much or little quality control that they feel they want to.<br>
The PC approach is to let the market reward or punish software companies for how buggy their products are.  Unfortunately, so much software uses various means of lock-in to prevent users from switching, that it ends up being a situation where the focus is on getting users to pay for upgrades, sometimes merely to fix things which shouldn't have been broken in the first place, and even that incentive is being removed as more software packages try to force users to constantly upgrade (e.g., make different versions non-interoperable but not sell older versions, so if you add new seats to a company you may be forced to upgrade the whole office)<br>
For software used in high-risk situations (e.g., medical software, aeronautics, space flight), the penalty for failure is high enough that people are willing to pay (and wait) for extensive quality control.  For most other software, this is not the case.</htmltext>
<tokenext>In the previous era of console games before they started supporting patches , games were treated much more like hardware in this sense because once you made the gold master and started printing copies , you could n't change it .
When you compare PC games of that era with console games , the rate of crashes and bugs was much higher on PC games .
This was partly , of course because they had to run on a zillion configurations and depend on buggy device drivers , but also because the console makers had fairly rigorous submission testing requirements , and could hold up a game from shipping if it did n't meet these requirements ( In the case of 1st party games , of course , there is an inherent conflict of interest there , but typically the approval process was fairly independent of the console makers ' publishing arms ) .
By contrast , PC games ( like other PC software ) have absolutely no oversight , so developers/publishers just do however much or little quality control that they feel they want to .
The PC approach is to let the market reward or punish software companies for how buggy their products are .
Unfortunately , so much software uses various means of lock-in to prevent users from switching , that it ends up being a situation where the focus is on getting users to pay for upgrades , sometimes merely to fix things which should n't have been broken in the first place , and even that incentive is being removed as more software packages try to force users to constantly upgrade ( e.g. , make different versions non-interoperable but not sell older versions , so if you add new seats to a company you may be forced to upgrade the whole office ) For software used in high-risk situations ( e.g. , medical software , aeronautics , space flight ) , the penalty for failure is high enough that people are willing to pay ( and wait ) for extensive quality control .
For most other software , this is not the case .</tokentext>
<sentencetext>In the previous era of console games before they started supporting patches, games were treated much more like hardware in this sense because once you made the gold master and started printing copies, you couldn't change it.
When you compare PC games of that era with console games, the rate of crashes and bugs was much higher on PC games.
This was partly, of course because they had to run on a zillion configurations and depend on buggy device drivers, but also because the console makers had fairly rigorous submission testing requirements, and could hold up a game from shipping if it didn't meet these requirements (In the case of 1st party games, of course, there is an inherent conflict of interest there, but typically the approval process was fairly independent of the console makers' publishing arms).
By contrast, PC games (like other PC software) have absolutely no oversight, so developers/publishers just do however much or little quality control that they feel they want to.
The PC approach is to let the market reward or punish software companies for how buggy their products are.
Unfortunately, so much software uses various means of lock-in to prevent users from switching, that it ends up being a situation where the focus is on getting users to pay for upgrades, sometimes merely to fix things which shouldn't have been broken in the first place, and even that incentive is being removed as more software packages try to force users to constantly upgrade (e.g., make different versions non-interoperable but not sell older versions, so if you add new seats to a company you may be forced to upgrade the whole office)
For software used in high-risk situations (e.g., medical software, aeronautics, space flight), the penalty for failure is high enough that people are willing to pay (and wait) for extensive quality control.
For most other software, this is not the case.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231089</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236389</id>
	<title>Re:Software Development is actually an art</title>
	<author>DoubleReed</author>
	<datestamp>1244282520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The grass is always greener on the other side.  Software developers marvel at the much higher reliability that other engineering disciplines have in their shipped products.  Other engineers marvel at the incredible cheapness of software development.<br>
<br>
The practices commonly used in creating software reflect the most effective set of trade-offs given the realities of how the software is used.  One of those realities is that software crashes don't kill people.  In the case that a software crash can kill people, the development process is approached differently, and the software costs much more to produce.<br>
<br>
Also, it may be a false dichotomy to contrast car design with software engineering.  Software is an important component in a modern car (computer controller traction and fuel injection for example.)</htmltext>
<tokenext>The grass is always greener on the other side .
Software developers marvel at the much higher reliability that other engineering disciplines have in their shipped products .
Other engineers marvel at the incredible cheapness of software development .
The practices commonly used in creating software reflect the most effective set of trade-offs given the realities of how the software is used .
One of those realities is that software crashes do n't kill people .
In the case that a software crash can kill people , the development process is approached differently , and the software costs much more to produce .
Also , it may be a false dichotomy to contrast car design with software engineering .
Software is an important component in a modern car ( computer controller traction and fuel injection for example .
)</tokentext>
<sentencetext>The grass is always greener on the other side.
Software developers marvel at the much higher reliability that other engineering disciplines have in their shipped products.
Other engineers marvel at the incredible cheapness of software development.
The practices commonly used in creating software reflect the most effective set of trade-offs given the realities of how the software is used.
One of those realities is that software crashes don't kill people.
In the case that a software crash can kill people, the development process is approached differently, and the software costs much more to produce.
Also, it may be a false dichotomy to contrast car design with software engineering.
Software is an important component in a modern car (computer controller traction and fuel injection for example.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231033</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631</id>
	<title>Before we get all sweaty about terms</title>
	<author>Anonymous</author>
	<datestamp>1244230680000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>If you're an X Certified Y Engineer, you're a technician.
</p><p>If you can be counted on to design a system that reliably works without killing people, you're an engineer.
</p><p>If you can observe phenomena, reliably document previously unobserved phenomena, and from that produce useful but not mathematically precise practices or products you're a scientist.
</p><p>If you can gather observed facts into a sheaf of postulates and a system of symbols that can predict unobserved phenomena, you're a mathematician.
</p><p>If you can't do any of the above, you can always check bags at LAX for $150K a year.
</p><p>If you can't get bags from the trunk to the belt, you might consider a position in middle management.</p></htmltext>
<tokenext>If you 're an X Certified Y Engineer , you 're a technician .
If you can be counted on to design a system that reliably works without killing people , you 're an engineer .
If you can observe phenomena , reliably document previously unobserved phenomena , and from that produce useful but not mathematically precise practices or products you 're a scientist .
If you can gather observed facts into a sheaf of postulates and a system of symbols that can predict unobserved phenomena , you 're a mathematician .
If you ca n't do any of the above , you can always check bags at LAX for $ 150K a year .
If you ca n't get bags from the trunk to the belt , you might consider a position in middle management .</tokentext>
<sentencetext>If you're an X Certified Y Engineer, you're a technician.
If you can be counted on to design a system that reliably works without killing people, you're an engineer.
If you can observe phenomena, reliably document previously unobserved phenomena, and from that produce useful but not mathematically precise practices or products you're a scientist.
If you can gather observed facts into a sheaf of postulates and a system of symbols that can predict unobserved phenomena, you're a mathematician.
If you can't do any of the above, you can always check bags at LAX for $150K a year.
If you can't get bags from the trunk to the belt, you might consider a position in middle management.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28238369</id>
	<title>Re:Perspective?</title>
	<author>frogzilla</author>
	<datestamp>1244301060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><em>"while in science it doesn't even have to compile. It only has to work in some ideal world with unlimited resources and non-existent foreign factors."</em></p><p>-<br>-</p><p>This is so terribly wrong.</p></htmltext>
<tokenext>" while in science it does n't even have to compile .
It only has to work in some ideal world with unlimited resources and non-existent foreign factors .
" --This is so terribly wrong .</tokentext>
<sentencetext>"while in science it doesn't even have to compile.
It only has to work in some ideal world with unlimited resources and non-existent foreign factors.
"--This is so terribly wrong.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231169</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231127</id>
	<title>Didn't carmack comment on this a few years back?</title>
	<author>UnknownSoldier</author>
	<datestamp>1244281500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Can't seem to find the blog/article, but thought Carmack posted about being a game developer was akin to wearing different types of hats:<br>- architect (designing)<br>- engineering (building the program)<br>- scientist (diagnosing bugs)</p><p>I know this topic has been discussed back in 2004...<br><a href="http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&amp;ixPost=182392" title="fogcreek.com">http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&amp;ixPost=182392</a> [fogcreek.com]</p></htmltext>
<tokenext>Ca n't seem to find the blog/article , but thought Carmack posted about being a game developer was akin to wearing different types of hats : - architect ( designing ) - engineering ( building the program ) - scientist ( diagnosing bugs ) I know this topic has been discussed back in 2004...http : //discuss.fogcreek.com/joelonsoftware/default.asp ? cmd = show&amp;ixPost = 182392 [ fogcreek.com ]</tokentext>
<sentencetext>Can't seem to find the blog/article, but thought Carmack posted about being a game developer was akin to wearing different types of hats:- architect (designing)- engineering (building the program)- scientist (diagnosing bugs)I know this topic has been discussed back in 2004...http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&amp;ixPost=182392 [fogcreek.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230781</id>
	<title>Easy</title>
	<author>Anonymous</author>
	<datestamp>1244319180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>A computer science graduate creates the perfect program, then a software engineer goes and breaks it by making usable.</p></htmltext>
<tokenext>A computer science graduate creates the perfect program , then a software engineer goes and breaks it by making usable .</tokentext>
<sentencetext>A computer science graduate creates the perfect program, then a software engineer goes and breaks it by making usable.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231995</id>
	<title>Re:You're not Engineers. Get over it.</title>
	<author>Dragonslicer</author>
	<datestamp>1244295780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Look, there is nothing wrong with being a programmer. Just as a good tech gets pissed off when he sees a 'nail technician', real engineers laugh at the IT crowd.</p><p>No engineering degree = no engineer.</p></div><p>There's a difference between a programmer and a software engineer. Just like being able to nail pieces of wood together doesn't make you an architect, being able to write out a piece of code that does what someone else told you it has to do does not magically grant you the ability to design large or complex software systems.</p></div>
	</htmltext>
<tokenext>Look , there is nothing wrong with being a programmer .
Just as a good tech gets pissed off when he sees a 'nail technician ' , real engineers laugh at the IT crowd.No engineering degree = no engineer.There 's a difference between a programmer and a software engineer .
Just like being able to nail pieces of wood together does n't make you an architect , being able to write out a piece of code that does what someone else told you it has to do does not magically grant you the ability to design large or complex software systems .</tokentext>
<sentencetext>Look, there is nothing wrong with being a programmer.
Just as a good tech gets pissed off when he sees a 'nail technician', real engineers laugh at the IT crowd.No engineering degree = no engineer.There's a difference between a programmer and a software engineer.
Just like being able to nail pieces of wood together doesn't make you an architect, being able to write out a piece of code that does what someone else told you it has to do does not magically grant you the ability to design large or complex software systems.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230903</id>
	<title>Overlapping disciplines</title>
	<author>Anonymous</author>
	<datestamp>1244321400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think SE and CS are overlapping disciplines populated by people who tend to analyze the things that overlap and make (sometimes unnecessary) generalizations. Thus, it's natural that people in both disciplines make misguided attempts to define the relationship when in fact there is no stable relationship at all. It simply depends heavily on what you are doing.

I could ask endless other similar questions, like: what's the difference between a musician and a composer? One can be the other, and one doesn't necessarily have to be the other, and one can be made better at one by learning about the other.</htmltext>
<tokenext>I think SE and CS are overlapping disciplines populated by people who tend to analyze the things that overlap and make ( sometimes unnecessary ) generalizations .
Thus , it 's natural that people in both disciplines make misguided attempts to define the relationship when in fact there is no stable relationship at all .
It simply depends heavily on what you are doing .
I could ask endless other similar questions , like : what 's the difference between a musician and a composer ?
One can be the other , and one does n't necessarily have to be the other , and one can be made better at one by learning about the other .</tokentext>
<sentencetext>I think SE and CS are overlapping disciplines populated by people who tend to analyze the things that overlap and make (sometimes unnecessary) generalizations.
Thus, it's natural that people in both disciplines make misguided attempts to define the relationship when in fact there is no stable relationship at all.
It simply depends heavily on what you are doing.
I could ask endless other similar questions, like: what's the difference between a musician and a composer?
One can be the other, and one doesn't necessarily have to be the other, and one can be made better at one by learning about the other.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231275</id>
	<title>Re:Software Engineering is trying</title>
	<author>Tony-A</author>
	<datestamp>1244283840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt;.. to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be.<br>"Real Engineering" has something called "Strength of Materials". You can build a bridge out of wood or out of steel, but the designs will be different because engineers are aware that different materials have different properties and have some ability to quantify those differences. Designing a bridge so that it will "scale" would never be attempted in any real engineering discipline. However, engineers will make designs which are valid over some range.<br>Look real deep and I suspect that the creative processes are the more rigorous. "Just remove everything from the block of marble that isn't David" Just being different shouln't count as being creative.</p></htmltext>
<tokenext>&gt; .. to become a rigorous engineering discipline .
It 's not quite there yet .
I am not convinced that it ever will be .
" Real Engineering " has something called " Strength of Materials " .
You can build a bridge out of wood or out of steel , but the designs will be different because engineers are aware that different materials have different properties and have some ability to quantify those differences .
Designing a bridge so that it will " scale " would never be attempted in any real engineering discipline .
However , engineers will make designs which are valid over some range.Look real deep and I suspect that the creative processes are the more rigorous .
" Just remove everything from the block of marble that is n't David " Just being different shoul n't count as being creative .</tokentext>
<sentencetext>&gt;.. to become a rigorous engineering discipline.
It's not quite there yet.
I am not convinced that it ever will be.
"Real Engineering" has something called "Strength of Materials".
You can build a bridge out of wood or out of steel, but the designs will be different because engineers are aware that different materials have different properties and have some ability to quantify those differences.
Designing a bridge so that it will "scale" would never be attempted in any real engineering discipline.
However, engineers will make designs which are valid over some range.Look real deep and I suspect that the creative processes are the more rigorous.
"Just remove everything from the block of marble that isn't David" Just being different shouln't count as being creative.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231873</id>
	<title>an idealist view</title>
	<author>ninjaallenz</author>
	<datestamp>1244294100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm currently pursuing an accelerated masters in computer science, I may be naive but i feel my view is valid.
Open source is the future, well commented and the most efficient code should be made open source. Why
rewrite code that has already been written efficiently? Allowing access to well written and commented code
to the masses will allow for much more competition between coders. I understand it is not the easiest of jobs,
but wouldn't it make it easier if coders had some sort of universal code library where the best(efficient and stable) code
is up for use to create great applications and is also up for optimization and improvement?</htmltext>
<tokenext>I 'm currently pursuing an accelerated masters in computer science , I may be naive but i feel my view is valid .
Open source is the future , well commented and the most efficient code should be made open source .
Why rewrite code that has already been written efficiently ?
Allowing access to well written and commented code to the masses will allow for much more competition between coders .
I understand it is not the easiest of jobs , but would n't it make it easier if coders had some sort of universal code library where the best ( efficient and stable ) code is up for use to create great applications and is also up for optimization and improvement ?</tokentext>
<sentencetext>I'm currently pursuing an accelerated masters in computer science, I may be naive but i feel my view is valid.
Open source is the future, well commented and the most efficient code should be made open source.
Why
rewrite code that has already been written efficiently?
Allowing access to well written and commented code
to the masses will allow for much more competition between coders.
I understand it is not the easiest of jobs,
but wouldn't it make it easier if coders had some sort of universal code library where the best(efficient and stable) code
is up for use to create great applications and is also up for optimization and improvement?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28241161</id>
	<title>Re:Perspective?</title>
	<author>Anonymous</author>
	<datestamp>1244388240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>While very insightful in general I believe most of the posts in here quite miss the point. After more than 30 years in computers I have come to the conclusion that we cannot yet tell the difference between the tool and the application. We continue to discuss computer's and programming as if that was the focus of the endeavor when it is only part of the time.</p><p>The problem is likely that the tool itself requires continuous development. It's like a hammer that's incomplete so the carpenter has to spend as much time developing the hammer as he does using it to frame the house. I have so often, in my career, run into programmers who spend all their time on the tool and still don't know how to apply it to a real world problem.</p><p>The other issue is that any development project involves both elements of the application and elements of the tool. To continue the hammer analogy, it would be like having to worry about the comfort of the grip while figuring out how to apply it to drive a nail. No other discipline requires this intimate mixture of tool and application to accomplish it's goals. The application programmer must know both the physics/engineering of the problem against which the computer is applied and the "science" of the computer as well then throw in a little human factors engineering on the side and you begin to understand why one cannot distinguish the computer science from the computer engineering.</p></htmltext>
<tokenext>While very insightful in general I believe most of the posts in here quite miss the point .
After more than 30 years in computers I have come to the conclusion that we can not yet tell the difference between the tool and the application .
We continue to discuss computer 's and programming as if that was the focus of the endeavor when it is only part of the time.The problem is likely that the tool itself requires continuous development .
It 's like a hammer that 's incomplete so the carpenter has to spend as much time developing the hammer as he does using it to frame the house .
I have so often , in my career , run into programmers who spend all their time on the tool and still do n't know how to apply it to a real world problem.The other issue is that any development project involves both elements of the application and elements of the tool .
To continue the hammer analogy , it would be like having to worry about the comfort of the grip while figuring out how to apply it to drive a nail .
No other discipline requires this intimate mixture of tool and application to accomplish it 's goals .
The application programmer must know both the physics/engineering of the problem against which the computer is applied and the " science " of the computer as well then throw in a little human factors engineering on the side and you begin to understand why one can not distinguish the computer science from the computer engineering .</tokentext>
<sentencetext>While very insightful in general I believe most of the posts in here quite miss the point.
After more than 30 years in computers I have come to the conclusion that we cannot yet tell the difference between the tool and the application.
We continue to discuss computer's and programming as if that was the focus of the endeavor when it is only part of the time.The problem is likely that the tool itself requires continuous development.
It's like a hammer that's incomplete so the carpenter has to spend as much time developing the hammer as he does using it to frame the house.
I have so often, in my career, run into programmers who spend all their time on the tool and still don't know how to apply it to a real world problem.The other issue is that any development project involves both elements of the application and elements of the tool.
To continue the hammer analogy, it would be like having to worry about the comfort of the grip while figuring out how to apply it to drive a nail.
No other discipline requires this intimate mixture of tool and application to accomplish it's goals.
The application programmer must know both the physics/engineering of the problem against which the computer is applied and the "science" of the computer as well then throw in a little human factors engineering on the side and you begin to understand why one cannot distinguish the computer science from the computer engineering.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230897</id>
	<title>Engineering != Science</title>
	<author>Anonymous</author>
	<datestamp>1244321220000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Connell titles his article "Software Engineering != Computer Science." He later proposes Connell's Thesis, "Software engineering will never be a rigorous discipline with proven results, because it involves human activity."</p><p>I would suggest that the article's title reveals why software engineering doesn't have "proven results" in the sense that Connell means. It's not due to human activity. Rather: engineering != science. "Proven results" (i.e., a set of results logically derived as part of an axiomatic system) are more characteristic of a scientific field than an engineering discipline.</p><p>Engineering applies and relies on science, but is not science, per se. Mature engineering fields have standards and codes of practice, both science-based and empirically derived. When/if software engineering matures further, it is reasonable to expect such standards and codes to develop.</p></htmltext>
<tokenext>Connell titles his article " Software Engineering ! = Computer Science .
" He later proposes Connell 's Thesis , " Software engineering will never be a rigorous discipline with proven results , because it involves human activity .
" I would suggest that the article 's title reveals why software engineering does n't have " proven results " in the sense that Connell means .
It 's not due to human activity .
Rather : engineering ! = science .
" Proven results " ( i.e. , a set of results logically derived as part of an axiomatic system ) are more characteristic of a scientific field than an engineering discipline.Engineering applies and relies on science , but is not science , per se .
Mature engineering fields have standards and codes of practice , both science-based and empirically derived .
When/if software engineering matures further , it is reasonable to expect such standards and codes to develop .</tokentext>
<sentencetext>Connell titles his article "Software Engineering != Computer Science.
" He later proposes Connell's Thesis, "Software engineering will never be a rigorous discipline with proven results, because it involves human activity.
"I would suggest that the article's title reveals why software engineering doesn't have "proven results" in the sense that Connell means.
It's not due to human activity.
Rather: engineering != science.
"Proven results" (i.e., a set of results logically derived as part of an axiomatic system) are more characteristic of a scientific field than an engineering discipline.Engineering applies and relies on science, but is not science, per se.
Mature engineering fields have standards and codes of practice, both science-based and empirically derived.
When/if software engineering matures further, it is reasonable to expect such standards and codes to develop.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236505</id>
	<title>Re:Perspective?</title>
	<author>Anonymous</author>
	<datestamp>1244283240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Engineering is in deep real world, with human nature and business requirements intervening all the time. Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula. They are both trying to understand a problem - but from different angles. So different - or better say orthogonal - that they are guaranteed to cross only rarely.</p></div><p>Why does science have to be mutually exclusive with religion? Religion is the faith that someone possesses about reality. Science simply tries to achieve the same understanding that faith already provides someone and it does indeed occur from a different angle. But both science and religion have the same end in sight; they just reach the end through different means. In my mind, that doesn't make them mutually exclusively but instead members of both should cooperate to arrive at a final understanding of reality. The problem is that people of faith <b>can't</b> trust scientists (but they can trust science if the scientists could be trusted) and the scientists <b>don't want</b> to trust the people of faith because they are viewed as 2nd-tier humans due to their "crazy" faith. If scientists weren't so elitist they might just change their perspective from which they interpret evidence and also actually work with religion, instead of against it, in order to find the proof behind the truth. The truth is already known from the perspective of religion; science just has to catch up.</p></div>
	</htmltext>
<tokenext>Engineering is in deep real world , with human nature and business requirements intervening all the time .
Science ( like religion ) is in some sort of ideal world , vacuum , where all is simple and described by a formula .
They are both trying to understand a problem - but from different angles .
So different - or better say orthogonal - that they are guaranteed to cross only rarely.Why does science have to be mutually exclusive with religion ?
Religion is the faith that someone possesses about reality .
Science simply tries to achieve the same understanding that faith already provides someone and it does indeed occur from a different angle .
But both science and religion have the same end in sight ; they just reach the end through different means .
In my mind , that does n't make them mutually exclusively but instead members of both should cooperate to arrive at a final understanding of reality .
The problem is that people of faith ca n't trust scientists ( but they can trust science if the scientists could be trusted ) and the scientists do n't want to trust the people of faith because they are viewed as 2nd-tier humans due to their " crazy " faith .
If scientists were n't so elitist they might just change their perspective from which they interpret evidence and also actually work with religion , instead of against it , in order to find the proof behind the truth .
The truth is already known from the perspective of religion ; science just has to catch up .</tokentext>
<sentencetext>Engineering is in deep real world, with human nature and business requirements intervening all the time.
Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.
They are both trying to understand a problem - but from different angles.
So different - or better say orthogonal - that they are guaranteed to cross only rarely.Why does science have to be mutually exclusive with religion?
Religion is the faith that someone possesses about reality.
Science simply tries to achieve the same understanding that faith already provides someone and it does indeed occur from a different angle.
But both science and religion have the same end in sight; they just reach the end through different means.
In my mind, that doesn't make them mutually exclusively but instead members of both should cooperate to arrive at a final understanding of reality.
The problem is that people of faith can't trust scientists (but they can trust science if the scientists could be trusted) and the scientists don't want to trust the people of faith because they are viewed as 2nd-tier humans due to their "crazy" faith.
If scientists weren't so elitist they might just change their perspective from which they interpret evidence and also actually work with religion, instead of against it, in order to find the proof behind the truth.
The truth is already known from the perspective of religion; science just has to catch up.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231169</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233195</id>
	<title>Re:Perspective?</title>
	<author>jbengt</author>
	<datestamp>1244304720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>TFA is terribly confused.  Although it was ostensibly about the obvious fact that software engineering is not the same thing as computer science, it instead spent a lot of time talking about whether or not software engineering is really an engineering discipline. Then it asks questions with false premises, like: <p><div class="quote"><p>Why can't software engineering have more rigorous results, like the other parts of computer science?</p></div><p>(hint, engineering!=science, if you can't see the obvious, read your own article headline)<br>
<br>When it says things like:</p><p><div class="quote"><p>No concept is precisely defined. . . . We believed that structured programming was the answer. Then we put faith in fourth-generation languages, then object-oriented methods, then extreme programming, and now maybe open source.</p></div><p>then you know it is even more confused, using debates about improvements in languages, language paradigms, work/management methods, and licensing types to try to show that software engineering is not rigorous science. That is like comparing varieties of apples, oranges, bananas, and pears in order to make the point that plants are not safety-tested automobiles.</p></div>
	</htmltext>
<tokenext>TFA is terribly confused .
Although it was ostensibly about the obvious fact that software engineering is not the same thing as computer science , it instead spent a lot of time talking about whether or not software engineering is really an engineering discipline .
Then it asks questions with false premises , like : Why ca n't software engineering have more rigorous results , like the other parts of computer science ?
( hint , engineering ! = science , if you ca n't see the obvious , read your own article headline ) When it says things like : No concept is precisely defined .
. .
. We believed that structured programming was the answer .
Then we put faith in fourth-generation languages , then object-oriented methods , then extreme programming , and now maybe open source.then you know it is even more confused , using debates about improvements in languages , language paradigms , work/management methods , and licensing types to try to show that software engineering is not rigorous science .
That is like comparing varieties of apples , oranges , bananas , and pears in order to make the point that plants are not safety-tested automobiles .</tokentext>
<sentencetext>TFA is terribly confused.
Although it was ostensibly about the obvious fact that software engineering is not the same thing as computer science, it instead spent a lot of time talking about whether or not software engineering is really an engineering discipline.
Then it asks questions with false premises, like: Why can't software engineering have more rigorous results, like the other parts of computer science?
(hint, engineering!=science, if you can't see the obvious, read your own article headline)
When it says things like:No concept is precisely defined.
. .
. We believed that structured programming was the answer.
Then we put faith in fourth-generation languages, then object-oriented methods, then extreme programming, and now maybe open source.then you know it is even more confused, using debates about improvements in languages, language paradigms, work/management methods, and licensing types to try to show that software engineering is not rigorous science.
That is like comparing varieties of apples, oranges, bananas, and pears in order to make the point that plants are not safety-tested automobiles.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231699</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244291640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yes, software "engineering" exists, but the sad truth is that most softwares are not "engineered" but build by mere analogy to what is considered as "working", without questioning the resulting design, responses to new induced constraints, etc.<br>There are some domains where the resulting quality level is incredebly low, most of the time they are domains of incredible mediocrity regarding the quality of service rendered to the final user.</p></htmltext>
<tokenext>Yes , software " engineering " exists , but the sad truth is that most softwares are not " engineered " but build by mere analogy to what is considered as " working " , without questioning the resulting design , responses to new induced constraints , etc.There are some domains where the resulting quality level is incredebly low , most of the time they are domains of incredible mediocrity regarding the quality of service rendered to the final user .</tokentext>
<sentencetext>Yes, software "engineering" exists, but the sad truth is that most softwares are not "engineered" but build by mere analogy to what is considered as "working", without questioning the resulting design, responses to new induced constraints, etc.There are some domains where the resulting quality level is incredebly low, most of the time they are domains of incredible mediocrity regarding the quality of service rendered to the final user.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619</id>
	<title>Software Engineering is trying</title>
	<author>mad zambian</author>
	<datestamp>1244230560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>.. to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be. Writing software is a creative process, arguably even an artistic one. Well understood rules can be followed,  provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.<br>Computer Science compared to Software Engineering?<br>Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.<br>Engineering aeronautics is all about building the damn aircraft.</p></htmltext>
<tokenext>.. to become a rigorous engineering discipline .
It 's not quite there yet .
I am not convinced that it ever will be .
Writing software is a creative process , arguably even an artistic one .
Well understood rules can be followed , provably correct algorithms applied , formal design methods used , but it is still a human creative process , and as such , I suspect inherently non-rigorous.Computer Science compared to Software Engineering ? Think aeronautics .
The science of aeronautics ponders the laws of aerodynamics and the laws of flight.Engineering aeronautics is all about building the damn aircraft .</tokentext>
<sentencetext>.. to become a rigorous engineering discipline.
It's not quite there yet.
I am not convinced that it ever will be.
Writing software is a creative process, arguably even an artistic one.
Well understood rules can be followed,  provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.Computer Science compared to Software Engineering?Think aeronautics.
The science of aeronautics ponders the laws of aerodynamics and the laws of flight.Engineering aeronautics is all about building the damn aircraft.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230803</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>mcrbids</author>
	<datestamp>1244319480000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p><i>Going by the wikipedia definition, decisions made in typical software development cycles don't seem to rely on a justification based mathematical or physical analysis. Admittedly I might be generalising, but is it more of a soft-skill then?</i></p><p>That's just horsepucky.</p><p>The only reason it seems the way you mention is that software processing cycles are so ridiculously cheap compared to, say, 3" C-Channel girders. But just today, I was doing some engineering to develop a distributed, self-healing clustering file system. Specifically, I was doing performance analysis of different approach, doing a base unit of 1,000 simple file reads. That is most *definitely* a physical analysis - performance tuning always is. But do I care about each individual line? Not really. Do I do extensive analysis of each individual element? Not by a long shot, simply because the actual, real, overall cost of the software is so low.</p><p>We host highly complex, vertical-market database solutions. We have a pretty decent hardware cluster comprising some $25,000 in whitebox rackmount equipment. A nice half-rack of stuff. And another $10k or so for a failover DR scenario. But compared to the number of customers we service, and the size of my company, that's an insignificant investment, yet we are overbuilt at least 400\%!</p><p>If 3" C-Channel cost $0.05 per linear foot, how much checking would you do beyond "good enough"?</p></htmltext>
<tokenext>Going by the wikipedia definition , decisions made in typical software development cycles do n't seem to rely on a justification based mathematical or physical analysis .
Admittedly I might be generalising , but is it more of a soft-skill then ? That 's just horsepucky.The only reason it seems the way you mention is that software processing cycles are so ridiculously cheap compared to , say , 3 " C-Channel girders .
But just today , I was doing some engineering to develop a distributed , self-healing clustering file system .
Specifically , I was doing performance analysis of different approach , doing a base unit of 1,000 simple file reads .
That is most * definitely * a physical analysis - performance tuning always is .
But do I care about each individual line ?
Not really .
Do I do extensive analysis of each individual element ?
Not by a long shot , simply because the actual , real , overall cost of the software is so low.We host highly complex , vertical-market database solutions .
We have a pretty decent hardware cluster comprising some $ 25,000 in whitebox rackmount equipment .
A nice half-rack of stuff .
And another $ 10k or so for a failover DR scenario .
But compared to the number of customers we service , and the size of my company , that 's an insignificant investment , yet we are overbuilt at least 400 \ % ! If 3 " C-Channel cost $ 0.05 per linear foot , how much checking would you do beyond " good enough " ?</tokentext>
<sentencetext>Going by the wikipedia definition, decisions made in typical software development cycles don't seem to rely on a justification based mathematical or physical analysis.
Admittedly I might be generalising, but is it more of a soft-skill then?That's just horsepucky.The only reason it seems the way you mention is that software processing cycles are so ridiculously cheap compared to, say, 3" C-Channel girders.
But just today, I was doing some engineering to develop a distributed, self-healing clustering file system.
Specifically, I was doing performance analysis of different approach, doing a base unit of 1,000 simple file reads.
That is most *definitely* a physical analysis - performance tuning always is.
But do I care about each individual line?
Not really.
Do I do extensive analysis of each individual element?
Not by a long shot, simply because the actual, real, overall cost of the software is so low.We host highly complex, vertical-market database solutions.
We have a pretty decent hardware cluster comprising some $25,000 in whitebox rackmount equipment.
A nice half-rack of stuff.
And another $10k or so for a failover DR scenario.
But compared to the number of customers we service, and the size of my company, that's an insignificant investment, yet we are overbuilt at least 400\%!If 3" C-Channel cost $0.05 per linear foot, how much checking would you do beyond "good enough"?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717</id>
	<title>Re:Perspective?</title>
	<author>Anonymous</author>
	<datestamp>1244231940000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Software Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. I am not convinced that it ever will be. Writing software is a creative process, arguably even an artistic one. Well understood rules can be followed, provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.<br>Computer Science compared to Software Engineering?<br>Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.<br>Engineering aeronautics is all about building the damn aircraft.</p></htmltext>
<tokenext>Software Engineering is trying to become a rigorous engineering discipline .
It 's not quite there yet .
I am not convinced that it ever will be .
Writing software is a creative process , arguably even an artistic one .
Well understood rules can be followed , provably correct algorithms applied , formal design methods used , but it is still a human creative process , and as such , I suspect inherently non-rigorous.Computer Science compared to Software Engineering ? Think aeronautics .
The science of aeronautics ponders the laws of aerodynamics and the laws of flight.Engineering aeronautics is all about building the damn aircraft .</tokentext>
<sentencetext>Software Engineering is trying to become a rigorous engineering discipline.
It's not quite there yet.
I am not convinced that it ever will be.
Writing software is a creative process, arguably even an artistic one.
Well understood rules can be followed, provably correct algorithms applied, formal design methods used, but it is still a human creative process, and as such, I suspect inherently non-rigorous.Computer Science compared to Software Engineering?Think aeronautics.
The science of aeronautics ponders the laws of aerodynamics and the laws of flight.Engineering aeronautics is all about building the damn aircraft.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28241535</id>
	<title>Real vs Ideal</title>
	<author>hicksw</author>
	<datestamp>1244392080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Computer Scientists are reductionists - If a problem is too hard to solve, simplify it by throwing some of it away, until what is left CAN be solved.  The result may still be of some use.</p><p>Software engineers make systems for real world use - If a problem is too hard, throw another programmer on the fire.</p><p>FOSS engineers can reduce the problem and call it version</p></htmltext>
<tokenext>Computer Scientists are reductionists - If a problem is too hard to solve , simplify it by throwing some of it away , until what is left CAN be solved .
The result may still be of some use.Software engineers make systems for real world use - If a problem is too hard , throw another programmer on the fire.FOSS engineers can reduce the problem and call it version</tokentext>
<sentencetext>Computer Scientists are reductionists - If a problem is too hard to solve, simplify it by throwing some of it away, until what is left CAN be solved.
The result may still be of some use.Software engineers make systems for real world use - If a problem is too hard, throw another programmer on the fire.FOSS engineers can reduce the problem and call it version</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232929</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>janwedekind</author>
	<datestamp>1244303340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That's the difference between <b>experience</b> and <b>knowledge</b>. Knowledge can save you a lot of bad experience, but it only brings you this far.</p></htmltext>
<tokenext>That 's the difference between experience and knowledge .
Knowledge can save you a lot of bad experience , but it only brings you this far .</tokentext>
<sentencetext>That's the difference between experience and knowledge.
Knowledge can save you a lot of bad experience, but it only brings you this far.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230691</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28249793</id>
	<title>But of course...</title>
	<author>tekshogun</author>
	<datestamp>1244469240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Of course software engineering and computer science are different, but only in the sense that a square is a rectangle but not all rectangles are squares.  Computer science goes FAR beyond software development/engineering and maintenance; and no I don't mean general information technology.  For example, the hardest part of producing software comes before the development phase, solving the problem.  Any engineer or team of engineers can take a solution and turn it into code but if they have no solution, it does not matter how much they know about<nobr> <wbr></nobr>.NET, JAVA, php, or whatever, they will sit around like every other person beating their heads about how to apply their discipline.  There is no argument here.  You have excellent computer scientist that can solve problems but aren't very code savvy (and don't really need to be) and you have software developers that can take a solution and bust out code as if they were acing some simple test.  You then have people that can do both.</htmltext>
<tokenext>Of course software engineering and computer science are different , but only in the sense that a square is a rectangle but not all rectangles are squares .
Computer science goes FAR beyond software development/engineering and maintenance ; and no I do n't mean general information technology .
For example , the hardest part of producing software comes before the development phase , solving the problem .
Any engineer or team of engineers can take a solution and turn it into code but if they have no solution , it does not matter how much they know about .NET , JAVA , php , or whatever , they will sit around like every other person beating their heads about how to apply their discipline .
There is no argument here .
You have excellent computer scientist that can solve problems but are n't very code savvy ( and do n't really need to be ) and you have software developers that can take a solution and bust out code as if they were acing some simple test .
You then have people that can do both .</tokentext>
<sentencetext>Of course software engineering and computer science are different, but only in the sense that a square is a rectangle but not all rectangles are squares.
Computer science goes FAR beyond software development/engineering and maintenance; and no I don't mean general information technology.
For example, the hardest part of producing software comes before the development phase, solving the problem.
Any engineer or team of engineers can take a solution and turn it into code but if they have no solution, it does not matter how much they know about .NET, JAVA, php, or whatever, they will sit around like every other person beating their heads about how to apply their discipline.
There is no argument here.
You have excellent computer scientist that can solve problems but aren't very code savvy (and don't really need to be) and you have software developers that can take a solution and bust out code as if they were acing some simple test.
You then have people that can do both.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230853</id>
	<title>Martin Fowlers - A New Methodology</title>
	<author>Anonymous</author>
	<datestamp>1244320440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Reminds me of Martin Fowlers "A New Methodology" paper.</p><p>http://martinfowler.com/articles/newMethodology.html</p></htmltext>
<tokenext>Reminds me of Martin Fowlers " A New Methodology " paper.http : //martinfowler.com/articles/newMethodology.html</tokentext>
<sentencetext>Reminds me of Martin Fowlers "A New Methodology" paper.http://martinfowler.com/articles/newMethodology.html</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557</id>
	<title>You're not Engineers. Get over it.</title>
	<author>Anonymous</author>
	<datestamp>1244229480000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext><p>Look, there is nothing wrong with being a programmer. Just as a good tech gets pissed off when he sees a 'nail technician', real engineers laugh at the IT crowd.</p><p>No engineering degree = no engineer.</p></htmltext>
<tokenext>Look , there is nothing wrong with being a programmer .
Just as a good tech gets pissed off when he sees a 'nail technician ' , real engineers laugh at the IT crowd.No engineering degree = no engineer .</tokentext>
<sentencetext>Look, there is nothing wrong with being a programmer.
Just as a good tech gets pissed off when he sees a 'nail technician', real engineers laugh at the IT crowd.No engineering degree = no engineer.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232679</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>pnewhook</author>
	<datestamp>1244301480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>When was the last time you saw your structural engineers do their work from first principles taught at uni, as opposed to spreadsheet design or computer simulation?

The next question is, why should they?</p></div><p>Basically every time that the computer simulation is used. An answer from an algorithm or simulation is only as good as the input to that algorithm or simulation. Doing a basic sanity check on that answer is a must for any good engineer.</p></div>
	</htmltext>
<tokenext>When was the last time you saw your structural engineers do their work from first principles taught at uni , as opposed to spreadsheet design or computer simulation ?
The next question is , why should they ? Basically every time that the computer simulation is used .
An answer from an algorithm or simulation is only as good as the input to that algorithm or simulation .
Doing a basic sanity check on that answer is a must for any good engineer .</tokentext>
<sentencetext>When was the last time you saw your structural engineers do their work from first principles taught at uni, as opposed to spreadsheet design or computer simulation?
The next question is, why should they?Basically every time that the computer simulation is used.
An answer from an algorithm or simulation is only as good as the input to that algorithm or simulation.
Doing a basic sanity check on that answer is a must for any good engineer.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230613</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28239351</id>
	<title>Re:Perspective?</title>
	<author>rghosh</author>
	<datestamp>1244314200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>See also "Computer Software Cannot Be Engineered" by Norman Young which argues that the concept of "Software Engineering," as an engineering discipline, is unfounded, and that "Computer Science" is not science, but mathematics.

"Computer software cannot be engineered because there is no science of computer programs. Science is essential to engineering. The application of scientific models through engineering judgment defines the essence of engineering. Computer programs, as mathematical objects, are not subject to scientific laws. Consequently, by definition, computer software cannot be engineered.<nobr> <wbr></nobr>..."

<a href="http://tech.slashdot.org/comments.pl?sid=1258979&amp;cid=28236833" title="slashdot.org" rel="nofollow">http://tech.slashdot.org/comments.pl?sid=1258979&amp;cid=28236833</a> [slashdot.org]</htmltext>
<tokenext>See also " Computer Software Can not Be Engineered " by Norman Young which argues that the concept of " Software Engineering , " as an engineering discipline , is unfounded , and that " Computer Science " is not science , but mathematics .
" Computer software can not be engineered because there is no science of computer programs .
Science is essential to engineering .
The application of scientific models through engineering judgment defines the essence of engineering .
Computer programs , as mathematical objects , are not subject to scientific laws .
Consequently , by definition , computer software can not be engineered .
... " http : //tech.slashdot.org/comments.pl ? sid = 1258979&amp;cid = 28236833 [ slashdot.org ]</tokentext>
<sentencetext>See also "Computer Software Cannot Be Engineered" by Norman Young which argues that the concept of "Software Engineering," as an engineering discipline, is unfounded, and that "Computer Science" is not science, but mathematics.
"Computer software cannot be engineered because there is no science of computer programs.
Science is essential to engineering.
The application of scientific models through engineering judgment defines the essence of engineering.
Computer programs, as mathematical objects, are not subject to scientific laws.
Consequently, by definition, computer software cannot be engineered.
..."

http://tech.slashdot.org/comments.pl?sid=1258979&amp;cid=28236833 [slashdot.org]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232651</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231781</id>
	<title>Ain't NO new thaing ...</title>
	<author>Anonymous</author>
	<datestamp>1244292600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>199307 Engineering Times - Will High Technology Bring Engineering Disaster? [unverified software applied by unqualified users]<br>199409 Scientific American - Software's Chronic Crisis, W. Wayt Gibbs [software is being written but not by programmers]<br>199409 IEEE Spectrum - Judgment's Subtle Presence [replacing the decisions made by people with pre-programmed ignorance]<br>199703 IEEE Spectrum - Reflections on Complexity, Robert W. Lucky [just because you can does not mean you should]<br>199707 WIRED - Digital Obesity, Nicholas Negroponte ["personal computers" have never been people friendly]<br>199802 WIRED - Productivity Paradox [the numbers, folks, where are the numbers to back up the continued spending?]<br>199707 IEEE Institute - Software Engineering [accreditation of educational programs for "professional" programmers]<br>199800 Walking on Thin Ice by Peter de Jager [how the Y2K problem was created by the bureaucrats, not the programmers]<br>200004 US NRC - Digital Instrumenation Research Plan [the emperor has no software quality assurance program]<br>199907 US NRC- 464th ACRS - Commentary by Dr. Graham Wallis on RETRAN-3D [only "real professors" know what is correct way to "engineer"]<br>200502 US NRC ACRS Sub-C on THP - Commentary by Dr. Graham Wallis on TRACE [user manuals generally suck - DUH! so do most textbooks]<br>199907 No High Tech Training - The Financial Times by Rebecca Christie [a partial explanation of the productivity paradox]<br>200503 How computers make kids dumb - Andrew Orlowski - San Francisco [the title says it all]</p></htmltext>
<tokenext>199307 Engineering Times - Will High Technology Bring Engineering Disaster ?
[ unverified software applied by unqualified users ] 199409 Scientific American - Software 's Chronic Crisis , W. Wayt Gibbs [ software is being written but not by programmers ] 199409 IEEE Spectrum - Judgment 's Subtle Presence [ replacing the decisions made by people with pre-programmed ignorance ] 199703 IEEE Spectrum - Reflections on Complexity , Robert W. Lucky [ just because you can does not mean you should ] 199707 WIRED - Digital Obesity , Nicholas Negroponte [ " personal computers " have never been people friendly ] 199802 WIRED - Productivity Paradox [ the numbers , folks , where are the numbers to back up the continued spending ?
] 199707 IEEE Institute - Software Engineering [ accreditation of educational programs for " professional " programmers ] 199800 Walking on Thin Ice by Peter de Jager [ how the Y2K problem was created by the bureaucrats , not the programmers ] 200004 US NRC - Digital Instrumenation Research Plan [ the emperor has no software quality assurance program ] 199907 US NRC- 464th ACRS - Commentary by Dr. Graham Wallis on RETRAN-3D [ only " real professors " know what is correct way to " engineer " ] 200502 US NRC ACRS Sub-C on THP - Commentary by Dr. Graham Wallis on TRACE [ user manuals generally suck - DUH !
so do most textbooks ] 199907 No High Tech Training - The Financial Times by Rebecca Christie [ a partial explanation of the productivity paradox ] 200503 How computers make kids dumb - Andrew Orlowski - San Francisco [ the title says it all ]</tokentext>
<sentencetext>199307 Engineering Times - Will High Technology Bring Engineering Disaster?
[unverified software applied by unqualified users]199409 Scientific American - Software's Chronic Crisis, W. Wayt Gibbs [software is being written but not by programmers]199409 IEEE Spectrum - Judgment's Subtle Presence [replacing the decisions made by people with pre-programmed ignorance]199703 IEEE Spectrum - Reflections on Complexity, Robert W. Lucky [just because you can does not mean you should]199707 WIRED - Digital Obesity, Nicholas Negroponte ["personal computers" have never been people friendly]199802 WIRED - Productivity Paradox [the numbers, folks, where are the numbers to back up the continued spending?
]199707 IEEE Institute - Software Engineering [accreditation of educational programs for "professional" programmers]199800 Walking on Thin Ice by Peter de Jager [how the Y2K problem was created by the bureaucrats, not the programmers]200004 US NRC - Digital Instrumenation Research Plan [the emperor has no software quality assurance program]199907 US NRC- 464th ACRS - Commentary by Dr. Graham Wallis on RETRAN-3D [only "real professors" know what is correct way to "engineer"]200502 US NRC ACRS Sub-C on THP - Commentary by Dr. Graham Wallis on TRACE [user manuals generally suck - DUH!
so do most textbooks]199907 No High Tech Training - The Financial Times by Rebecca Christie [a partial explanation of the productivity paradox]200503 How computers make kids dumb - Andrew Orlowski - San Francisco [the title says it all]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231871</id>
	<title>!(Science != Empirical)</title>
	<author>jonaskoelker</author>
	<datestamp>1244294100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Mature engineering fields have standards and codes of practice, both science-based and empirically derived.</p></div><p>How is science-based != empirical?</p><p>It's math (and the math-ish parts of CS) which stick out as the sore thumb, in that we think of them as science but their practitioners occupy themselves with proofs rather than experimental evidence.</p><p>Math (and CS) are the oddballs, not the set {every other science}.  Or do you think that math+CS got it right, and physics, chemistry, biology, astronomy, medicine, geology, (softening up) economy, archeology, anthropology, sociology, ethnography, history, psychology,<nobr> <wbr></nobr>... got it almost right but still has that unfortunate aspect where they need to look at the real world to verify their ideas?</p></div>
	</htmltext>
<tokenext>Mature engineering fields have standards and codes of practice , both science-based and empirically derived.How is science-based ! = empirical ? It 's math ( and the math-ish parts of CS ) which stick out as the sore thumb , in that we think of them as science but their practitioners occupy themselves with proofs rather than experimental evidence.Math ( and CS ) are the oddballs , not the set { every other science } .
Or do you think that math + CS got it right , and physics , chemistry , biology , astronomy , medicine , geology , ( softening up ) economy , archeology , anthropology , sociology , ethnography , history , psychology , ... got it almost right but still has that unfortunate aspect where they need to look at the real world to verify their ideas ?</tokentext>
<sentencetext>Mature engineering fields have standards and codes of practice, both science-based and empirically derived.How is science-based != empirical?It's math (and the math-ish parts of CS) which stick out as the sore thumb, in that we think of them as science but their practitioners occupy themselves with proofs rather than experimental evidence.Math (and CS) are the oddballs, not the set {every other science}.
Or do you think that math+CS got it right, and physics, chemistry, biology, astronomy, medicine, geology, (softening up) economy, archeology, anthropology, sociology, ethnography, history, psychology, ... got it almost right but still has that unfortunate aspect where they need to look at the real world to verify their ideas?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230897</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231017</id>
	<title>well, duh</title>
	<author>dirtyhippie</author>
	<datestamp>1244280180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Seriously. CS asks questions of the form will X accomplish Y? Software Engineering asks questions of the form "what is the best way X to accomplish y"?</p><p>Nothing to see here, move along.</p></htmltext>
<tokenext>Seriously .
CS asks questions of the form will X accomplish Y ?
Software Engineering asks questions of the form " what is the best way X to accomplish y " ? Nothing to see here , move along .</tokentext>
<sentencetext>Seriously.
CS asks questions of the form will X accomplish Y?
Software Engineering asks questions of the form "what is the best way X to accomplish y"?Nothing to see here, move along.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28237401</id>
	<title>Squishy?</title>
	<author>Tablizer</author>
	<datestamp>1244291700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>"The reason is that humans are <b>squishy</b> and frustrating and unpredictable."</p></div> </blockquote><p>Well! You are not going to get any science if you make fun of our weight and call us names.<br>
&nbsp; &nbsp; &nbsp;</p></div>
	</htmltext>
<tokenext>" The reason is that humans are squishy and frustrating and unpredictable .
" Well !
You are not going to get any science if you make fun of our weight and call us names .
     </tokentext>
<sentencetext>"The reason is that humans are squishy and frustrating and unpredictable.
" Well!
You are not going to get any science if you make fun of our weight and call us names.
     
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28239105</id>
	<title>Re:Software Development is actually an art</title>
	<author>Anonymous</author>
	<datestamp>1244310000000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Software development seems to be no more of an art than graphic design, IMHO. A phone book is an example of graphic design, but so is the advertising poster of an artistic movie. The artistic influence in a certain project may vary, but the method itself is not art, and the end product isn't necessarily art, especially if the main reason to design it was to perform a non artistic function.</p><p>If course, I guess we could spend all day arguing exactly what art is, so I'll try to stop now.</p></htmltext>
<tokenext>Software development seems to be no more of an art than graphic design , IMHO .
A phone book is an example of graphic design , but so is the advertising poster of an artistic movie .
The artistic influence in a certain project may vary , but the method itself is not art , and the end product is n't necessarily art , especially if the main reason to design it was to perform a non artistic function.If course , I guess we could spend all day arguing exactly what art is , so I 'll try to stop now .</tokentext>
<sentencetext>Software development seems to be no more of an art than graphic design, IMHO.
A phone book is an example of graphic design, but so is the advertising poster of an artistic movie.
The artistic influence in a certain project may vary, but the method itself is not art, and the end product isn't necessarily art, especially if the main reason to design it was to perform a non artistic function.If course, I guess we could spend all day arguing exactly what art is, so I'll try to stop now.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28241833</id>
	<title>Depends on the school.</title>
	<author>Anonymous</author>
	<datestamp>1244395080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The difference between "Computer Science" and "Software Engineering" depends on the school, and nothing else. There is no standardized curriculum for computer science nor for software engineering. My own experience has been quite different from that of the author. At my school, software engineering is about applying the theory which is computer science, and software engineers are required to take the same courses as computer scientists as well as additional lab courses in which they learn software engineering best practices; by contrast, those who sign up for purely computer science are exposed only to the theory and often end up writing code in which variable names are enigmatic and uninformative (e.g. "alpha", "beta", "theta") and which do not take advantage of good OOP design methodology.</p></htmltext>
<tokenext>The difference between " Computer Science " and " Software Engineering " depends on the school , and nothing else .
There is no standardized curriculum for computer science nor for software engineering .
My own experience has been quite different from that of the author .
At my school , software engineering is about applying the theory which is computer science , and software engineers are required to take the same courses as computer scientists as well as additional lab courses in which they learn software engineering best practices ; by contrast , those who sign up for purely computer science are exposed only to the theory and often end up writing code in which variable names are enigmatic and uninformative ( e.g .
" alpha " , " beta " , " theta " ) and which do not take advantage of good OOP design methodology .</tokentext>
<sentencetext>The difference between "Computer Science" and "Software Engineering" depends on the school, and nothing else.
There is no standardized curriculum for computer science nor for software engineering.
My own experience has been quite different from that of the author.
At my school, software engineering is about applying the theory which is computer science, and software engineers are required to take the same courses as computer scientists as well as additional lab courses in which they learn software engineering best practices; by contrast, those who sign up for purely computer science are exposed only to the theory and often end up writing code in which variable names are enigmatic and uninformative (e.g.
"alpha", "beta", "theta") and which do not take advantage of good OOP design methodology.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231561</id>
	<title>Re:Software Engineering is trying</title>
	<author>cvd6262</author>
	<datestamp>1244289240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My first CS professor told me that there are nearly infinite ways to accomplish any single task on a computer. He felt this meant computer science and software engineering were arts...</p><p>"But we don't call them art because we like paychecks."</p></htmltext>
<tokenext>My first CS professor told me that there are nearly infinite ways to accomplish any single task on a computer .
He felt this meant computer science and software engineering were arts... " But we do n't call them art because we like paychecks .
"</tokentext>
<sentencetext>My first CS professor told me that there are nearly infinite ways to accomplish any single task on a computer.
He felt this meant computer science and software engineering were arts..."But we don't call them art because we like paychecks.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234177</id>
	<title>Re:Before we get all sweaty about terms</title>
	<author>aldo.gs</author>
	<datestamp>1244311200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Maybe he doesn't mean that they do it with the intent of predicting phenomena, but that they establish the postulates (inspired by something real), then do some work and then produce something that can be used as a model. That does happen (quite often).</p></htmltext>
<tokenext>Maybe he does n't mean that they do it with the intent of predicting phenomena , but that they establish the postulates ( inspired by something real ) , then do some work and then produce something that can be used as a model .
That does happen ( quite often ) .</tokentext>
<sentencetext>Maybe he doesn't mean that they do it with the intent of predicting phenomena, but that they establish the postulates (inspired by something real), then do some work and then produce something that can be used as a model.
That does happen (quite often).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231133</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28237519</id>
	<title>Re:First!</title>
	<author>Tablizer</author>
	<datestamp>1244292840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p> Wouldn't it still be as much a science as say... human psychology?</p></div></blockquote><p>Perhaps. Psychology is also a "squishy" science to a large degree. Software engineering is a <b>combination of psychology and economics</b>. It's about psychology because humans have to maintain the code and how they relate to the code is largely about how they think about the code (and schemas). It's also a taste of economics because it involves maximizing use of limited resources, such as time, labor, and equipment.</p><p>Economics is in a similar boat to the computer field: there are models that can be mathematically tested, but a lot of the variables are about human behavior, which takes us right back to psychology. For example, how will people react to bank closures? Will they buy a lot less or a little less? And should the models optimize total wealth or also try to smooth income (reduce bubbles)? These are questions pure math and science cannot answer.</p><p>Economics generally failed to predict the mortgage meltdown. And we've had a long time since the Great Depression to improve economics. (To it's credit, things could have been a lot worse this time, but this is perhaps learning by real trial-and-error, not lab trials. It's not fun being giant guinie pigs)</p><p>Another problem is that each human brain is different. Even if you find a way to model an average or aggregate, you still have to deal with individuals in software engineering and with regard to who runs a big company (economics).<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</p></div>
	</htmltext>
<tokenext>Would n't it still be as much a science as say... human psychology ? Perhaps .
Psychology is also a " squishy " science to a large degree .
Software engineering is a combination of psychology and economics .
It 's about psychology because humans have to maintain the code and how they relate to the code is largely about how they think about the code ( and schemas ) .
It 's also a taste of economics because it involves maximizing use of limited resources , such as time , labor , and equipment.Economics is in a similar boat to the computer field : there are models that can be mathematically tested , but a lot of the variables are about human behavior , which takes us right back to psychology .
For example , how will people react to bank closures ?
Will they buy a lot less or a little less ?
And should the models optimize total wealth or also try to smooth income ( reduce bubbles ) ?
These are questions pure math and science can not answer.Economics generally failed to predict the mortgage meltdown .
And we 've had a long time since the Great Depression to improve economics .
( To it 's credit , things could have been a lot worse this time , but this is perhaps learning by real trial-and-error , not lab trials .
It 's not fun being giant guinie pigs ) Another problem is that each human brain is different .
Even if you find a way to model an average or aggregate , you still have to deal with individuals in software engineering and with regard to who runs a big company ( economics ) .
           </tokentext>
<sentencetext> Wouldn't it still be as much a science as say... human psychology?Perhaps.
Psychology is also a "squishy" science to a large degree.
Software engineering is a combination of psychology and economics.
It's about psychology because humans have to maintain the code and how they relate to the code is largely about how they think about the code (and schemas).
It's also a taste of economics because it involves maximizing use of limited resources, such as time, labor, and equipment.Economics is in a similar boat to the computer field: there are models that can be mathematically tested, but a lot of the variables are about human behavior, which takes us right back to psychology.
For example, how will people react to bank closures?
Will they buy a lot less or a little less?
And should the models optimize total wealth or also try to smooth income (reduce bubbles)?
These are questions pure math and science cannot answer.Economics generally failed to predict the mortgage meltdown.
And we've had a long time since the Great Depression to improve economics.
(To it's credit, things could have been a lot worse this time, but this is perhaps learning by real trial-and-error, not lab trials.
It's not fun being giant guinie pigs)Another problem is that each human brain is different.
Even if you find a way to model an average or aggregate, you still have to deal with individuals in software engineering and with regard to who runs a big company (economics).
           
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230519</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232201</id>
	<title>programmers are not engineers</title>
	<author>Anonymous</author>
	<datestamp>1244298060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I used to laugh when programmers started calling themselves "software engineers". It reminded me of the joke about "sanitation engineers". Now this kind of title inflation is the norm, but don't kid yourself, you are not a real engineer just because it says so on your cube entrance.</p></htmltext>
<tokenext>I used to laugh when programmers started calling themselves " software engineers " .
It reminded me of the joke about " sanitation engineers " .
Now this kind of title inflation is the norm , but do n't kid yourself , you are not a real engineer just because it says so on your cube entrance .</tokentext>
<sentencetext>I used to laugh when programmers started calling themselves "software engineers".
It reminded me of the joke about "sanitation engineers".
Now this kind of title inflation is the norm, but don't kid yourself, you are not a real engineer just because it says so on your cube entrance.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233509</id>
	<title>Re:Perspective?</title>
	<author>ThePhilips</author>
	<datestamp>1244306520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p><div class="quote"><p> Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.</p> </div><p> I think you're confusing (or conflating) science with mathematics. But don't feel bad; people do this all the time.</p> </div><p> Actually that one was a stone at physics<nobr> <wbr></nobr>;)

</p><p> Math is abstract by definition (hey, I'm in some part a mathematician too, applied one). Math doesn't deal with real world. With no world at all. Math *allows* one to create their own world - and that's how physicists routinely abuse math all the time.

</p><p> And in fact that what makes science the way it is: <a href="http://en.wikipedia.org/wiki/Scientific\_method" title="wikipedia.org">scientific method</a> [wikipedia.org] to work, subject has to be understood by a human. And inner working of human understanding relies on several "lies": generalization and interpretation among others. In other words science can have rules and methods - because those are treats of human behavior and cognition. Thus scientists often sees its subject as they want to see it. Because they can. (*)

</p><p> Engineering's "it has to work" is pretty unnatural to our brain. It inhibits engineers from seeing the reality the way their brains try to see it.

</p><p> (*) My classical example is research of "time travel": any 5yo kid understands that "time" is only part of how we observe the world around us, it is part of our cognitive process - not part of the world. Yet, since math models allow to actually put t (time) at left side of equation, some start interpreting it as (variable) part of the world.</p><p><div class="quote"><p> In engineering, you are generally working with tools and materials whose behavior is well understood, so you can concentrate on design. With software development, this isn't generally true.</p> </div><p> I wanted to object to that, but then I read it again, seen the keyword "understood" and accepted what you way.

</p><p> Because harsh reality is that many engineers are "working with materials whose behavior is well understood", yet the behavior is not well "known". Software engineers on other side, work with materials which are "known" (hey, it all can be modeled to the bits), yet they are poorly "understood" because of our limited brain capacity.</p><p><div class="quote"><p> Now if we could only get the computer field to adopt the same definitions that other fields of engineering, science and mat use. But that isn't going to happen any time soon.</p> </div><p> Software engineering is very very young. It freaked me out when in my versity times one prof said that applied algebra is very young, youngest of all mathematics - only *hundred* years old.

</p><p> As software engineering would be evolving, the many application fields would be branching off. We can safely say that Web programming is going its own separate way. Decade before, finance programming went its own way too. Probably some other unknown to me fields too. The branching is happening precisely because some rules in the fields start to crystallize, making them distinct from general software engineering.</p></div>
	</htmltext>
<tokenext>Science ( like religion ) is in some sort of ideal world , vacuum , where all is simple and described by a formula .
I think you 're confusing ( or conflating ) science with mathematics .
But do n't feel bad ; people do this all the time .
Actually that one was a stone at physics ; ) Math is abstract by definition ( hey , I 'm in some part a mathematician too , applied one ) .
Math does n't deal with real world .
With no world at all .
Math * allows * one to create their own world - and that 's how physicists routinely abuse math all the time .
And in fact that what makes science the way it is : scientific method [ wikipedia.org ] to work , subject has to be understood by a human .
And inner working of human understanding relies on several " lies " : generalization and interpretation among others .
In other words science can have rules and methods - because those are treats of human behavior and cognition .
Thus scientists often sees its subject as they want to see it .
Because they can .
( * ) Engineering 's " it has to work " is pretty unnatural to our brain .
It inhibits engineers from seeing the reality the way their brains try to see it .
( * ) My classical example is research of " time travel " : any 5yo kid understands that " time " is only part of how we observe the world around us , it is part of our cognitive process - not part of the world .
Yet , since math models allow to actually put t ( time ) at left side of equation , some start interpreting it as ( variable ) part of the world .
In engineering , you are generally working with tools and materials whose behavior is well understood , so you can concentrate on design .
With software development , this is n't generally true .
I wanted to object to that , but then I read it again , seen the keyword " understood " and accepted what you way .
Because harsh reality is that many engineers are " working with materials whose behavior is well understood " , yet the behavior is not well " known " .
Software engineers on other side , work with materials which are " known " ( hey , it all can be modeled to the bits ) , yet they are poorly " understood " because of our limited brain capacity .
Now if we could only get the computer field to adopt the same definitions that other fields of engineering , science and mat use .
But that is n't going to happen any time soon .
Software engineering is very very young .
It freaked me out when in my versity times one prof said that applied algebra is very young , youngest of all mathematics - only * hundred * years old .
As software engineering would be evolving , the many application fields would be branching off .
We can safely say that Web programming is going its own separate way .
Decade before , finance programming went its own way too .
Probably some other unknown to me fields too .
The branching is happening precisely because some rules in the fields start to crystallize , making them distinct from general software engineering .</tokentext>
<sentencetext> Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.
I think you're confusing (or conflating) science with mathematics.
But don't feel bad; people do this all the time.
Actually that one was a stone at physics ;)

 Math is abstract by definition (hey, I'm in some part a mathematician too, applied one).
Math doesn't deal with real world.
With no world at all.
Math *allows* one to create their own world - and that's how physicists routinely abuse math all the time.
And in fact that what makes science the way it is: scientific method [wikipedia.org] to work, subject has to be understood by a human.
And inner working of human understanding relies on several "lies": generalization and interpretation among others.
In other words science can have rules and methods - because those are treats of human behavior and cognition.
Thus scientists often sees its subject as they want to see it.
Because they can.
(*)

 Engineering's "it has to work" is pretty unnatural to our brain.
It inhibits engineers from seeing the reality the way their brains try to see it.
(*) My classical example is research of "time travel": any 5yo kid understands that "time" is only part of how we observe the world around us, it is part of our cognitive process - not part of the world.
Yet, since math models allow to actually put t (time) at left side of equation, some start interpreting it as (variable) part of the world.
In engineering, you are generally working with tools and materials whose behavior is well understood, so you can concentrate on design.
With software development, this isn't generally true.
I wanted to object to that, but then I read it again, seen the keyword "understood" and accepted what you way.
Because harsh reality is that many engineers are "working with materials whose behavior is well understood", yet the behavior is not well "known".
Software engineers on other side, work with materials which are "known" (hey, it all can be modeled to the bits), yet they are poorly "understood" because of our limited brain capacity.
Now if we could only get the computer field to adopt the same definitions that other fields of engineering, science and mat use.
But that isn't going to happen any time soon.
Software engineering is very very young.
It freaked me out when in my versity times one prof said that applied algebra is very young, youngest of all mathematics - only *hundred* years old.
As software engineering would be evolving, the many application fields would be branching off.
We can safely say that Web programming is going its own separate way.
Decade before, finance programming went its own way too.
Probably some other unknown to me fields too.
The branching is happening precisely because some rules in the fields start to crystallize, making them distinct from general software engineering.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232651</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28235583</id>
	<title>Re:Before we get all sweaty about terms</title>
	<author>RabidTimmy</author>
	<datestamp>1244320500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p> If you can be counted on to design a system that reliably works without killing people, you're an engineer.</p>  </div><p>So are defense contractors automatically disqualified from the engineering fields?</p></div>
	</htmltext>
<tokenext>If you can be counted on to design a system that reliably works without killing people , you 're an engineer .
So are defense contractors automatically disqualified from the engineering fields ?</tokentext>
<sentencetext> If you can be counted on to design a system that reliably works without killing people, you're an engineer.
So are defense contractors automatically disqualified from the engineering fields?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230949</id>
	<title>Elitist crap</title>
	<author>Anonymous</author>
	<datestamp>1244279100000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>The TFA, and any other such articles, amount to nothing other than navel<br>gazing.  People who think they are a scientist/artist/whatever, thinking it<br>makes them more leet if they are able to exclude others.</p><p>The elitist attitude of contemporary science is something which I hold in<br>extremely deep contempt, to be blunt.  Programming might not be considered a<br>pure science, <i>if</i> they want to try and claim that <i>anything</i> that<br>human beings do is completely free of emotion.  Nothing does, so by that<br>definition, nothing is a pure science.</p><p>If you focus on the purely mechanistic/mathematical aspects of programming,<br>that can be considered science.  If you focus on the emotion, or the level of<br>inspiration which sentience is considered a prerequisite for, it's an art.<br>Use whichever term for yourself that you want, or better yet, just be<br><b>you</b>.</p><p>Remember Napoleon, people.  The greatest Emperors crown themselves.</p></htmltext>
<tokenext>The TFA , and any other such articles , amount to nothing other than navelgazing .
People who think they are a scientist/artist/whatever , thinking itmakes them more leet if they are able to exclude others.The elitist attitude of contemporary science is something which I hold inextremely deep contempt , to be blunt .
Programming might not be considered apure science , if they want to try and claim that anything thathuman beings do is completely free of emotion .
Nothing does , so by thatdefinition , nothing is a pure science.If you focus on the purely mechanistic/mathematical aspects of programming,that can be considered science .
If you focus on the emotion , or the level ofinspiration which sentience is considered a prerequisite for , it 's an art.Use whichever term for yourself that you want , or better yet , just beyou.Remember Napoleon , people .
The greatest Emperors crown themselves .</tokentext>
<sentencetext>The TFA, and any other such articles, amount to nothing other than navelgazing.
People who think they are a scientist/artist/whatever, thinking itmakes them more leet if they are able to exclude others.The elitist attitude of contemporary science is something which I hold inextremely deep contempt, to be blunt.
Programming might not be considered apure science, if they want to try and claim that anything thathuman beings do is completely free of emotion.
Nothing does, so by thatdefinition, nothing is a pure science.If you focus on the purely mechanistic/mathematical aspects of programming,that can be considered science.
If you focus on the emotion, or the level ofinspiration which sentience is considered a prerequisite for, it's an art.Use whichever term for yourself that you want, or better yet, just beyou.Remember Napoleon, people.
The greatest Emperors crown themselves.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232283</id>
	<title>Not engineering, but it SHOULD be</title>
	<author>mrnick</author>
	<datestamp>1244298660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Most undergraduate students don't have enough time to learn the basics of computer programming, never mind software design.</p><p>As I stated in a separate post in this same thread people with IT degrees should be doing the majority of programing.  When I got my undergraduate there was no IT degree, if you wanted to work in IT you got a BS in CS.</p><p>In a perfect world, Computer Scientists (like myself, MS in CS) would be doing research and developing new advancements in CS.</p><p>Regardless, in graduate programing courses you learn things like how to mathematically analysis different algorithms to determine which are superior.  How much of this goes into modern coding?  Very little, if any.</p><p>Cheaper, faster, easier is the motto of most programs written today.  This increases with the more business management that gets thrown into the mix.  That's how something like MS Windows Vista comes into existence. Give any real Computer Scientist the project along with the right to choose a developmental path and almost all of them would opt to scrap it and start over.  But either extreme is bad in one we get crappy software and the other nothing is ever released.  Currently we lean towards crappy software because hardware has developed so much faster than software.  If some physical law, universal law, prevented computers from having over 1 GB RAM and 100 MHZ CPU, then the focus would have shifted and I would still have 8 programs running on my computer and would be experiencing the same computing experience I currently am because programmers would be writing better code.</p><p>So is it engineering?  In it's current incarnation, no.  Could it ever be considered engineering?  Sure, but it would take a massive shift in the software development life cycle.</p><p>Personally I cannot wait until Moore's Law becomes Moore's Theory when it breaks because of some physical law stalls hardware development.  Then maybe we will see some good code.</p><p>Plus, isn't an idea supposed to be a theory until proven to be a law?  I mean does anyone really think it will continue indefinitely?  I bet Moore didn't even think so.  It seems we started calling it a law and it will continue until proven to be a theory.</p></htmltext>
<tokenext>Most undergraduate students do n't have enough time to learn the basics of computer programming , never mind software design.As I stated in a separate post in this same thread people with IT degrees should be doing the majority of programing .
When I got my undergraduate there was no IT degree , if you wanted to work in IT you got a BS in CS.In a perfect world , Computer Scientists ( like myself , MS in CS ) would be doing research and developing new advancements in CS.Regardless , in graduate programing courses you learn things like how to mathematically analysis different algorithms to determine which are superior .
How much of this goes into modern coding ?
Very little , if any.Cheaper , faster , easier is the motto of most programs written today .
This increases with the more business management that gets thrown into the mix .
That 's how something like MS Windows Vista comes into existence .
Give any real Computer Scientist the project along with the right to choose a developmental path and almost all of them would opt to scrap it and start over .
But either extreme is bad in one we get crappy software and the other nothing is ever released .
Currently we lean towards crappy software because hardware has developed so much faster than software .
If some physical law , universal law , prevented computers from having over 1 GB RAM and 100 MHZ CPU , then the focus would have shifted and I would still have 8 programs running on my computer and would be experiencing the same computing experience I currently am because programmers would be writing better code.So is it engineering ?
In it 's current incarnation , no .
Could it ever be considered engineering ?
Sure , but it would take a massive shift in the software development life cycle.Personally I can not wait until Moore 's Law becomes Moore 's Theory when it breaks because of some physical law stalls hardware development .
Then maybe we will see some good code.Plus , is n't an idea supposed to be a theory until proven to be a law ?
I mean does anyone really think it will continue indefinitely ?
I bet Moore did n't even think so .
It seems we started calling it a law and it will continue until proven to be a theory .</tokentext>
<sentencetext>Most undergraduate students don't have enough time to learn the basics of computer programming, never mind software design.As I stated in a separate post in this same thread people with IT degrees should be doing the majority of programing.
When I got my undergraduate there was no IT degree, if you wanted to work in IT you got a BS in CS.In a perfect world, Computer Scientists (like myself, MS in CS) would be doing research and developing new advancements in CS.Regardless, in graduate programing courses you learn things like how to mathematically analysis different algorithms to determine which are superior.
How much of this goes into modern coding?
Very little, if any.Cheaper, faster, easier is the motto of most programs written today.
This increases with the more business management that gets thrown into the mix.
That's how something like MS Windows Vista comes into existence.
Give any real Computer Scientist the project along with the right to choose a developmental path and almost all of them would opt to scrap it and start over.
But either extreme is bad in one we get crappy software and the other nothing is ever released.
Currently we lean towards crappy software because hardware has developed so much faster than software.
If some physical law, universal law, prevented computers from having over 1 GB RAM and 100 MHZ CPU, then the focus would have shifted and I would still have 8 programs running on my computer and would be experiencing the same computing experience I currently am because programmers would be writing better code.So is it engineering?
In it's current incarnation, no.
Could it ever be considered engineering?
Sure, but it would take a massive shift in the software development life cycle.Personally I cannot wait until Moore's Law becomes Moore's Theory when it breaks because of some physical law stalls hardware development.
Then maybe we will see some good code.Plus, isn't an idea supposed to be a theory until proven to be a law?
I mean does anyone really think it will continue indefinitely?
I bet Moore didn't even think so.
It seems we started calling it a law and it will continue until proven to be a theory.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231089</id>
	<title>Not just software</title>
	<author>Darinbob</author>
	<datestamp>1244281020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Some of these same old complaints exist with hardware too.  It takes humans to detect the "bugs" in a circuit layout or to quantify how adaptable/modifiable it is (ie, maintainability).  There's guesswork involved in figuring out how much to over-engineer something, finding the cheapest part that does what you need, crossing your fingers that a vendor doesn't discontinue a component.  Hardware engineers may take a more rigorous approach than the typical software grunt, but it is still a human endeavor.  Otherwise we couldn't have nearly so many board revisions and software wouldn't be used to mask over the hardware shortcomings.
<br> <br>
The biggest problem with software is that it is easily malleable.  We'd have far fewer bugs if it were treated like hardware that couldn't just be tweaked in the field if something is wrong; we'd be given more time to finish the designs and implementation, the testing would be built in and mandatory, nothing would be declared finished until several eyeballs looked it over and even then that would just be the initial prototype, and we'd have outside testing companies verify the solution for compliance with regulations.  When software is malleable it's really hard to tell the bosses "sorry, we can't make that change" or "we can't ship this week because we added a bug fix and have to retest."  Actually the same pressures exist in hardware (and other engineering discliples) it's just a lot more common with software.</htmltext>
<tokenext>Some of these same old complaints exist with hardware too .
It takes humans to detect the " bugs " in a circuit layout or to quantify how adaptable/modifiable it is ( ie , maintainability ) .
There 's guesswork involved in figuring out how much to over-engineer something , finding the cheapest part that does what you need , crossing your fingers that a vendor does n't discontinue a component .
Hardware engineers may take a more rigorous approach than the typical software grunt , but it is still a human endeavor .
Otherwise we could n't have nearly so many board revisions and software would n't be used to mask over the hardware shortcomings .
The biggest problem with software is that it is easily malleable .
We 'd have far fewer bugs if it were treated like hardware that could n't just be tweaked in the field if something is wrong ; we 'd be given more time to finish the designs and implementation , the testing would be built in and mandatory , nothing would be declared finished until several eyeballs looked it over and even then that would just be the initial prototype , and we 'd have outside testing companies verify the solution for compliance with regulations .
When software is malleable it 's really hard to tell the bosses " sorry , we ca n't make that change " or " we ca n't ship this week because we added a bug fix and have to retest .
" Actually the same pressures exist in hardware ( and other engineering discliples ) it 's just a lot more common with software .</tokentext>
<sentencetext>Some of these same old complaints exist with hardware too.
It takes humans to detect the "bugs" in a circuit layout or to quantify how adaptable/modifiable it is (ie, maintainability).
There's guesswork involved in figuring out how much to over-engineer something, finding the cheapest part that does what you need, crossing your fingers that a vendor doesn't discontinue a component.
Hardware engineers may take a more rigorous approach than the typical software grunt, but it is still a human endeavor.
Otherwise we couldn't have nearly so many board revisions and software wouldn't be used to mask over the hardware shortcomings.
The biggest problem with software is that it is easily malleable.
We'd have far fewer bugs if it were treated like hardware that couldn't just be tweaked in the field if something is wrong; we'd be given more time to finish the designs and implementation, the testing would be built in and mandatory, nothing would be declared finished until several eyeballs looked it over and even then that would just be the initial prototype, and we'd have outside testing companies verify the solution for compliance with regulations.
When software is malleable it's really hard to tell the bosses "sorry, we can't make that change" or "we can't ship this week because we added a bug fix and have to retest.
"  Actually the same pressures exist in hardware (and other engineering discliples) it's just a lot more common with software.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234153</id>
	<title>Re:Software Development is actually an art</title>
	<author>lawpoop</author>
	<datestamp>1244311020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>As I said in another post, I think good programmers are more like architects than painters or other types of artists. Architecture is a really interesting field, because you have to know your math and be able to design something that will actually stay up, but as far as what the end product looks like, it's totally creativity and vision. And then, it also has the human user in mind, so there is also a shared element of UI and user experience.</htmltext>
<tokenext>As I said in another post , I think good programmers are more like architects than painters or other types of artists .
Architecture is a really interesting field , because you have to know your math and be able to design something that will actually stay up , but as far as what the end product looks like , it 's totally creativity and vision .
And then , it also has the human user in mind , so there is also a shared element of UI and user experience .</tokentext>
<sentencetext>As I said in another post, I think good programmers are more like architects than painters or other types of artists.
Architecture is a really interesting field, because you have to know your math and be able to design something that will actually stay up, but as far as what the end product looks like, it's totally creativity and vision.
And then, it also has the human user in mind, so there is also a shared element of UI and user experience.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28240513</id>
	<title>Re:Software Engineering is trying</title>
	<author>thoglette</author>
	<datestamp>1244379300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p> I am not convinced that it ever will be. Writing software is a creative process,</p></div></blockquote><p>I call <b>bullshit</b></p><p>Engineering is a creative process, but a disciplined, analytic process.</p><p>Without the discipline, the job is never finished or faulty (see "university" or "research")</p><p>Without analysis it devolves to a trade (like programming, tech writing or machining).</p><p>To quote Dilbert - if you don't understand the difference between an engineer and a tech writer, you're not qualified to be an engineer.</p></div>
	</htmltext>
<tokenext>I am not convinced that it ever will be .
Writing software is a creative process,I call bullshitEngineering is a creative process , but a disciplined , analytic process.Without the discipline , the job is never finished or faulty ( see " university " or " research " ) Without analysis it devolves to a trade ( like programming , tech writing or machining ) .To quote Dilbert - if you do n't understand the difference between an engineer and a tech writer , you 're not qualified to be an engineer .</tokentext>
<sentencetext> I am not convinced that it ever will be.
Writing software is a creative process,I call bullshitEngineering is a creative process, but a disciplined, analytic process.Without the discipline, the job is never finished or faulty (see "university" or "research")Without analysis it devolves to a trade (like programming, tech writing or machining).To quote Dilbert - if you don't understand the difference between an engineer and a tech writer, you're not qualified to be an engineer.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231529</id>
	<title>The difference</title>
	<author>eznihm</author>
	<datestamp>1244288520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Writing source code is craft, making source code executable is engineering.</htmltext>
<tokenext>Writing source code is craft , making source code executable is engineering .</tokentext>
<sentencetext>Writing source code is craft, making source code executable is engineering.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236045</id>
	<title>Re:Before we get all sweaty about terms</title>
	<author>torako</author>
	<datestamp>1244280120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yes, you're right, of course, and he might just mean that.
<p>
What he describes happens, just as physicists sometimes develop a model to describe some natural phenomenon and end up discovering new math that is then later adopted by mathematicians.
</p><p>
But in both cases, I wouldn't describe that as the main purpose of the field. Physicists usually don't deal with pure math, mathematicians do. And mathematicians don't usually deal with observation, physicists do.</p></htmltext>
<tokenext>Yes , you 're right , of course , and he might just mean that .
What he describes happens , just as physicists sometimes develop a model to describe some natural phenomenon and end up discovering new math that is then later adopted by mathematicians .
But in both cases , I would n't describe that as the main purpose of the field .
Physicists usually do n't deal with pure math , mathematicians do .
And mathematicians do n't usually deal with observation , physicists do .</tokentext>
<sentencetext>Yes, you're right, of course, and he might just mean that.
What he describes happens, just as physicists sometimes develop a model to describe some natural phenomenon and end up discovering new math that is then later adopted by mathematicians.
But in both cases, I wouldn't describe that as the main purpose of the field.
Physicists usually don't deal with pure math, mathematicians do.
And mathematicians don't usually deal with observation, physicists do.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234177</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232551</id>
	<title>Pace/Cost of Change</title>
	<author>S77IM</author>
	<datestamp>1244300700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Engineering principles <i>can</i> be applied to software (even the wishy-washy stuff like requirements and usability) but nobody ever does it because of the deadline.  The product needs to go out the door yesterday!  To meet our contractual requirements or be first-to-market or patch the gaping vulnerability introduced during our last frenzied hack-fest.</p><p>The difference between other engineering fields and software is that in, say, civil engineering or architecture, production is expensive and fixing errors post-production is ridiculously expensive.  Nobody wants to put up half a skyscraper only to find that the foundation is wobbly or the main structural elements too weak or the design too top heavy.  So it's sound business practice to do a lot of rigorous, mathematically-provable checking and double-checking during the design phase, well before anyone puts on a hard-hat let alone builds something that might fall down.</p><p>With software, it's the reverse -- the design takes all the time, and the production is super cheap, and changing things after production isn't usually that bad.  Even if you have a large and expensive deployment, it's still usually feasible to change the software long after it has been built.  And in the typical case, the business use doesn't justify a rigorous up-front design.  Sure, fixing a defect after the code is in use is always harder than fixing it beforehand -- but that has to be weighed against the business value of having "good enough" code, sooner.</p><p>So, software engineering will never really become a rigorous field because there's no business reason for it (as opposed to fields that build physical objects, which have business pressure to be much more rigorous).</p><p>
&nbsp; -- 77IM</p></htmltext>
<tokenext>Engineering principles can be applied to software ( even the wishy-washy stuff like requirements and usability ) but nobody ever does it because of the deadline .
The product needs to go out the door yesterday !
To meet our contractual requirements or be first-to-market or patch the gaping vulnerability introduced during our last frenzied hack-fest.The difference between other engineering fields and software is that in , say , civil engineering or architecture , production is expensive and fixing errors post-production is ridiculously expensive .
Nobody wants to put up half a skyscraper only to find that the foundation is wobbly or the main structural elements too weak or the design too top heavy .
So it 's sound business practice to do a lot of rigorous , mathematically-provable checking and double-checking during the design phase , well before anyone puts on a hard-hat let alone builds something that might fall down.With software , it 's the reverse -- the design takes all the time , and the production is super cheap , and changing things after production is n't usually that bad .
Even if you have a large and expensive deployment , it 's still usually feasible to change the software long after it has been built .
And in the typical case , the business use does n't justify a rigorous up-front design .
Sure , fixing a defect after the code is in use is always harder than fixing it beforehand -- but that has to be weighed against the business value of having " good enough " code , sooner.So , software engineering will never really become a rigorous field because there 's no business reason for it ( as opposed to fields that build physical objects , which have business pressure to be much more rigorous ) .
  -- 77IM</tokentext>
<sentencetext>Engineering principles can be applied to software (even the wishy-washy stuff like requirements and usability) but nobody ever does it because of the deadline.
The product needs to go out the door yesterday!
To meet our contractual requirements or be first-to-market or patch the gaping vulnerability introduced during our last frenzied hack-fest.The difference between other engineering fields and software is that in, say, civil engineering or architecture, production is expensive and fixing errors post-production is ridiculously expensive.
Nobody wants to put up half a skyscraper only to find that the foundation is wobbly or the main structural elements too weak or the design too top heavy.
So it's sound business practice to do a lot of rigorous, mathematically-provable checking and double-checking during the design phase, well before anyone puts on a hard-hat let alone builds something that might fall down.With software, it's the reverse -- the design takes all the time, and the production is super cheap, and changing things after production isn't usually that bad.
Even if you have a large and expensive deployment, it's still usually feasible to change the software long after it has been built.
And in the typical case, the business use doesn't justify a rigorous up-front design.
Sure, fixing a defect after the code is in use is always harder than fixing it beforehand -- but that has to be weighed against the business value of having "good enough" code, sooner.So, software engineering will never really become a rigorous field because there's no business reason for it (as opposed to fields that build physical objects, which have business pressure to be much more rigorous).
  -- 77IM</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230729</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244318460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>After working with engineers from other disciplines that create software, one begins to realize how different it is for those of us who create software for a living, especially stuff that a human can use. Engineers from other disciplines tend (and I'm generalizing) to be more derivative, when creating software.</p><p>Good software engineers, programmers, hackers, or whatever you want to call us think about problems differently. When we do our best work, it is because we see a problem that is new to us, and we see a solution or a potential solution. The result is software that the artistic, creative poets put together to function in a way that solves a problem. Sometimes it's elegant; other times it's horrendous. I'm sure you can think of many examples of each. But every time, it is something personal.</p><p>I agree that the idea of controlling development in some formulaic way is next to ludicrous. All you can really hope for is that the development is contained enough from getting unmanageable. Scope-creep, enhancements, limitations and their respective removals, all play havoc with rigour. I think you can easily see when software is getting to the unmanageable level; that's when you throw out and recreate. I've heard the cursing of other developers for decades and yet, no one escapes those curses. And it can go both ways... eg. Bob: Why TF did Joe do X?... and often enough... Joe: What TF was Bob thinking? X is now really broken!</p><p>Software is Art as much as it is anything else.</p></htmltext>
<tokenext>After working with engineers from other disciplines that create software , one begins to realize how different it is for those of us who create software for a living , especially stuff that a human can use .
Engineers from other disciplines tend ( and I 'm generalizing ) to be more derivative , when creating software.Good software engineers , programmers , hackers , or whatever you want to call us think about problems differently .
When we do our best work , it is because we see a problem that is new to us , and we see a solution or a potential solution .
The result is software that the artistic , creative poets put together to function in a way that solves a problem .
Sometimes it 's elegant ; other times it 's horrendous .
I 'm sure you can think of many examples of each .
But every time , it is something personal.I agree that the idea of controlling development in some formulaic way is next to ludicrous .
All you can really hope for is that the development is contained enough from getting unmanageable .
Scope-creep , enhancements , limitations and their respective removals , all play havoc with rigour .
I think you can easily see when software is getting to the unmanageable level ; that 's when you throw out and recreate .
I 've heard the cursing of other developers for decades and yet , no one escapes those curses .
And it can go both ways... eg. Bob : Why TF did Joe do X ? .. .
and often enough... Joe : What TF was Bob thinking ?
X is now really broken ! Software is Art as much as it is anything else .</tokentext>
<sentencetext>After working with engineers from other disciplines that create software, one begins to realize how different it is for those of us who create software for a living, especially stuff that a human can use.
Engineers from other disciplines tend (and I'm generalizing) to be more derivative, when creating software.Good software engineers, programmers, hackers, or whatever you want to call us think about problems differently.
When we do our best work, it is because we see a problem that is new to us, and we see a solution or a potential solution.
The result is software that the artistic, creative poets put together to function in a way that solves a problem.
Sometimes it's elegant; other times it's horrendous.
I'm sure you can think of many examples of each.
But every time, it is something personal.I agree that the idea of controlling development in some formulaic way is next to ludicrous.
All you can really hope for is that the development is contained enough from getting unmanageable.
Scope-creep, enhancements, limitations and their respective removals, all play havoc with rigour.
I think you can easily see when software is getting to the unmanageable level; that's when you throw out and recreate.
I've heard the cursing of other developers for decades and yet, no one escapes those curses.
And it can go both ways... eg. Bob: Why TF did Joe do X?...
and often enough... Joe: What TF was Bob thinking?
X is now really broken!Software is Art as much as it is anything else.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231169</id>
	<title>Re:Perspective?</title>
	<author>ThePhilips</author>
	<datestamp>1244281980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>Computer Science compared to Software Engineering?<br>
Think aeronautics. The science of aeronautics ponders the laws of aerodynamics and the laws of flight.<br>
Engineering aeronautics is all about building the damn aircraft.</p></div><p> That's pretty much how I think myself.

</p><p> Engineering would stop being engineering if it becomes a science.

</p><p> Engineering is in deep real world, with human nature and business requirements intervening all the time. Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula. They are both trying to understand a problem - but from different angles. So different - or better say orthogonal - that they are guaranteed to cross only rarely.</p><p><div class="quote"><p> Writing software is a creative process, arguably even an artistic one.</p> </div><p> Same with science. I'd say that in the respect there is not much difference.

</p><p> The difference is as I try to put it above is that in engineering "it must work," while in science it doesn't even have to compile. It only has to work in some ideal world with unlimited resources and non-existent foreign factors.</p></div>
	</htmltext>
<tokenext>Computer Science compared to Software Engineering ?
Think aeronautics .
The science of aeronautics ponders the laws of aerodynamics and the laws of flight .
Engineering aeronautics is all about building the damn aircraft .
That 's pretty much how I think myself .
Engineering would stop being engineering if it becomes a science .
Engineering is in deep real world , with human nature and business requirements intervening all the time .
Science ( like religion ) is in some sort of ideal world , vacuum , where all is simple and described by a formula .
They are both trying to understand a problem - but from different angles .
So different - or better say orthogonal - that they are guaranteed to cross only rarely .
Writing software is a creative process , arguably even an artistic one .
Same with science .
I 'd say that in the respect there is not much difference .
The difference is as I try to put it above is that in engineering " it must work , " while in science it does n't even have to compile .
It only has to work in some ideal world with unlimited resources and non-existent foreign factors .</tokentext>
<sentencetext>Computer Science compared to Software Engineering?
Think aeronautics.
The science of aeronautics ponders the laws of aerodynamics and the laws of flight.
Engineering aeronautics is all about building the damn aircraft.
That's pretty much how I think myself.
Engineering would stop being engineering if it becomes a science.
Engineering is in deep real world, with human nature and business requirements intervening all the time.
Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.
They are both trying to understand a problem - but from different angles.
So different - or better say orthogonal - that they are guaranteed to cross only rarely.
Writing software is a creative process, arguably even an artistic one.
Same with science.
I'd say that in the respect there is not much difference.
The difference is as I try to put it above is that in engineering "it must work," while in science it doesn't even have to compile.
It only has to work in some ideal world with unlimited resources and non-existent foreign factors.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232849</id>
	<title>ABET like Software Engineering</title>
	<author>WWE-TicK</author>
	<datestamp>1244302740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>ABET recognizes Software Engineering as a legitimate engineering field.  Just sayin'...</htmltext>
<tokenext>ABET recognizes Software Engineering as a legitimate engineering field .
Just sayin'.. .</tokentext>
<sentencetext>ABET recognizes Software Engineering as a legitimate engineering field.
Just sayin'...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232367</id>
	<title>Re:You're not Engineers. Get over it.</title>
	<author>russotto</author>
	<datestamp>1244299440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p>Look, there is nothing wrong with being a programmer. Just as a good tech gets pissed off when he sees a 'nail technician', real engineers laugh at the IT crowd.</p></div></blockquote><p>If you're going to insist on rigorous naming, you ought to be consistent about it.  Programming != "the IT crowd".  There's some overlap, but there's a lot more programmers not in "the IT crowd" and a lot more to be done than programming within the "IT crowd".</p><p>Furthermore, I don't care how many bridges, buildings, or aircraft you can design, if you can't drive a steam locomotive (with attached train), you ain't no engineer.</p></div>
	</htmltext>
<tokenext>Look , there is nothing wrong with being a programmer .
Just as a good tech gets pissed off when he sees a 'nail technician ' , real engineers laugh at the IT crowd.If you 're going to insist on rigorous naming , you ought to be consistent about it .
Programming ! = " the IT crowd " .
There 's some overlap , but there 's a lot more programmers not in " the IT crowd " and a lot more to be done than programming within the " IT crowd " .Furthermore , I do n't care how many bridges , buildings , or aircraft you can design , if you ca n't drive a steam locomotive ( with attached train ) , you ai n't no engineer .</tokentext>
<sentencetext>Look, there is nothing wrong with being a programmer.
Just as a good tech gets pissed off when he sees a 'nail technician', real engineers laugh at the IT crowd.If you're going to insist on rigorous naming, you ought to be consistent about it.
Programming != "the IT crowd".
There's some overlap, but there's a lot more programmers not in "the IT crowd" and a lot more to be done than programming within the "IT crowd".Furthermore, I don't care how many bridges, buildings, or aircraft you can design, if you can't drive a steam locomotive (with attached train), you ain't no engineer.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232503</id>
	<title>Re:Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244300460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; Meanwhile it's surprising how often my mates who have done IT or computer science ask me for help on something because they just don't know how to THINK.</p><p>Apples and Oranges: your mates are trained to design and write software etc, not debug hardware and OS config problems.</p></htmltext>
<tokenext>&gt; Meanwhile it 's surprising how often my mates who have done IT or computer science ask me for help on something because they just do n't know how to THINK.Apples and Oranges : your mates are trained to design and write software etc , not debug hardware and OS config problems .</tokentext>
<sentencetext>&gt; Meanwhile it's surprising how often my mates who have done IT or computer science ask me for help on something because they just don't know how to THINK.Apples and Oranges: your mates are trained to design and write software etc, not debug hardware and OS config problems.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230691</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232025</id>
	<title>Computer Science != Coding</title>
	<author>Anonymous</author>
	<datestamp>1244296200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I have my BS in Computer Science, am 1 course away from having my MS in Computer Science, as well as have 15 years experience in general IT with a focus on Network Security.</p><p>My BS in Computer Science was nearly 100\% coding languages and techniques.  My MS has had some coding in it and I would say that any computer scientist should have a strong grasp of coding.  But, when you look at Computer Science as a discipline it should be these new undergraduates with an IT degree that do the coding jobs.  This distinction didn't exist when I was getting my undergraduate degree, there was no IT degrees.</p><p>After going through my MS in Computer Science I have realized the discipline of Computer Science to be what it really is and that is applied mathematics.  I am hoping that the IT industry will appreciate my vast knowledge of how computers work that I gained during my graduate studies, though I may not put that knowledge into whatever daily tasks I am responsible for.  Looking at my background and education the best fit for me in the IT industry would be as a CIO or CTO.  Though, I'm sure those jobs are a rare and of the type where you have to know someone.</p><p>Computer Science is just that a science.  Not only that a mathematical science.  I always wondered why people got math degrees, being they don't have a direct career path for them, other than academics itself.  Now, I look back and realize I'm about to have a Masters in Applied Mathematics (Computer Science).  How will that affect my future?  Only time will tell.  Like I said I got 15 years experience with my BS in Computer Science (Programming) and thankfully programming has never been my primary role during my professional career.</p><p>I'm at a crossroads, do I go back into the "real world" and see what I get for my upgrade to Masters in CS or do I stay in the academic world, get my Ph.D. and teach CS?  Teaching pays a lot less but there is more job security.</p><p>But, one thing is fore sure I won't write you a program for the same reasons I won't fix your computer.  Not that I won't code something if doing so makes my job easier or my company more efficient but I am a Computer Scientist and not an IT guy.  So, you'll have to find someone else to change the toner in the printer.</p><p>There will always have to be people in the loop in all stages of program development but I think we have come far enough where the IT guys should be doing that and the Computer Scientists should be doing more advanced work.  Let the secretary change the toner.</p><p>The only way people will be taken out of the loop is if someday Computer Scientists learn enough knowledge to create sentient beings, with an intelligence of its own, through a combination of hardware and software.  Notice I said intelligence.  Artificial intelligence is generally used incorrectly. Computer Science is currently at a stage where we cannot even simulate intelligence accurately.  But, if we ever do create intelligent computers there will be nothing artificial about it.  Once that happens it's likely that we will no longer be the most intelligent beings, we know of, in the universe.  By Definition if we can create something smarter than ourselves then that something would be smart enough to create something smarter then their selves.  Though, I don't think this will lead to a Matrix like scenario. Why do most people always imagine the worse case scenario?  Though IMHO we don't even have to worry about such an event, unless it somehow happens by accident, because Computer Scientists cannot even define intelligence to any degree, never mind understand it enough to write intelligent code.</p><p>ANYWAYS, if people keep treating Computer Scientists like lowly IT guys we might just have to stick a 'pointer' into your eye.</p><p>Plus being a computer scientist I get the advantage of random implied youthfulness.  That's why I was born Jan, 1970 and am currently 27 years old.  It's all due to applied mathematics.  How many Java or<nobr> <wbr></nobr>.NOT programmers understand why?</p></htmltext>
<tokenext>I have my BS in Computer Science , am 1 course away from having my MS in Computer Science , as well as have 15 years experience in general IT with a focus on Network Security.My BS in Computer Science was nearly 100 \ % coding languages and techniques .
My MS has had some coding in it and I would say that any computer scientist should have a strong grasp of coding .
But , when you look at Computer Science as a discipline it should be these new undergraduates with an IT degree that do the coding jobs .
This distinction did n't exist when I was getting my undergraduate degree , there was no IT degrees.After going through my MS in Computer Science I have realized the discipline of Computer Science to be what it really is and that is applied mathematics .
I am hoping that the IT industry will appreciate my vast knowledge of how computers work that I gained during my graduate studies , though I may not put that knowledge into whatever daily tasks I am responsible for .
Looking at my background and education the best fit for me in the IT industry would be as a CIO or CTO .
Though , I 'm sure those jobs are a rare and of the type where you have to know someone.Computer Science is just that a science .
Not only that a mathematical science .
I always wondered why people got math degrees , being they do n't have a direct career path for them , other than academics itself .
Now , I look back and realize I 'm about to have a Masters in Applied Mathematics ( Computer Science ) .
How will that affect my future ?
Only time will tell .
Like I said I got 15 years experience with my BS in Computer Science ( Programming ) and thankfully programming has never been my primary role during my professional career.I 'm at a crossroads , do I go back into the " real world " and see what I get for my upgrade to Masters in CS or do I stay in the academic world , get my Ph.D. and teach CS ?
Teaching pays a lot less but there is more job security.But , one thing is fore sure I wo n't write you a program for the same reasons I wo n't fix your computer .
Not that I wo n't code something if doing so makes my job easier or my company more efficient but I am a Computer Scientist and not an IT guy .
So , you 'll have to find someone else to change the toner in the printer.There will always have to be people in the loop in all stages of program development but I think we have come far enough where the IT guys should be doing that and the Computer Scientists should be doing more advanced work .
Let the secretary change the toner.The only way people will be taken out of the loop is if someday Computer Scientists learn enough knowledge to create sentient beings , with an intelligence of its own , through a combination of hardware and software .
Notice I said intelligence .
Artificial intelligence is generally used incorrectly .
Computer Science is currently at a stage where we can not even simulate intelligence accurately .
But , if we ever do create intelligent computers there will be nothing artificial about it .
Once that happens it 's likely that we will no longer be the most intelligent beings , we know of , in the universe .
By Definition if we can create something smarter than ourselves then that something would be smart enough to create something smarter then their selves .
Though , I do n't think this will lead to a Matrix like scenario .
Why do most people always imagine the worse case scenario ?
Though IMHO we do n't even have to worry about such an event , unless it somehow happens by accident , because Computer Scientists can not even define intelligence to any degree , never mind understand it enough to write intelligent code.ANYWAYS , if people keep treating Computer Scientists like lowly IT guys we might just have to stick a 'pointer ' into your eye.Plus being a computer scientist I get the advantage of random implied youthfulness .
That 's why I was born Jan , 1970 and am currently 27 years old .
It 's all due to applied mathematics .
How many Java or .NOT programmers understand why ?</tokentext>
<sentencetext>I have my BS in Computer Science, am 1 course away from having my MS in Computer Science, as well as have 15 years experience in general IT with a focus on Network Security.My BS in Computer Science was nearly 100\% coding languages and techniques.
My MS has had some coding in it and I would say that any computer scientist should have a strong grasp of coding.
But, when you look at Computer Science as a discipline it should be these new undergraduates with an IT degree that do the coding jobs.
This distinction didn't exist when I was getting my undergraduate degree, there was no IT degrees.After going through my MS in Computer Science I have realized the discipline of Computer Science to be what it really is and that is applied mathematics.
I am hoping that the IT industry will appreciate my vast knowledge of how computers work that I gained during my graduate studies, though I may not put that knowledge into whatever daily tasks I am responsible for.
Looking at my background and education the best fit for me in the IT industry would be as a CIO or CTO.
Though, I'm sure those jobs are a rare and of the type where you have to know someone.Computer Science is just that a science.
Not only that a mathematical science.
I always wondered why people got math degrees, being they don't have a direct career path for them, other than academics itself.
Now, I look back and realize I'm about to have a Masters in Applied Mathematics (Computer Science).
How will that affect my future?
Only time will tell.
Like I said I got 15 years experience with my BS in Computer Science (Programming) and thankfully programming has never been my primary role during my professional career.I'm at a crossroads, do I go back into the "real world" and see what I get for my upgrade to Masters in CS or do I stay in the academic world, get my Ph.D. and teach CS?
Teaching pays a lot less but there is more job security.But, one thing is fore sure I won't write you a program for the same reasons I won't fix your computer.
Not that I won't code something if doing so makes my job easier or my company more efficient but I am a Computer Scientist and not an IT guy.
So, you'll have to find someone else to change the toner in the printer.There will always have to be people in the loop in all stages of program development but I think we have come far enough where the IT guys should be doing that and the Computer Scientists should be doing more advanced work.
Let the secretary change the toner.The only way people will be taken out of the loop is if someday Computer Scientists learn enough knowledge to create sentient beings, with an intelligence of its own, through a combination of hardware and software.
Notice I said intelligence.
Artificial intelligence is generally used incorrectly.
Computer Science is currently at a stage where we cannot even simulate intelligence accurately.
But, if we ever do create intelligent computers there will be nothing artificial about it.
Once that happens it's likely that we will no longer be the most intelligent beings, we know of, in the universe.
By Definition if we can create something smarter than ourselves then that something would be smart enough to create something smarter then their selves.
Though, I don't think this will lead to a Matrix like scenario.
Why do most people always imagine the worse case scenario?
Though IMHO we don't even have to worry about such an event, unless it somehow happens by accident, because Computer Scientists cannot even define intelligence to any degree, never mind understand it enough to write intelligent code.ANYWAYS, if people keep treating Computer Scientists like lowly IT guys we might just have to stick a 'pointer' into your eye.Plus being a computer scientist I get the advantage of random implied youthfulness.
That's why I was born Jan, 1970 and am currently 27 years old.
It's all due to applied mathematics.
How many Java or .NOT programmers understand why?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231501</id>
	<title>Re:Software Development is actually an art</title>
	<author>Enleth</author>
	<datestamp>1244288160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>No. If an engineer designs a car and it crashes due to easily-avoidable defects, his company is fined big bucks in court. If an engineer designs a program and it crashes due to easily-avoidable defects, his company tells the client "go read the EULA and fuck off, we're not responsible". So, the first engineer's company gives him the money, means and time required to avoid those defects. The first engineer's company doesn't bother, so the engineer doesn't find those defects, even if he'd like to, because he'd be fired for not meeting the deadline and wasting time on something that doesn't affect revenue.</p><p>Well, in fact, there were cases of car companies figuring out that paying a few families some change money would be cheaper than acutally fixing those easily avoidable defects, but that's another matter.</p></htmltext>
<tokenext>No .
If an engineer designs a car and it crashes due to easily-avoidable defects , his company is fined big bucks in court .
If an engineer designs a program and it crashes due to easily-avoidable defects , his company tells the client " go read the EULA and fuck off , we 're not responsible " .
So , the first engineer 's company gives him the money , means and time required to avoid those defects .
The first engineer 's company does n't bother , so the engineer does n't find those defects , even if he 'd like to , because he 'd be fired for not meeting the deadline and wasting time on something that does n't affect revenue.Well , in fact , there were cases of car companies figuring out that paying a few families some change money would be cheaper than acutally fixing those easily avoidable defects , but that 's another matter .</tokentext>
<sentencetext>No.
If an engineer designs a car and it crashes due to easily-avoidable defects, his company is fined big bucks in court.
If an engineer designs a program and it crashes due to easily-avoidable defects, his company tells the client "go read the EULA and fuck off, we're not responsible".
So, the first engineer's company gives him the money, means and time required to avoid those defects.
The first engineer's company doesn't bother, so the engineer doesn't find those defects, even if he'd like to, because he'd be fired for not meeting the deadline and wasting time on something that doesn't affect revenue.Well, in fact, there were cases of car companies figuring out that paying a few families some change money would be cheaper than acutally fixing those easily avoidable defects, but that's another matter.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231033</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231793</id>
	<title>What's wrong with this picture?</title>
	<author>garethharris</author>
	<datestamp>1244292840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>SE has little to do with software. It has become mainly software project management. Software projects are disaster areas because inexperienced people look for gimmicks instead of putting in the 10,000 to 20,000 hours to become proficient. Just look at the job ads looking for "Senior developer with 3 years experience." Software used to be built by some brilliant people before CS and IT degrees existed. Most had degrees in physics and math or sometimes oddly enough - music. A few had no degrees st all. As computing has become more of a mainstream industry, most recent programmers have little knowledge of CS issues relating to simplicity, languages, algorithms,  race conditions, etc. they get "certifications" from vendors! They just chase fads, throw everything in a pot and hope OO will organize it. They also seem to have little knowledge of basic engineering such as minimizing part and technology counts, orthogonal structures, neatness in design, etc. Now, I often do projects where I beat teams of 20 or more by myself. What's wrong with this picture?</htmltext>
<tokenext>SE has little to do with software .
It has become mainly software project management .
Software projects are disaster areas because inexperienced people look for gimmicks instead of putting in the 10,000 to 20,000 hours to become proficient .
Just look at the job ads looking for " Senior developer with 3 years experience .
" Software used to be built by some brilliant people before CS and IT degrees existed .
Most had degrees in physics and math or sometimes oddly enough - music .
A few had no degrees st all .
As computing has become more of a mainstream industry , most recent programmers have little knowledge of CS issues relating to simplicity , languages , algorithms , race conditions , etc .
they get " certifications " from vendors !
They just chase fads , throw everything in a pot and hope OO will organize it .
They also seem to have little knowledge of basic engineering such as minimizing part and technology counts , orthogonal structures , neatness in design , etc .
Now , I often do projects where I beat teams of 20 or more by myself .
What 's wrong with this picture ?</tokentext>
<sentencetext>SE has little to do with software.
It has become mainly software project management.
Software projects are disaster areas because inexperienced people look for gimmicks instead of putting in the 10,000 to 20,000 hours to become proficient.
Just look at the job ads looking for "Senior developer with 3 years experience.
" Software used to be built by some brilliant people before CS and IT degrees existed.
Most had degrees in physics and math or sometimes oddly enough - music.
A few had no degrees st all.
As computing has become more of a mainstream industry, most recent programmers have little knowledge of CS issues relating to simplicity, languages, algorithms,  race conditions, etc.
they get "certifications" from vendors!
They just chase fads, throw everything in a pot and hope OO will organize it.
They also seem to have little knowledge of basic engineering such as minimizing part and technology counts, orthogonal structures, neatness in design, etc.
Now, I often do projects where I beat teams of 20 or more by myself.
What's wrong with this picture?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231701</id>
	<title>Involves humans, eh?</title>
	<author>pedantic bore</author>
	<datestamp>1244291640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If having humans 'central to the process' is an issue, that rules out medicine, psychology, sociology, history...</htmltext>
<tokenext>If having humans 'central to the process ' is an issue , that rules out medicine , psychology , sociology , history.. .</tokentext>
<sentencetext>If having humans 'central to the process' is an issue, that rules out medicine, psychology, sociology, history...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232947</id>
	<title>Flutist or Flautist?</title>
	<author>nicholdraper</author>
	<datestamp>1244303460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Programmer, Software Engineer, Computer Scientist, Software Architect.  The title depends upon your level of insecurity.  Same with Computer Science compared with Software Engineering.  Was Michael Faraday not an inventor of electronics because he didn't use calculus?  The truth is that there are good, bad and ugly practitionares of computer engineering science.  The ugliest of all think they are good.</htmltext>
<tokenext>Programmer , Software Engineer , Computer Scientist , Software Architect .
The title depends upon your level of insecurity .
Same with Computer Science compared with Software Engineering .
Was Michael Faraday not an inventor of electronics because he did n't use calculus ?
The truth is that there are good , bad and ugly practitionares of computer engineering science .
The ugliest of all think they are good .</tokentext>
<sentencetext>Programmer, Software Engineer, Computer Scientist, Software Architect.
The title depends upon your level of insecurity.
Same with Computer Science compared with Software Engineering.
Was Michael Faraday not an inventor of electronics because he didn't use calculus?
The truth is that there are good, bad and ugly practitionares of computer engineering science.
The ugliest of all think they are good.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232069</id>
	<title>Feedback loops accepted</title>
	<author>tyroneking</author>
	<datestamp>1244296800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've always thought (and I think there are some Scrum related papers to back me up on this) that the instant malleability of software design has substituted for formal practices.</p><p>There's nothing as malleable in the real world so we don't know how to formalise it.</p><p>Instead, on most of the system I've worked on, management have tried to introduce formalities just so they feel happier - when there's no real point.</p><p>Example: I'm trying to figure out how to strip UTC from a bunch of fields in a system - make them date only instead of time-zone aware date-time. The answer is easy (change the data type), the analysis is horrible (find all the other fields and operations that are touched by the field concerned), but the management overhead is outstanding - I've had to write two document, an hour long presentation, and a video-cap of a demonstration, a risk assessment probably too; and still people won't leave me alone to get on with it.</p></htmltext>
<tokenext>I 've always thought ( and I think there are some Scrum related papers to back me up on this ) that the instant malleability of software design has substituted for formal practices.There 's nothing as malleable in the real world so we do n't know how to formalise it.Instead , on most of the system I 've worked on , management have tried to introduce formalities just so they feel happier - when there 's no real point.Example : I 'm trying to figure out how to strip UTC from a bunch of fields in a system - make them date only instead of time-zone aware date-time .
The answer is easy ( change the data type ) , the analysis is horrible ( find all the other fields and operations that are touched by the field concerned ) , but the management overhead is outstanding - I 've had to write two document , an hour long presentation , and a video-cap of a demonstration , a risk assessment probably too ; and still people wo n't leave me alone to get on with it .</tokentext>
<sentencetext>I've always thought (and I think there are some Scrum related papers to back me up on this) that the instant malleability of software design has substituted for formal practices.There's nothing as malleable in the real world so we don't know how to formalise it.Instead, on most of the system I've worked on, management have tried to introduce formalities just so they feel happier - when there's no real point.Example: I'm trying to figure out how to strip UTC from a bunch of fields in a system - make them date only instead of time-zone aware date-time.
The answer is easy (change the data type), the analysis is horrible (find all the other fields and operations that are touched by the field concerned), but the management overhead is outstanding - I've had to write two document, an hour long presentation, and a video-cap of a demonstration, a risk assessment probably too; and still people won't leave me alone to get on with it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231389</id>
	<title>Re:Software Development is actually an art</title>
	<author>BiggerIsBetter</author>
	<datestamp>1244285820000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>I agree with the sentiment, but in a business context, I think that means we're doing it wrong.</p><p>Production software *should* be boring, and rigorous... and correct. Now, I know this has all been hashed out before, and it's one reason why we ended up with Agile methodologies, but very very very little of what we do needs to be clever, or innovative. Despite what we think, most of us aren't smart enough to build clever AND reliable software, so we end up crafting things rather than truly engineering them. Those of us who ARE smart enough probably aren't working on projects with enough budget to take the time to do so.</p></htmltext>
<tokenext>I agree with the sentiment , but in a business context , I think that means we 're doing it wrong.Production software * should * be boring , and rigorous... and correct .
Now , I know this has all been hashed out before , and it 's one reason why we ended up with Agile methodologies , but very very very little of what we do needs to be clever , or innovative .
Despite what we think , most of us are n't smart enough to build clever AND reliable software , so we end up crafting things rather than truly engineering them .
Those of us who ARE smart enough probably are n't working on projects with enough budget to take the time to do so .</tokentext>
<sentencetext>I agree with the sentiment, but in a business context, I think that means we're doing it wrong.Production software *should* be boring, and rigorous... and correct.
Now, I know this has all been hashed out before, and it's one reason why we ended up with Agile methodologies, but very very very little of what we do needs to be clever, or innovative.
Despite what we think, most of us aren't smart enough to build clever AND reliable software, so we end up crafting things rather than truly engineering them.
Those of us who ARE smart enough probably aren't working on projects with enough budget to take the time to do so.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232651</id>
	<title>Re:Perspective?</title>
	<author>jc42</author>
	<datestamp>1244301300000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p><i>Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.</i></p><p>I think you're confusing (or conflating) science with mathematics.  But don't feel bad; people do this all the time.  Part of the reason is that science routinely uses mathematics as a tool, and the two fields are deeply intertwined.  Scientists use math to help understand and explain what they're working on, while mathematicians routinely use scientific work as inspiration for new ideas to pursue.</p><p>But the "science" part is usually very much about the real world.  It's the mathematicians who carefully avoid dealing with the real world, since that's not their job.  The interesting part is how often the abstract, theoretical stuff that the mathematicians work on turn out to be very applicable to figuring out what's going on in the real world.</p><p>One of the problems with our terminology is that "computer science" is generally used for the abstract, theoretical part of software.  This is misleading, because the subject really is a mathematical field, not scientific.  If it were scientific, the computer scientists would be performing experiments and developing hypotheses to explain how software works.  But that's not what they do; it's the "software engineers" trying to debug software that do things like that.</p><p>And this leads to the problem that "software engineering" generally involves doing things that in other fields would be called "science".  In engineering, you are generally working with tools and materials whose behavior is well understood, so you can concentrate on design.  With software development, this isn't generally true.  An engineer designing a bridge or house or airplane can expect to work with detailed specs for all the available components.  With software, the equivalent information is usually proprietary and intentionally hidden from the people building the code.  Even in "open source" systems, the concept of "information hiding" is popular, and all too often this does mean that needed information is intentionally hidden from the person writing the code. So the software engineer is working with poorly-documented material, and must develop using processes that test and discover the properties of the underlying stuff.</p><p>Of course, there are some software engineers who don't do any debugging.  But we know how well this works.  Civil engineers might be able to develop this way, since they have access to full specs for their material.  Software engineers can't, because they are kept ignorant of the details of lower-level stuff.  As long as this is true, software engineering must have a large scientific component, to study and test the software as it's developed.  They must constantly develop and test hypotheses about their code, in order to get it to function as desired in an environment that is mostly hidden.</p><p>Anyway, there's little chance of getting the terminology straight any time soon.  There's no chance of software people getting access to detailed specs for the underlying systems.  We even have laws in place that block the access to full information.  So software engineering can't really be true engineering, and software developers will continue to spend large parts of their time acting as experimental scientists in order to debug their software.  And they won't get much help from the computer scientists, who are spending most of their time working with the mathematics of the subject, while disparaging the real-world portion of their discipline as being "mere engineering".</p><p>Now if we could only get the computer field to adopt the same definitions that other fields of engineering, science and mat use.  But that isn't going to happen any time soon.</p></htmltext>
<tokenext>Science ( like religion ) is in some sort of ideal world , vacuum , where all is simple and described by a formula.I think you 're confusing ( or conflating ) science with mathematics .
But do n't feel bad ; people do this all the time .
Part of the reason is that science routinely uses mathematics as a tool , and the two fields are deeply intertwined .
Scientists use math to help understand and explain what they 're working on , while mathematicians routinely use scientific work as inspiration for new ideas to pursue.But the " science " part is usually very much about the real world .
It 's the mathematicians who carefully avoid dealing with the real world , since that 's not their job .
The interesting part is how often the abstract , theoretical stuff that the mathematicians work on turn out to be very applicable to figuring out what 's going on in the real world.One of the problems with our terminology is that " computer science " is generally used for the abstract , theoretical part of software .
This is misleading , because the subject really is a mathematical field , not scientific .
If it were scientific , the computer scientists would be performing experiments and developing hypotheses to explain how software works .
But that 's not what they do ; it 's the " software engineers " trying to debug software that do things like that.And this leads to the problem that " software engineering " generally involves doing things that in other fields would be called " science " .
In engineering , you are generally working with tools and materials whose behavior is well understood , so you can concentrate on design .
With software development , this is n't generally true .
An engineer designing a bridge or house or airplane can expect to work with detailed specs for all the available components .
With software , the equivalent information is usually proprietary and intentionally hidden from the people building the code .
Even in " open source " systems , the concept of " information hiding " is popular , and all too often this does mean that needed information is intentionally hidden from the person writing the code .
So the software engineer is working with poorly-documented material , and must develop using processes that test and discover the properties of the underlying stuff.Of course , there are some software engineers who do n't do any debugging .
But we know how well this works .
Civil engineers might be able to develop this way , since they have access to full specs for their material .
Software engineers ca n't , because they are kept ignorant of the details of lower-level stuff .
As long as this is true , software engineering must have a large scientific component , to study and test the software as it 's developed .
They must constantly develop and test hypotheses about their code , in order to get it to function as desired in an environment that is mostly hidden.Anyway , there 's little chance of getting the terminology straight any time soon .
There 's no chance of software people getting access to detailed specs for the underlying systems .
We even have laws in place that block the access to full information .
So software engineering ca n't really be true engineering , and software developers will continue to spend large parts of their time acting as experimental scientists in order to debug their software .
And they wo n't get much help from the computer scientists , who are spending most of their time working with the mathematics of the subject , while disparaging the real-world portion of their discipline as being " mere engineering " .Now if we could only get the computer field to adopt the same definitions that other fields of engineering , science and mat use .
But that is n't going to happen any time soon .</tokentext>
<sentencetext>Science (like religion) is in some sort of ideal world, vacuum, where all is simple and described by a formula.I think you're confusing (or conflating) science with mathematics.
But don't feel bad; people do this all the time.
Part of the reason is that science routinely uses mathematics as a tool, and the two fields are deeply intertwined.
Scientists use math to help understand and explain what they're working on, while mathematicians routinely use scientific work as inspiration for new ideas to pursue.But the "science" part is usually very much about the real world.
It's the mathematicians who carefully avoid dealing with the real world, since that's not their job.
The interesting part is how often the abstract, theoretical stuff that the mathematicians work on turn out to be very applicable to figuring out what's going on in the real world.One of the problems with our terminology is that "computer science" is generally used for the abstract, theoretical part of software.
This is misleading, because the subject really is a mathematical field, not scientific.
If it were scientific, the computer scientists would be performing experiments and developing hypotheses to explain how software works.
But that's not what they do; it's the "software engineers" trying to debug software that do things like that.And this leads to the problem that "software engineering" generally involves doing things that in other fields would be called "science".
In engineering, you are generally working with tools and materials whose behavior is well understood, so you can concentrate on design.
With software development, this isn't generally true.
An engineer designing a bridge or house or airplane can expect to work with detailed specs for all the available components.
With software, the equivalent information is usually proprietary and intentionally hidden from the people building the code.
Even in "open source" systems, the concept of "information hiding" is popular, and all too often this does mean that needed information is intentionally hidden from the person writing the code.
So the software engineer is working with poorly-documented material, and must develop using processes that test and discover the properties of the underlying stuff.Of course, there are some software engineers who don't do any debugging.
But we know how well this works.
Civil engineers might be able to develop this way, since they have access to full specs for their material.
Software engineers can't, because they are kept ignorant of the details of lower-level stuff.
As long as this is true, software engineering must have a large scientific component, to study and test the software as it's developed.
They must constantly develop and test hypotheses about their code, in order to get it to function as desired in an environment that is mostly hidden.Anyway, there's little chance of getting the terminology straight any time soon.
There's no chance of software people getting access to detailed specs for the underlying systems.
We even have laws in place that block the access to full information.
So software engineering can't really be true engineering, and software developers will continue to spend large parts of their time acting as experimental scientists in order to debug their software.
And they won't get much help from the computer scientists, who are spending most of their time working with the mathematics of the subject, while disparaging the real-world portion of their discipline as being "mere engineering".Now if we could only get the computer field to adopt the same definitions that other fields of engineering, science and mat use.
But that isn't going to happen any time soon.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231169</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233345</id>
	<title>Re:Perspective?</title>
	<author>commodore64\_love</author>
	<datestamp>1244305680000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Let's rewrite your words and the original article's words a little bit:</p><p>[Electrical] Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. Writing [circuit card VHDL] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [schematics].</p><p>[Automotive] Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. [Designing steering wheels and consoles] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [mechanical drawings].</p><p>[Civil] Engineering is trying to become a rigorous engineering discipline. It's not quite there yet. [Designing roads and bridges] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [surveys].</p><p>.<br>I call bullshit.  ALL engineering disciplines involve creativity, require humans to maintain the design, and an ability to preplan how customers will interact with the finished product.  It sounds to me like this professor/programmer/whatever is trying to make excuses for why software is not as reliable as other engineered products.</p></htmltext>
<tokenext>Let 's rewrite your words and the original article 's words a little bit : [ Electrical ] Engineering is trying to become a rigorous engineering discipline .
It 's not quite there yet .
Writing [ circuit card VHDL ] is a creative process , arguably even an artistic one...... But maintainability crucially involves humans , and their ability to grasp the meaning and intention of [ schematics ] .
[ Automotive ] Engineering is trying to become a rigorous engineering discipline .
It 's not quite there yet .
[ Designing steering wheels and consoles ] is a creative process , arguably even an artistic one...... But maintainability crucially involves humans , and their ability to grasp the meaning and intention of [ mechanical drawings ] .
[ Civil ] Engineering is trying to become a rigorous engineering discipline .
It 's not quite there yet .
[ Designing roads and bridges ] is a creative process , arguably even an artistic one...... But maintainability crucially involves humans , and their ability to grasp the meaning and intention of [ surveys ] ..I call bullshit .
ALL engineering disciplines involve creativity , require humans to maintain the design , and an ability to preplan how customers will interact with the finished product .
It sounds to me like this professor/programmer/whatever is trying to make excuses for why software is not as reliable as other engineered products .</tokentext>
<sentencetext>Let's rewrite your words and the original article's words a little bit:[Electrical] Engineering is trying to become a rigorous engineering discipline.
It's not quite there yet.
Writing [circuit card VHDL] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [schematics].
[Automotive] Engineering is trying to become a rigorous engineering discipline.
It's not quite there yet.
[Designing steering wheels and consoles] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [mechanical drawings].
[Civil] Engineering is trying to become a rigorous engineering discipline.
It's not quite there yet.
[Designing roads and bridges] is a creative process, arguably even an artistic one...... But maintainability crucially involves humans, and their ability to grasp the meaning and intention of [surveys]..I call bullshit.
ALL engineering disciplines involve creativity, require humans to maintain the design, and an ability to preplan how customers will interact with the finished product.
It sounds to me like this professor/programmer/whatever is trying to make excuses for why software is not as reliable as other engineered products.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231365</id>
	<title>Fashion versus maths</title>
	<author>hutchike</author>
	<datestamp>1244285340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Software Engineering = fashion<br>Computer Science = maths</p><p>Simple. Nuff said.</p></htmltext>
<tokenext>Software Engineering = fashionComputer Science = mathsSimple .
Nuff said .</tokentext>
<sentencetext>Software Engineering = fashionComputer Science = mathsSimple.
Nuff said.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231927</id>
	<title>Wicked Problem</title>
	<author>node159</author>
	<datestamp>1244294880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Oddly one one has raised the most simple of issues at the heart of all software development, the reality that the majority of software development is with the resolution of a wicked problem (http://en.wikipedia.org/wiki/Wicked\_problem, problem where you can only get the input parameters by solving the problem first), this is in stark contrast of other engineering disciplines, with System Engineering being the only one that comes at all close.</p><p>When you look at the various engineering disciplines, they problems they are trying to solve may be complex and difficulty, but fundamentally the input parameters and expected output are known. Not to be trite but there are only so many ways to build a bridge.</p></htmltext>
<tokenext>Oddly one one has raised the most simple of issues at the heart of all software development , the reality that the majority of software development is with the resolution of a wicked problem ( http : //en.wikipedia.org/wiki/Wicked \ _problem , problem where you can only get the input parameters by solving the problem first ) , this is in stark contrast of other engineering disciplines , with System Engineering being the only one that comes at all close.When you look at the various engineering disciplines , they problems they are trying to solve may be complex and difficulty , but fundamentally the input parameters and expected output are known .
Not to be trite but there are only so many ways to build a bridge .</tokentext>
<sentencetext>Oddly one one has raised the most simple of issues at the heart of all software development, the reality that the majority of software development is with the resolution of a wicked problem (http://en.wikipedia.org/wiki/Wicked\_problem, problem where you can only get the input parameters by solving the problem first), this is in stark contrast of other engineering disciplines, with System Engineering being the only one that comes at all close.When you look at the various engineering disciplines, they problems they are trying to solve may be complex and difficulty, but fundamentally the input parameters and expected output are known.
Not to be trite but there are only so many ways to build a bridge.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234807</id>
	<title>Re:Before we get all sweaty about terms</title>
	<author>Jaime2</author>
	<datestamp>1244316360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>More specifically, an Engineer is someone who can claim that a system won't kill people and can legally transfer the responsibility for the lives of the users from the construction company to himself.  What we don't have in the software industry is the accountability that forces Engineers to be rigorous.  Sure, we software developers can claim that we use rigorous processes, but every time something doesn't work, we shrug it off and get to work on the fix.  If a real Engineer screws up big just once, he loses his license and/or goes to jail.<br>
<br>
What makes licensed Professional Engineers so mad about the computer industry's flippant use of the word engineer is that it dilutes the title that they worked hard to obtain and that gives them a very unique position of responsibility in certain aspects of life.  Don't think of an Engineer as someone who is good at any specific thing, think about them as a gatekeeper of the use of technology in public places.</htmltext>
<tokenext>More specifically , an Engineer is someone who can claim that a system wo n't kill people and can legally transfer the responsibility for the lives of the users from the construction company to himself .
What we do n't have in the software industry is the accountability that forces Engineers to be rigorous .
Sure , we software developers can claim that we use rigorous processes , but every time something does n't work , we shrug it off and get to work on the fix .
If a real Engineer screws up big just once , he loses his license and/or goes to jail .
What makes licensed Professional Engineers so mad about the computer industry 's flippant use of the word engineer is that it dilutes the title that they worked hard to obtain and that gives them a very unique position of responsibility in certain aspects of life .
Do n't think of an Engineer as someone who is good at any specific thing , think about them as a gatekeeper of the use of technology in public places .</tokentext>
<sentencetext>More specifically, an Engineer is someone who can claim that a system won't kill people and can legally transfer the responsibility for the lives of the users from the construction company to himself.
What we don't have in the software industry is the accountability that forces Engineers to be rigorous.
Sure, we software developers can claim that we use rigorous processes, but every time something doesn't work, we shrug it off and get to work on the fix.
If a real Engineer screws up big just once, he loses his license and/or goes to jail.
What makes licensed Professional Engineers so mad about the computer industry's flippant use of the word engineer is that it dilutes the title that they worked hard to obtain and that gives them a very unique position of responsibility in certain aspects of life.
Don't think of an Engineer as someone who is good at any specific thing, think about them as a gatekeeper of the use of technology in public places.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230637</id>
	<title>Formal definition of a software engineer</title>
	<author>OutputLogic</author>
	<datestamp>1244230740000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext> Here is a formal definition of a Computer Software Engineer occupation, according to the <a href="http://online.onetcenter.org/link/summary/15-1032.00" title="onetcenter.org" rel="nofollow">US Department Of Labor</a> [onetcenter.org]:
<br>   "Research, design, develop, and test operating systems-level software, compilers, and network distribution software for medical, industrial, military, communications, aerospace, business, scientific, and general computing applications. Set operational specifications and formulate and analyze software requirements. Apply principles and techniques of computer science, engineering, and mathematical analysis."<br> <br>

<a href="http://outputlogic.com/" title="outputlogic.com" rel="nofollow">OutputLogic</a> [outputlogic.com]</htmltext>
<tokenext>Here is a formal definition of a Computer Software Engineer occupation , according to the US Department Of Labor [ onetcenter.org ] : " Research , design , develop , and test operating systems-level software , compilers , and network distribution software for medical , industrial , military , communications , aerospace , business , scientific , and general computing applications .
Set operational specifications and formulate and analyze software requirements .
Apply principles and techniques of computer science , engineering , and mathematical analysis .
" OutputLogic [ outputlogic.com ]</tokentext>
<sentencetext> Here is a formal definition of a Computer Software Engineer occupation, according to the US Department Of Labor [onetcenter.org]:
   "Research, design, develop, and test operating systems-level software, compilers, and network distribution software for medical, industrial, military, communications, aerospace, business, scientific, and general computing applications.
Set operational specifications and formulate and analyze software requirements.
Apply principles and techniques of computer science, engineering, and mathematical analysis.
" 

OutputLogic [outputlogic.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577</id>
	<title>Is software "engineering" really engineering?</title>
	<author>Anonymous</author>
	<datestamp>1244229660000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>Going by the <a href="http://en.wikipedia.org/wiki/Engineering" title="wikipedia.org" rel="nofollow">wikipedia definition</a> [wikipedia.org] decisions made in typical software development cycles don't seem to rely on a justification based mathematical or physical analysis. Admittedly I might be generalising, but is it more of a soft-skill then? ie something that you acquire on your own rather than something that can be formally taught or imparted as training? Makes you wince when you see all those job adverts asking for programmers to work in their "engineering departments"...

Disc: I'm a coder myself, working in a structural engineering environment, so watching people design buildings around me feels more like "real" engineering...

Go on, mod me down now.</htmltext>
<tokenext>Going by the wikipedia definition [ wikipedia.org ] decisions made in typical software development cycles do n't seem to rely on a justification based mathematical or physical analysis .
Admittedly I might be generalising , but is it more of a soft-skill then ?
ie something that you acquire on your own rather than something that can be formally taught or imparted as training ?
Makes you wince when you see all those job adverts asking for programmers to work in their " engineering departments " .. . Disc : I 'm a coder myself , working in a structural engineering environment , so watching people design buildings around me feels more like " real " engineering.. . Go on , mod me down now .</tokentext>
<sentencetext>Going by the wikipedia definition [wikipedia.org] decisions made in typical software development cycles don't seem to rely on a justification based mathematical or physical analysis.
Admittedly I might be generalising, but is it more of a soft-skill then?
ie something that you acquire on your own rather than something that can be formally taught or imparted as training?
Makes you wince when you see all those job adverts asking for programmers to work in their "engineering departments"...

Disc: I'm a coder myself, working in a structural engineering environment, so watching people design buildings around me feels more like "real" engineering...

Go on, mod me down now.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28237641</id>
	<title>Similar Article</title>
	<author>Anonymous</author>
	<datestamp>1244293980000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Here's a similar blog-article:</p><p><a href="http://www.geocities.com/tablizer/science.htm" title="geocities.com" rel="nofollow">http://www.geocities.com/tablizer/science.htm</a> [geocities.com]<br>
&nbsp; &nbsp; &nbsp;</p></htmltext>
<tokenext>Here 's a similar blog-article : http : //www.geocities.com/tablizer/science.htm [ geocities.com ]      </tokentext>
<sentencetext>Here's a similar blog-article:http://www.geocities.com/tablizer/science.htm [geocities.com]
     </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232429</id>
	<title>Re:You're not Engineers. Get over it.</title>
	<author>InsertCleverUsername</author>
	<datestamp>1244299860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; No engineering degree = no engineer</p><p>Look...  I don't really care if I'm qualified to drive a train or not.</p><p>I create complex things that live inside the computer, using the constraints and software parts available, much like an engineer in the physical world works with constraints and existing parts to make something useful.  Unless you want to narrowly define engineering as designing physical things, I don't see your point.  Truth be told, I don't spend a lot of time worrying about semantics and titles --I earn too much money to care.</p></htmltext>
<tokenext>&gt; No engineering degree = no engineerLook... I do n't really care if I 'm qualified to drive a train or not.I create complex things that live inside the computer , using the constraints and software parts available , much like an engineer in the physical world works with constraints and existing parts to make something useful .
Unless you want to narrowly define engineering as designing physical things , I do n't see your point .
Truth be told , I do n't spend a lot of time worrying about semantics and titles --I earn too much money to care .</tokentext>
<sentencetext>&gt; No engineering degree = no engineerLook...  I don't really care if I'm qualified to drive a train or not.I create complex things that live inside the computer, using the constraints and software parts available, much like an engineer in the physical world works with constraints and existing parts to make something useful.
Unless you want to narrowly define engineering as designing physical things, I don't see your point.
Truth be told, I don't spend a lot of time worrying about semantics and titles --I earn too much money to care.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232047</id>
	<title>Software never fails, people decide it does</title>
	<author>Anonymous</author>
	<datestamp>1244296500000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>The statement that software engineering - which is a mislabel - cannot be a rigorous, formal system is so obvious that it might as well be one of those things we never think about until we have to and when we do think about it it's intuitively obvious.</p><p>Consider what will happen when you die, there are only three possibilities: You exist after you die and you like the results; you exist after you die and you do not like the results; you do not exist after you die.  All three possibilities are equally valid since we have no evidence of any of them.  If as it turns out, that when you die you cease to exist, it is not something you need to worry about.  Now, the thought probably terrifies you - it used to terrify me, too - until you realize something: if you cease to exist, <i>you will know nothing</i>.  You'll never know that you don't exist.</p><p>So consider the conditions of the existence of software.  Software is always perfect and is always the same, it never changes.  It does not rot, rust, age, get moldy, crumble, break, shatter or fail.  It never needs maintenance, lubrication, cleaning, sharpening, polishing, repair or replacement.  As long as the hardware that copies it makes identical copies, it is perfect and always will be perfect, except for the extremely rare and unusual case of deterioration of the storage media due to cosmic ray damage.  Which can be detected by mathematical algorithm, in which case, if there is another source, another perfect copy can be made and it's right back where it was.  Software is never defective and can never be defective other than the case I've given of the rare possibility of cosmic-ray damage to media or hardware failure in copying, and thus it never needs change, modification or updating.</p><p>Every year, every country makes changes to its tax laws.  Any software which must comply with those new changes has to be changed according to the decisions of tax accountants and lawyers as to what is needed to be in compliance.  If you have a cellular network and want to add new features, you have to modify the software - in the switches, the handsets, the gateways, and/or all of these - to be able to enable them to offer new features.  In both cases the software needs updating.</p><p>Both statements are true, but you might ask how they can be when they appear to be conflicting.  They're not, and I'll explain why.</p><p>Any software package, from a 1-line APL function to a 20 million-line COBOL behemoth application suite that runs a trillion dollar bank, large insurance company or government agency, only requires maintenance or change because in someone's subjective opinion it needs a change.  A bridge needs replacement when it collapses or when it is beyond its useful life; a building needs replacement under the same circumstances.  A piece of metal furniture needs replacement when its structure rusts into dust, fails or is unable to support a load due to metal fatigue.  These are objective facts, either the structure is usable or it isn't.  An engineer can determine by experience and judgment that the structure is at its lifespan limit or can point to signs of physical rust, deterioration, or structure failure indicators that prove their opinion.</p><p>Any declaration that a software package needs updating, change, or replacement is strictly based upon the subjective opinion of someone saying that it needs the work.  All software change is the result of some person's opinion that the change needs to be made and have no basis in reality except their opinion.  Their opinion is correct if you agree with them or if in your opinion you can't disagree with their opinion.  They may be correct that because of errors in how the software performs its desired function, need for new function, or need for changes in existing function, the software needs change, replacement or updating, but they can only be "correct" because it is considered that in someone's opinion they agree with their opinion that the change is needed.</p><p>But the claim by someone that a software package needs cha</p></htmltext>
<tokenext>The statement that software engineering - which is a mislabel - can not be a rigorous , formal system is so obvious that it might as well be one of those things we never think about until we have to and when we do think about it it 's intuitively obvious.Consider what will happen when you die , there are only three possibilities : You exist after you die and you like the results ; you exist after you die and you do not like the results ; you do not exist after you die .
All three possibilities are equally valid since we have no evidence of any of them .
If as it turns out , that when you die you cease to exist , it is not something you need to worry about .
Now , the thought probably terrifies you - it used to terrify me , too - until you realize something : if you cease to exist , you will know nothing .
You 'll never know that you do n't exist.So consider the conditions of the existence of software .
Software is always perfect and is always the same , it never changes .
It does not rot , rust , age , get moldy , crumble , break , shatter or fail .
It never needs maintenance , lubrication , cleaning , sharpening , polishing , repair or replacement .
As long as the hardware that copies it makes identical copies , it is perfect and always will be perfect , except for the extremely rare and unusual case of deterioration of the storage media due to cosmic ray damage .
Which can be detected by mathematical algorithm , in which case , if there is another source , another perfect copy can be made and it 's right back where it was .
Software is never defective and can never be defective other than the case I 've given of the rare possibility of cosmic-ray damage to media or hardware failure in copying , and thus it never needs change , modification or updating.Every year , every country makes changes to its tax laws .
Any software which must comply with those new changes has to be changed according to the decisions of tax accountants and lawyers as to what is needed to be in compliance .
If you have a cellular network and want to add new features , you have to modify the software - in the switches , the handsets , the gateways , and/or all of these - to be able to enable them to offer new features .
In both cases the software needs updating.Both statements are true , but you might ask how they can be when they appear to be conflicting .
They 're not , and I 'll explain why.Any software package , from a 1-line APL function to a 20 million-line COBOL behemoth application suite that runs a trillion dollar bank , large insurance company or government agency , only requires maintenance or change because in someone 's subjective opinion it needs a change .
A bridge needs replacement when it collapses or when it is beyond its useful life ; a building needs replacement under the same circumstances .
A piece of metal furniture needs replacement when its structure rusts into dust , fails or is unable to support a load due to metal fatigue .
These are objective facts , either the structure is usable or it is n't .
An engineer can determine by experience and judgment that the structure is at its lifespan limit or can point to signs of physical rust , deterioration , or structure failure indicators that prove their opinion.Any declaration that a software package needs updating , change , or replacement is strictly based upon the subjective opinion of someone saying that it needs the work .
All software change is the result of some person 's opinion that the change needs to be made and have no basis in reality except their opinion .
Their opinion is correct if you agree with them or if in your opinion you ca n't disagree with their opinion .
They may be correct that because of errors in how the software performs its desired function , need for new function , or need for changes in existing function , the software needs change , replacement or updating , but they can only be " correct " because it is considered that in someone 's opinion they agree with their opinion that the change is needed.But the claim by someone that a software package needs cha</tokentext>
<sentencetext>The statement that software engineering - which is a mislabel - cannot be a rigorous, formal system is so obvious that it might as well be one of those things we never think about until we have to and when we do think about it it's intuitively obvious.Consider what will happen when you die, there are only three possibilities: You exist after you die and you like the results; you exist after you die and you do not like the results; you do not exist after you die.
All three possibilities are equally valid since we have no evidence of any of them.
If as it turns out, that when you die you cease to exist, it is not something you need to worry about.
Now, the thought probably terrifies you - it used to terrify me, too - until you realize something: if you cease to exist, you will know nothing.
You'll never know that you don't exist.So consider the conditions of the existence of software.
Software is always perfect and is always the same, it never changes.
It does not rot, rust, age, get moldy, crumble, break, shatter or fail.
It never needs maintenance, lubrication, cleaning, sharpening, polishing, repair or replacement.
As long as the hardware that copies it makes identical copies, it is perfect and always will be perfect, except for the extremely rare and unusual case of deterioration of the storage media due to cosmic ray damage.
Which can be detected by mathematical algorithm, in which case, if there is another source, another perfect copy can be made and it's right back where it was.
Software is never defective and can never be defective other than the case I've given of the rare possibility of cosmic-ray damage to media or hardware failure in copying, and thus it never needs change, modification or updating.Every year, every country makes changes to its tax laws.
Any software which must comply with those new changes has to be changed according to the decisions of tax accountants and lawyers as to what is needed to be in compliance.
If you have a cellular network and want to add new features, you have to modify the software - in the switches, the handsets, the gateways, and/or all of these - to be able to enable them to offer new features.
In both cases the software needs updating.Both statements are true, but you might ask how they can be when they appear to be conflicting.
They're not, and I'll explain why.Any software package, from a 1-line APL function to a 20 million-line COBOL behemoth application suite that runs a trillion dollar bank, large insurance company or government agency, only requires maintenance or change because in someone's subjective opinion it needs a change.
A bridge needs replacement when it collapses or when it is beyond its useful life; a building needs replacement under the same circumstances.
A piece of metal furniture needs replacement when its structure rusts into dust, fails or is unable to support a load due to metal fatigue.
These are objective facts, either the structure is usable or it isn't.
An engineer can determine by experience and judgment that the structure is at its lifespan limit or can point to signs of physical rust, deterioration, or structure failure indicators that prove their opinion.Any declaration that a software package needs updating, change, or replacement is strictly based upon the subjective opinion of someone saying that it needs the work.
All software change is the result of some person's opinion that the change needs to be made and have no basis in reality except their opinion.
Their opinion is correct if you agree with them or if in your opinion you can't disagree with their opinion.
They may be correct that because of errors in how the software performs its desired function, need for new function, or need for changes in existing function, the software needs change, replacement or updating, but they can only be "correct" because it is considered that in someone's opinion they agree with their opinion that the change is needed.But the claim by someone that a software package needs cha</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232283
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233203
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231169
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232651
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28239351
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231169
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28238369
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233345
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232221
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230655
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230811
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28235583
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230519
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231415
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231089
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28235807
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28240513
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230765
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232419
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232919
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28241161
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230613
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231759
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231033
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231501
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230897
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231871
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234807
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230653
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231033
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236389
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230767
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230637
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28243285
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231133
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234177
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236045
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231275
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231699
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230723
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230981
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230803
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231943
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230691
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232929
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232177
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28239611
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231927
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232177
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236139
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230729
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230519
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28237519
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28289777
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231219
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230691
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232503
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233195
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231561
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232367
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231269
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231995
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231169
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236505
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28256645
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234153
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231389
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28238545
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232339
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28239105
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231475
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232177
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233933
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232429
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230613
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232679
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231169
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232651
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233509
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_06_0210229_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231179
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230619
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231275
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28240513
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231561
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230767
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231475
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231927
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28256645
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28243285
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230577
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230653
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232283
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233203
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230613
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232679
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231759
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230803
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231943
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230729
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230981
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230691
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232929
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232503
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230723
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231699
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230637
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230765
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231089
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28235807
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230897
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231871
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232047
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231781
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232069
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230659
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230949
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230793
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230747
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232221
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231033
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236389
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231501
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28239105
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231389
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28238545
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231219
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234153
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232177
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233933
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236139
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28239611
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230903
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230523
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28241161
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230717
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233195
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231169
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232651
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233509
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28239351
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28238369
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236505
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231179
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28233345
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232201
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230557
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232429
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232367
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230607
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230631
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231269
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232419
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28235583
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231133
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234177
----http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28236045
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28234807
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230655
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230811
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232919
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232339
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231995
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28232025
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231135
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_06_0210229.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28230519
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28231415
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28237519
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_06_0210229.28289777
</commentlist>
</conversation>
