<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_11_16_1448204</id>
	<title>Becoming Agile</title>
	<author>samzenpus</author>
	<datestamp>1258385340000</datestamp>
	<htmltext><a href="mailto:iml.reviewer@gmail.com" rel="nofollow">IraLaefsky</a> writes <i>"The appropriately titled <em>Becoming Agile: In An Imperfect World</em> by Greg Smith and Ahmed Sidky offers a realistic path to the family of Agile practices which have become prevalent in software development in the last few years.  This family of approaches to software development has been widely adopted in the past decade to replace the traditional <a href="http://en.wikipedia.org/wiki/Waterfall\_model">Waterfall Model</a> of software development, described in a 1970 article by Winston W. Royce <a href="http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf">'Managing the Development of Large Software Systems.'</a>  The Waterfall Model stressed rigid functional and design specification of the program(s) to be constructed in advance of any code development.  While the this methodology and other early formal tools for Software Engineering were infinitely preferable to the chaos and ad-hoc programming-without-design practices of early systems, these first tools ignored the fallibility of initial interviews used to construct initial design and often resulted in massive time and cost overruns."</i> Read below for the rest of IraLaefsky's review.</htmltext>
<tokenext>IraLaefsky writes " The appropriately titled Becoming Agile : In An Imperfect World by Greg Smith and Ahmed Sidky offers a realistic path to the family of Agile practices which have become prevalent in software development in the last few years .
This family of approaches to software development has been widely adopted in the past decade to replace the traditional Waterfall Model of software development , described in a 1970 article by Winston W. Royce 'Managing the Development of Large Software Systems .
' The Waterfall Model stressed rigid functional and design specification of the program ( s ) to be constructed in advance of any code development .
While the this methodology and other early formal tools for Software Engineering were infinitely preferable to the chaos and ad-hoc programming-without-design practices of early systems , these first tools ignored the fallibility of initial interviews used to construct initial design and often resulted in massive time and cost overruns .
" Read below for the rest of IraLaefsky 's review .</tokentext>
<sentencetext>IraLaefsky writes "The appropriately titled Becoming Agile: In An Imperfect World by Greg Smith and Ahmed Sidky offers a realistic path to the family of Agile practices which have become prevalent in software development in the last few years.
This family of approaches to software development has been widely adopted in the past decade to replace the traditional Waterfall Model of software development, described in a 1970 article by Winston W. Royce 'Managing the Development of Large Software Systems.
'  The Waterfall Model stressed rigid functional and design specification of the program(s) to be constructed in advance of any code development.
While the this methodology and other early formal tools for Software Engineering were infinitely preferable to the chaos and ad-hoc programming-without-design practices of early systems, these first tools ignored the fallibility of initial interviews used to construct initial design and often resulted in massive time and cost overruns.
" Read below for the rest of IraLaefsky's review.</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121896</id>
	<title>Re:How to turn your skilled employees into cogs</title>
	<author>Anonymous</author>
	<datestamp>1258367520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>We have to evaluate agile based on it's real world results, not what the books describe.</p></div><p>As the third or fourth biggest game studio in the world, I can assure you about real world results.<nobr> <wbr></nobr>:)</p><p><div class="quote"><p>In the real-world, agile creates a very high-pressure work environment, where personal space is non-existent, everyone is watching you, and your work is constantly on display. This pressure can produce productivity gains but I would say that in the long run these gains aren't sustainable.</p></div><p>Not true. Your work is not constantly on display, the advancement of the is. The client is happier this way and if he chooses to change requirements around, it is less of a deathblow to the project deadline than using the "waterfall" approach. Also, in the long run, productivity gains are the same, as after 2 years of using agile development, I can attest to it.</p><p><div class="quote"><p>I think agile is a very poor fit for your average introvert, which, imagine that, describes most programmers very well.</p></div><p>Then you should review your hiring practices. If your employee can't follow daily stand-up meetings or scrums, then why is he working for you? If he can't express his ideas properly, how is he going to advance and evolve as a developer?</p><p><div class="quote"><p>Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity.</p></div><p>Then those managers are crap. Thanks to agile development, a manager can actually see if stories are getting done and how much time was spent on it. And with agile development, over time, stories can be more precisely poker-planned when finding out how much time tasks will actually take.</p><p>Agile development is one thing, actually doing it right is another. It does work well, I can attest to it.</p></div>
	</htmltext>
<tokenext>We have to evaluate agile based on it 's real world results , not what the books describe.As the third or fourth biggest game studio in the world , I can assure you about real world results .
: ) In the real-world , agile creates a very high-pressure work environment , where personal space is non-existent , everyone is watching you , and your work is constantly on display .
This pressure can produce productivity gains but I would say that in the long run these gains are n't sustainable.Not true .
Your work is not constantly on display , the advancement of the is .
The client is happier this way and if he chooses to change requirements around , it is less of a deathblow to the project deadline than using the " waterfall " approach .
Also , in the long run , productivity gains are the same , as after 2 years of using agile development , I can attest to it.I think agile is a very poor fit for your average introvert , which , imagine that , describes most programmers very well.Then you should review your hiring practices .
If your employee ca n't follow daily stand-up meetings or scrums , then why is he working for you ?
If he ca n't express his ideas properly , how is he going to advance and evolve as a developer ? Often times , managers walk through a room , and if they see a bunch of people typing away or debating some design issue , then they see that busyness as productivity.Then those managers are crap .
Thanks to agile development , a manager can actually see if stories are getting done and how much time was spent on it .
And with agile development , over time , stories can be more precisely poker-planned when finding out how much time tasks will actually take.Agile development is one thing , actually doing it right is another .
It does work well , I can attest to it .</tokentext>
<sentencetext>We have to evaluate agile based on it's real world results, not what the books describe.As the third or fourth biggest game studio in the world, I can assure you about real world results.
:)In the real-world, agile creates a very high-pressure work environment, where personal space is non-existent, everyone is watching you, and your work is constantly on display.
This pressure can produce productivity gains but I would say that in the long run these gains aren't sustainable.Not true.
Your work is not constantly on display, the advancement of the is.
The client is happier this way and if he chooses to change requirements around, it is less of a deathblow to the project deadline than using the "waterfall" approach.
Also, in the long run, productivity gains are the same, as after 2 years of using agile development, I can attest to it.I think agile is a very poor fit for your average introvert, which, imagine that, describes most programmers very well.Then you should review your hiring practices.
If your employee can't follow daily stand-up meetings or scrums, then why is he working for you?
If he can't express his ideas properly, how is he going to advance and evolve as a developer?Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity.Then those managers are crap.
Thanks to agile development, a manager can actually see if stories are getting done and how much time was spent on it.
And with agile development, over time, stories can be more precisely poker-planned when finding out how much time tasks will actually take.Agile development is one thing, actually doing it right is another.
It does work well, I can attest to it.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116762</id>
	<title>Re:Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258393500000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Don't mistake a "fad" with just how things are done during a particular period of time, due to the knowledge and technology that was available then.</p><p>Traveling long distances by horse wasn't a "fad". Before trains, automobiles, and planes were invented, it was the only reasonable method available, even if we drive cars now.</p><p>Ruby on Rails is a "fad". Everything we can do in Ruby using Rails could be done using Perl, Python, PHP, Java, C#, and almost all other languages, using a variety of different frameworks. It's just that Ruby got lots and lots and lots of hype online from stupid college students, HR idiots and managers who were more concerned with being "trendy" than with efficiently producing high-quality software.</p><p>Agile methodologies are clearly not a fad. They have allowed us to build larger and more complex software systems using fewer resources. This was something we could not easily do before, using existing methodologies, and even today we have few alternatives.</p></htmltext>
<tokenext>Do n't mistake a " fad " with just how things are done during a particular period of time , due to the knowledge and technology that was available then.Traveling long distances by horse was n't a " fad " .
Before trains , automobiles , and planes were invented , it was the only reasonable method available , even if we drive cars now.Ruby on Rails is a " fad " .
Everything we can do in Ruby using Rails could be done using Perl , Python , PHP , Java , C # , and almost all other languages , using a variety of different frameworks .
It 's just that Ruby got lots and lots and lots of hype online from stupid college students , HR idiots and managers who were more concerned with being " trendy " than with efficiently producing high-quality software.Agile methodologies are clearly not a fad .
They have allowed us to build larger and more complex software systems using fewer resources .
This was something we could not easily do before , using existing methodologies , and even today we have few alternatives .</tokentext>
<sentencetext>Don't mistake a "fad" with just how things are done during a particular period of time, due to the knowledge and technology that was available then.Traveling long distances by horse wasn't a "fad".
Before trains, automobiles, and planes were invented, it was the only reasonable method available, even if we drive cars now.Ruby on Rails is a "fad".
Everything we can do in Ruby using Rails could be done using Perl, Python, PHP, Java, C#, and almost all other languages, using a variety of different frameworks.
It's just that Ruby got lots and lots and lots of hype online from stupid college students, HR idiots and managers who were more concerned with being "trendy" than with efficiently producing high-quality software.Agile methodologies are clearly not a fad.
They have allowed us to build larger and more complex software systems using fewer resources.
This was something we could not easily do before, using existing methodologies, and even today we have few alternatives.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119362</id>
	<title>Re:Oh, THAT strawman</title>
	<author>DragonWriter</author>
	<datestamp>1258401600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Oh, right, yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the "agile" crowd, and wasn't applied that way.</p></div></blockquote><p>Certainly, in many times and places, the waterfall model is (and, in some particularly backwards places, still <i>is</i>, IME) applied in largely the way portrayed by the Agile crowd.</p><blockquote><div><p>Ever heard of iterations? Right. Apparently the agile crowd still never heard that anyone else uses those.</p></div></blockquote><p>Certainly, most of the writings I've read on Agile methodologies by practitioners/advocates of those methodologies have acknowledged that Agile methodologies are largely codifications of best practices developed in places that were working with internal modifications of some older methodology, mostly the basic Waterfall Model, and that iterations are certainly one of those practices. The fallacy of you seem to be describing seems to be more of an anti-Agile crowd strawman of the Agile position than an pro-Agile strawman of the pre-Agile status quo.</p></div>
	</htmltext>
<tokenext>Oh , right , yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the " agile " crowd , and was n't applied that way.Certainly , in many times and places , the waterfall model is ( and , in some particularly backwards places , still is , IME ) applied in largely the way portrayed by the Agile crowd.Ever heard of iterations ?
Right. Apparently the agile crowd still never heard that anyone else uses those.Certainly , most of the writings I 've read on Agile methodologies by practitioners/advocates of those methodologies have acknowledged that Agile methodologies are largely codifications of best practices developed in places that were working with internal modifications of some older methodology , mostly the basic Waterfall Model , and that iterations are certainly one of those practices .
The fallacy of you seem to be describing seems to be more of an anti-Agile crowd strawman of the Agile position than an pro-Agile strawman of the pre-Agile status quo .</tokentext>
<sentencetext>Oh, right, yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the "agile" crowd, and wasn't applied that way.Certainly, in many times and places, the waterfall model is (and, in some particularly backwards places, still is, IME) applied in largely the way portrayed by the Agile crowd.Ever heard of iterations?
Right. Apparently the agile crowd still never heard that anyone else uses those.Certainly, most of the writings I've read on Agile methodologies by practitioners/advocates of those methodologies have acknowledged that Agile methodologies are largely codifications of best practices developed in places that were working with internal modifications of some older methodology, mostly the basic Waterfall Model, and that iterations are certainly one of those practices.
The fallacy of you seem to be describing seems to be more of an anti-Agile crowd strawman of the Agile position than an pro-Agile strawman of the pre-Agile status quo.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116522</id>
	<title>Oh and the second agile dogma is stupid</title>
	<author>Anonymous</author>
	<datestamp>1258392480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>That one about working software vs comprehensive documentation. I mean what company was it where they actually had a problem with too much documentation. All my experience has been in IT people don't want to document anything and that dogma would probably make them think not only is it ok to not document but it's actually a good idea.</htmltext>
<tokenext>That one about working software vs comprehensive documentation .
I mean what company was it where they actually had a problem with too much documentation .
All my experience has been in IT people do n't want to document anything and that dogma would probably make them think not only is it ok to not document but it 's actually a good idea .</tokentext>
<sentencetext>That one about working software vs comprehensive documentation.
I mean what company was it where they actually had a problem with too much documentation.
All my experience has been in IT people don't want to document anything and that dogma would probably make them think not only is it ok to not document but it's actually a good idea.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119026</id>
	<title>Re:Methodology fads</title>
	<author>quanticle</author>
	<datestamp>1258400700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>But what do you do if the spec. sheet is wrong? What do you do if the spec. sheet is unclear?  How about if you can't meet the requirements given by the time specified?  Methodology answers all those questions.</p></htmltext>
<tokenext>But what do you do if the spec .
sheet is wrong ?
What do you do if the spec .
sheet is unclear ?
How about if you ca n't meet the requirements given by the time specified ?
Methodology answers all those questions .</tokentext>
<sentencetext>But what do you do if the spec.
sheet is wrong?
What do you do if the spec.
sheet is unclear?
How about if you can't meet the requirements given by the time specified?
Methodology answers all those questions.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116120</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116144</id>
	<title>It's easy to stay fit...</title>
	<author>XPeter</author>
	<datestamp>1258390620000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>0</modscore>
	<htmltext>I eat whatever I want, whenever I want.

But I also have swim practice two hours a day six days a week<nobr> <wbr></nobr>:)</htmltext>
<tokenext>I eat whatever I want , whenever I want .
But I also have swim practice two hours a day six days a week : )</tokentext>
<sentencetext>I eat whatever I want, whenever I want.
But I also have swim practice two hours a day six days a week :)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121380</id>
	<title>Re:PyPy - crashing and burning with "agile".</title>
	<author>recharged95</author>
	<datestamp>1258365600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Why can't we just call a <i>"death march"</i><nobr> <wbr></nobr>.... just a failed project (or project that will fail).
<br>
<br>
All these buzzwords and cliq names are just building a fantasy environment.</htmltext>
<tokenext>Why ca n't we just call a " death march " .... just a failed project ( or project that will fail ) .
All these buzzwords and cliq names are just building a fantasy environment .</tokentext>
<sentencetext>Why can't we just call a "death march" .... just a failed project (or project that will fail).
All these buzzwords and cliq names are just building a fantasy environment.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116390</id>
	<title>Bizarre Covers</title>
	<author>Tarlus</author>
	<datestamp>1258391820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I swear, between <a href="http://oreilly.com/store/" title="oreilly.com">O'Reilly's</a> [oreilly.com] animals and <a href="http://www.manning.com/" title="manning.com">Manning's</a> [manning.com] depictions of people from different eras and cultures, I'd say a picture of a guy with a dead bird tucked in his belt is the most random choice for the cover of a programming book that I've ever seen.</htmltext>
<tokenext>I swear , between O'Reilly 's [ oreilly.com ] animals and Manning 's [ manning.com ] depictions of people from different eras and cultures , I 'd say a picture of a guy with a dead bird tucked in his belt is the most random choice for the cover of a programming book that I 've ever seen .</tokentext>
<sentencetext>I swear, between O'Reilly's [oreilly.com] animals and Manning's [manning.com] depictions of people from different eras and cultures, I'd say a picture of a guy with a dead bird tucked in his belt is the most random choice for the cover of a programming book that I've ever seen.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30132062</id>
	<title>Re:Methodology fads</title>
	<author>sjames</author>
	<datestamp>1258486380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Every last one of them seems to look at an effective team of bright people and attempts to codify their practices into a rulebook a micro-manager can use to make monkeys perform in a similar way. All ignore that the key to success was that the team members were bright and flexible and would have been successful with any "methodology" provided that the manager was smart enough to  do his job (run interference with other management) while they get their job done in whatever way works best for them free of interference.</p><p>Waterfall works fine when modified by such a team. They just have the good sense to see well in advance it isn't gelling yet and that lessons have been learned, so they cycle it back through. Repeat as necessary. Then someone sees that and decides more is better so they decide it must recycle every week. They throw out the part about seeing if it's gelling or if lessons have been learned since the id10ts they're working with wouldn't know either of those. They see the bright team pairing off as needed for some intense discussion or code review, so they decide (again, more is better) that's how programmers should work 100\% of the time. They throw out the "as needed" part since, once again, the id10ts they're working with don't know when that is.</p><p>Meanwhile, and this is perhaps the one and only real benefit, the actually bright programmers tell the manager "we're using an agile style" so he'll shut up and let them get to work satisfied that his department has that all important bullet point. Alternatively where the manager is good as well, that's what he tells the id10ts above him so they won't stick their fingers in the pie and prevent his team from doing what he knows they do best.</p><p>In truth, it matters little what you call it. Sometimes it's best to close your door and hack it out. Sometimes an extra pair of eyes is very helpful. Sometimes it becomes apparent that the system as-specified isn't going to work and needs revision. The better programmers code with that future possibility in mind so it won't all have to be thrown out.</p><p>Big hint, if the discussion ever turns to whether or not something is or is not [insert flavor of the day here], and the team's future actions depend on the outcome of the discussion, you're doing it wrong. Your team may be missing the all-important mentors and de-facto leaders who don't need [flavor of the day] to know when to re-group the project.</p></htmltext>
<tokenext>Every last one of them seems to look at an effective team of bright people and attempts to codify their practices into a rulebook a micro-manager can use to make monkeys perform in a similar way .
All ignore that the key to success was that the team members were bright and flexible and would have been successful with any " methodology " provided that the manager was smart enough to do his job ( run interference with other management ) while they get their job done in whatever way works best for them free of interference.Waterfall works fine when modified by such a team .
They just have the good sense to see well in advance it is n't gelling yet and that lessons have been learned , so they cycle it back through .
Repeat as necessary .
Then someone sees that and decides more is better so they decide it must recycle every week .
They throw out the part about seeing if it 's gelling or if lessons have been learned since the id10ts they 're working with would n't know either of those .
They see the bright team pairing off as needed for some intense discussion or code review , so they decide ( again , more is better ) that 's how programmers should work 100 \ % of the time .
They throw out the " as needed " part since , once again , the id10ts they 're working with do n't know when that is.Meanwhile , and this is perhaps the one and only real benefit , the actually bright programmers tell the manager " we 're using an agile style " so he 'll shut up and let them get to work satisfied that his department has that all important bullet point .
Alternatively where the manager is good as well , that 's what he tells the id10ts above him so they wo n't stick their fingers in the pie and prevent his team from doing what he knows they do best.In truth , it matters little what you call it .
Sometimes it 's best to close your door and hack it out .
Sometimes an extra pair of eyes is very helpful .
Sometimes it becomes apparent that the system as-specified is n't going to work and needs revision .
The better programmers code with that future possibility in mind so it wo n't all have to be thrown out.Big hint , if the discussion ever turns to whether or not something is or is not [ insert flavor of the day here ] , and the team 's future actions depend on the outcome of the discussion , you 're doing it wrong .
Your team may be missing the all-important mentors and de-facto leaders who do n't need [ flavor of the day ] to know when to re-group the project .</tokentext>
<sentencetext>Every last one of them seems to look at an effective team of bright people and attempts to codify their practices into a rulebook a micro-manager can use to make monkeys perform in a similar way.
All ignore that the key to success was that the team members were bright and flexible and would have been successful with any "methodology" provided that the manager was smart enough to  do his job (run interference with other management) while they get their job done in whatever way works best for them free of interference.Waterfall works fine when modified by such a team.
They just have the good sense to see well in advance it isn't gelling yet and that lessons have been learned, so they cycle it back through.
Repeat as necessary.
Then someone sees that and decides more is better so they decide it must recycle every week.
They throw out the part about seeing if it's gelling or if lessons have been learned since the id10ts they're working with wouldn't know either of those.
They see the bright team pairing off as needed for some intense discussion or code review, so they decide (again, more is better) that's how programmers should work 100\% of the time.
They throw out the "as needed" part since, once again, the id10ts they're working with don't know when that is.Meanwhile, and this is perhaps the one and only real benefit, the actually bright programmers tell the manager "we're using an agile style" so he'll shut up and let them get to work satisfied that his department has that all important bullet point.
Alternatively where the manager is good as well, that's what he tells the id10ts above him so they won't stick their fingers in the pie and prevent his team from doing what he knows they do best.In truth, it matters little what you call it.
Sometimes it's best to close your door and hack it out.
Sometimes an extra pair of eyes is very helpful.
Sometimes it becomes apparent that the system as-specified isn't going to work and needs revision.
The better programmers code with that future possibility in mind so it won't all have to be thrown out.Big hint, if the discussion ever turns to whether or not something is or is not [insert flavor of the day here], and the team's future actions depend on the outcome of the discussion, you're doing it wrong.
Your team may be missing the all-important mentors and de-facto leaders who don't need [flavor of the day] to know when to re-group the project.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119106</id>
	<title>Agile is good for GUI/web projects</title>
	<author>saigon\_from\_europe</author>
	<datestamp>1258400940000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Scrum has one good point - show your code to your customer often and apply his comments. But that works only for GUI or web. I cannot imagine that in, say, medical software. For instance, one of my colleagues had to optimize crucial piece of code (some heavy math for CAT scanner). It took him several months. Only thing he could say to the customer was like "it is now two times faster" or "it is now 3.45 times faster". Not something you can really get some useful feedback on.</p><p>In another company, we were supposed to do a project for GE, and there was some serious GUI there, but their office was some several thousands miles from us and I really didn't know how we would make regular meetings with them as Scrum required. Also, they had some very elaborate specs and they did not see too much point of Scrum methodology. In some other situation, that project would be a perfect one for Scrum.</p><p>PS One thing I don't like with Agile evangelists is that Agile (Scrum in this case) is always right. It's either "what are you doing is not Scrum" or "you did not adapt Scrum to your needs", but its never the problem in Scrum.</p></htmltext>
<tokenext>Scrum has one good point - show your code to your customer often and apply his comments .
But that works only for GUI or web .
I can not imagine that in , say , medical software .
For instance , one of my colleagues had to optimize crucial piece of code ( some heavy math for CAT scanner ) .
It took him several months .
Only thing he could say to the customer was like " it is now two times faster " or " it is now 3.45 times faster " .
Not something you can really get some useful feedback on.In another company , we were supposed to do a project for GE , and there was some serious GUI there , but their office was some several thousands miles from us and I really did n't know how we would make regular meetings with them as Scrum required .
Also , they had some very elaborate specs and they did not see too much point of Scrum methodology .
In some other situation , that project would be a perfect one for Scrum.PS One thing I do n't like with Agile evangelists is that Agile ( Scrum in this case ) is always right .
It 's either " what are you doing is not Scrum " or " you did not adapt Scrum to your needs " , but its never the problem in Scrum .</tokentext>
<sentencetext>Scrum has one good point - show your code to your customer often and apply his comments.
But that works only for GUI or web.
I cannot imagine that in, say, medical software.
For instance, one of my colleagues had to optimize crucial piece of code (some heavy math for CAT scanner).
It took him several months.
Only thing he could say to the customer was like "it is now two times faster" or "it is now 3.45 times faster".
Not something you can really get some useful feedback on.In another company, we were supposed to do a project for GE, and there was some serious GUI there, but their office was some several thousands miles from us and I really didn't know how we would make regular meetings with them as Scrum required.
Also, they had some very elaborate specs and they did not see too much point of Scrum methodology.
In some other situation, that project would be a perfect one for Scrum.PS One thing I don't like with Agile evangelists is that Agile (Scrum in this case) is always right.
It's either "what are you doing is not Scrum" or "you did not adapt Scrum to your needs", but its never the problem in Scrum.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121394</id>
	<title>Re:PyPy - crashing and burning with "agile".</title>
	<author>stygianguest</author>
	<datestamp>1258365720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It is in no way fair to compare PyPy, a compiler that actually implements about 95\% of Python and is meant to be a drop-in replacement for CPython, to Shed Skin, which only works for specially tailored Python programs.</p><p>Also, the funding of PyPy wasn't cut off as you put it. The EU hands out money for research projects with a deadline (usually 2-5 years), not to deliver a marketable product.</p><p>Don't forget that, as opposed to CPython, PyPy is primarily a research project meant to explore new compiler and VM technology. This means that most of the developers work on their own extensions, rather than the stability of the core compiler.</p><p>That is not to say that your comments are completely unwarranted. Perhaps their development process is not particularly suited to the development of a compiler/interpreter.</p><p>Oh and by the way, having built an incomplete Python interpreter myself, I have deep respect for both the people of PyPy and the developer of Shed Skin.</p></htmltext>
<tokenext>It is in no way fair to compare PyPy , a compiler that actually implements about 95 \ % of Python and is meant to be a drop-in replacement for CPython , to Shed Skin , which only works for specially tailored Python programs.Also , the funding of PyPy was n't cut off as you put it .
The EU hands out money for research projects with a deadline ( usually 2-5 years ) , not to deliver a marketable product.Do n't forget that , as opposed to CPython , PyPy is primarily a research project meant to explore new compiler and VM technology .
This means that most of the developers work on their own extensions , rather than the stability of the core compiler.That is not to say that your comments are completely unwarranted .
Perhaps their development process is not particularly suited to the development of a compiler/interpreter.Oh and by the way , having built an incomplete Python interpreter myself , I have deep respect for both the people of PyPy and the developer of Shed Skin .</tokentext>
<sentencetext>It is in no way fair to compare PyPy, a compiler that actually implements about 95\% of Python and is meant to be a drop-in replacement for CPython, to Shed Skin, which only works for specially tailored Python programs.Also, the funding of PyPy wasn't cut off as you put it.
The EU hands out money for research projects with a deadline (usually 2-5 years), not to deliver a marketable product.Don't forget that, as opposed to CPython, PyPy is primarily a research project meant to explore new compiler and VM technology.
This means that most of the developers work on their own extensions, rather than the stability of the core compiler.That is not to say that your comments are completely unwarranted.
Perhaps their development process is not particularly suited to the development of a compiler/interpreter.Oh and by the way, having built an incomplete Python interpreter myself, I have deep respect for both the people of PyPy and the developer of Shed Skin.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116120</id>
	<title>Re:Methodology fads</title>
	<author>teh\_commodore</author>
	<datestamp>1258390560000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>Most of the developers I know (myself included) should just be placed in a box with a spec sheet and left to code.  All of this process mess is for the management and the "architects."</htmltext>
<tokenext>Most of the developers I know ( myself included ) should just be placed in a box with a spec sheet and left to code .
All of this process mess is for the management and the " architects .
"</tokentext>
<sentencetext>Most of the developers I know (myself included) should just be placed in a box with a spec sheet and left to code.
All of this process mess is for the management and the "architects.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118038</id>
	<title>Re:From one end to the other</title>
	<author>Wiseazz</author>
	<datestamp>1258397700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The problem with right-designing (and I do like the designation, btw) is that having multiple methodologies can create confusion.  Consider the corporate IT shop.  Hundreds of IT folk of various skill sets working in an organization with strict auditing and quality controls.  Repeatable, predicatable processes work best in this environment... pick one and stick with it as best as you can so everyone's on the same page.  It's a trade-off to be sure, but in some environments you have to learn to work within such limitations for the greater good.</p><p>We are currently using Agile (Scrum) and Waterfall because we're in transition (to mostly Agile.)  Agile is new to me still, but I cannot deny how the added transparency and shorter dev cycles have begun to streamline our development.  Life will be better still when Agile is in full swing here and all involved have been properly introduced to the concept.</p></htmltext>
<tokenext>The problem with right-designing ( and I do like the designation , btw ) is that having multiple methodologies can create confusion .
Consider the corporate IT shop .
Hundreds of IT folk of various skill sets working in an organization with strict auditing and quality controls .
Repeatable , predicatable processes work best in this environment... pick one and stick with it as best as you can so everyone 's on the same page .
It 's a trade-off to be sure , but in some environments you have to learn to work within such limitations for the greater good.We are currently using Agile ( Scrum ) and Waterfall because we 're in transition ( to mostly Agile .
) Agile is new to me still , but I can not deny how the added transparency and shorter dev cycles have begun to streamline our development .
Life will be better still when Agile is in full swing here and all involved have been properly introduced to the concept .</tokentext>
<sentencetext>The problem with right-designing (and I do like the designation, btw) is that having multiple methodologies can create confusion.
Consider the corporate IT shop.
Hundreds of IT folk of various skill sets working in an organization with strict auditing and quality controls.
Repeatable, predicatable processes work best in this environment... pick one and stick with it as best as you can so everyone's on the same page.
It's a trade-off to be sure, but in some environments you have to learn to work within such limitations for the greater good.We are currently using Agile (Scrum) and Waterfall because we're in transition (to mostly Agile.
)  Agile is new to me still, but I cannot deny how the added transparency and shorter dev cycles have begun to streamline our development.
Life will be better still when Agile is in full swing here and all involved have been properly introduced to the concept.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116110</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117848</id>
	<title>Re:Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258397100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Architects are also developers. This agile process is largely concerned with how to get you that spec sheet in the first place.</p></htmltext>
<tokenext>Architects are also developers .
This agile process is largely concerned with how to get you that spec sheet in the first place .</tokentext>
<sentencetext>Architects are also developers.
This agile process is largely concerned with how to get you that spec sheet in the first place.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116120</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122338</id>
	<title>Re:Methodology fads</title>
	<author>Wizdumb</author>
	<datestamp>1258368900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Welcome to IT darwinism</htmltext>
<tokenext>Welcome to IT darwinism</tokentext>
<sentencetext>Welcome to IT darwinism</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30128034</id>
	<title>Re:Agile development in engineering?</title>
	<author>Anonymous</author>
	<datestamp>1258467960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>first off, why I feel qualified to comment: I've been consulting on software development for 12 years and specializing in 'Agile' for the last 8. I have helped many places adopt Agile, including many with large legacy code bases.</p><p>&gt;Our company is trying to switch to Agile methods and have bought some software.</p><p>Uh oh. 'Buying some software' isn't going to help you 'Go Agile'. It is an approach, a mind set and a discipline. Get software if it is useful, not because you want to be 'Agile'</p><p>&gt;Hoping to get training scheduled soon.</p><p>better, but trying to adopt agile methods after a bit of training is like trying to learn karate from a book. You are going to end up doing something that look vaguely like karate, and then you are going to get your ass kicked. Get people with real experience in a) running agile projects and b) helping organizations adopt agile methods to come and help you. Get them to work with you, side by side, for 6 months.</p><p>&gt;There are just a couple who can even touch isoparametric element stiffness matrix code, to name just one example. I still dont know how agile is going to change the way those two guys work.</p><p>well first off, they are going to have to help other people learn how to do it. ( And frankly, in my experience, they are going to find that they can't get away with making things out to be more complex than they really are or need to be any more )</p><p>&gt;But at some point for some kind of code development, Agile may not be the best way to do the code.</p><p>yep that may very well be true, but I haven't found it yet.</p></htmltext>
<tokenext>first off , why I feel qualified to comment : I 've been consulting on software development for 12 years and specializing in 'Agile ' for the last 8 .
I have helped many places adopt Agile , including many with large legacy code bases. &gt; Our company is trying to switch to Agile methods and have bought some software.Uh oh .
'Buying some software ' is n't going to help you 'Go Agile' .
It is an approach , a mind set and a discipline .
Get software if it is useful , not because you want to be 'Agile ' &gt; Hoping to get training scheduled soon.better , but trying to adopt agile methods after a bit of training is like trying to learn karate from a book .
You are going to end up doing something that look vaguely like karate , and then you are going to get your ass kicked .
Get people with real experience in a ) running agile projects and b ) helping organizations adopt agile methods to come and help you .
Get them to work with you , side by side , for 6 months. &gt; There are just a couple who can even touch isoparametric element stiffness matrix code , to name just one example .
I still dont know how agile is going to change the way those two guys work.well first off , they are going to have to help other people learn how to do it .
( And frankly , in my experience , they are going to find that they ca n't get away with making things out to be more complex than they really are or need to be any more ) &gt; But at some point for some kind of code development , Agile may not be the best way to do the code.yep that may very well be true , but I have n't found it yet .</tokentext>
<sentencetext>first off, why I feel qualified to comment: I've been consulting on software development for 12 years and specializing in 'Agile' for the last 8.
I have helped many places adopt Agile, including many with large legacy code bases.&gt;Our company is trying to switch to Agile methods and have bought some software.Uh oh.
'Buying some software' isn't going to help you 'Go Agile'.
It is an approach, a mind set and a discipline.
Get software if it is useful, not because you want to be 'Agile'&gt;Hoping to get training scheduled soon.better, but trying to adopt agile methods after a bit of training is like trying to learn karate from a book.
You are going to end up doing something that look vaguely like karate, and then you are going to get your ass kicked.
Get people with real experience in a) running agile projects and b) helping organizations adopt agile methods to come and help you.
Get them to work with you, side by side, for 6 months.&gt;There are just a couple who can even touch isoparametric element stiffness matrix code, to name just one example.
I still dont know how agile is going to change the way those two guys work.well first off, they are going to have to help other people learn how to do it.
( And frankly, in my experience, they are going to find that they can't get away with making things out to be more complex than they really are or need to be any more )&gt;But at some point for some kind of code development, Agile may not be the best way to do the code.yep that may very well be true, but I haven't found it yet.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116146</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30129306</id>
	<title>Re:</title>
	<author>clint999</author>
	<datestamp>1258475400000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p><div class="quote"><p>That would make you a programmer.  A software developer   is often involved in more than just programming.</p></div></div>
	</htmltext>
<tokenext>That would make you a programmer .
A software developer is often involved in more than just programming .</tokentext>
<sentencetext>That would make you a programmer.
A software developer   is often involved in more than just programming.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116110</id>
	<title>From one end to the other</title>
	<author>Anonymous</author>
	<datestamp>1258390560000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>So we've gone from over-designing systems to under-designing systems.</p><p>How about right-designing a system based on the complexity of the scope and the key personnel involved?</p><p>Is that crazy?</p></htmltext>
<tokenext>So we 've gone from over-designing systems to under-designing systems.How about right-designing a system based on the complexity of the scope and the key personnel involved ? Is that crazy ?</tokentext>
<sentencetext>So we've gone from over-designing systems to under-designing systems.How about right-designing a system based on the complexity of the scope and the key personnel involved?Is that crazy?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30128536</id>
	<title>Re:PyPy - crashing and burning with "agile".</title>
	<author>Anonymous</author>
	<datestamp>1258471680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I was the project manager of the PyPy EU project, and I think you are spreading a bunch of falsehoods both about the PyPy project and about agile methodologies.</p><p>We did not have our funding pulled. The project was very successfully completed, and the way EU funding works, we would have had to find another call, spend time writing a proposal, negotiating etc. Also the Eu requires matching funding, and the partners did not have the financial means of going for another EU project.</p><p>PyPy is an advanced research project, and we knew from the start that it would not be a quick thing. We had hopes that the financing would be easier and that we would have had the possibility of working full time on the project. This did not come true, because it is very hard to get people to part with their money for truly visionary projects.</p><p>Our results of late show that it is a truly visionary project. We achieve results comparable to ShedSkin without having to limit the Python language, without having to compile before running and with the full set of dynamic features that make Python so powerful.</p><p>So, the speed is there, and we think we can further improve on it. Next step is to find hidden bugs and corner cases.</p><p>Given our adherence to agile methodologies and TDD, this should be fairly painless. Without the agile ideas, PyPy would have been impossible. With them, it has merely been extremely challenging.</p></htmltext>
<tokenext>I was the project manager of the PyPy EU project , and I think you are spreading a bunch of falsehoods both about the PyPy project and about agile methodologies.We did not have our funding pulled .
The project was very successfully completed , and the way EU funding works , we would have had to find another call , spend time writing a proposal , negotiating etc .
Also the Eu requires matching funding , and the partners did not have the financial means of going for another EU project.PyPy is an advanced research project , and we knew from the start that it would not be a quick thing .
We had hopes that the financing would be easier and that we would have had the possibility of working full time on the project .
This did not come true , because it is very hard to get people to part with their money for truly visionary projects.Our results of late show that it is a truly visionary project .
We achieve results comparable to ShedSkin without having to limit the Python language , without having to compile before running and with the full set of dynamic features that make Python so powerful.So , the speed is there , and we think we can further improve on it .
Next step is to find hidden bugs and corner cases.Given our adherence to agile methodologies and TDD , this should be fairly painless .
Without the agile ideas , PyPy would have been impossible .
With them , it has merely been extremely challenging .</tokentext>
<sentencetext>I was the project manager of the PyPy EU project, and I think you are spreading a bunch of falsehoods both about the PyPy project and about agile methodologies.We did not have our funding pulled.
The project was very successfully completed, and the way EU funding works, we would have had to find another call, spend time writing a proposal, negotiating etc.
Also the Eu requires matching funding, and the partners did not have the financial means of going for another EU project.PyPy is an advanced research project, and we knew from the start that it would not be a quick thing.
We had hopes that the financing would be easier and that we would have had the possibility of working full time on the project.
This did not come true, because it is very hard to get people to part with their money for truly visionary projects.Our results of late show that it is a truly visionary project.
We achieve results comparable to ShedSkin without having to limit the Python language, without having to compile before running and with the full set of dynamic features that make Python so powerful.So, the speed is there, and we think we can further improve on it.
Next step is to find hidden bugs and corner cases.Given our adherence to agile methodologies and TDD, this should be fairly painless.
Without the agile ideas, PyPy would have been impossible.
With them, it has merely been extremely challenging.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122062</id>
	<title>Tired of the "magic" straw man</title>
	<author>Gorimek</author>
	<datestamp>1258368000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't think anyone has claimed that Agile is magic or that it can make mediocre programmers create a great project.</p><p>It's just a collection of sane and rational practices to get important work done as well as possible.</p></htmltext>
<tokenext>I do n't think anyone has claimed that Agile is magic or that it can make mediocre programmers create a great project.It 's just a collection of sane and rational practices to get important work done as well as possible .</tokentext>
<sentencetext>I don't think anyone has claimed that Agile is magic or that it can make mediocre programmers create a great project.It's just a collection of sane and rational practices to get important work done as well as possible.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117120</id>
	<title>By any other name....</title>
	<author>EternityRoad</author>
	<datestamp>1258394820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This sounds and kind of looks like another description of Rapid Prototyping or how a artist does a work of art. Do a bit.. Backup... Look at it from all angles. and continue on.

When will these "Thinkers" realize one size doe not fit all. You need to think of "how to do the problem" along with "How to solving the problem"...

This can work for "Project XYZ" thats so open would be a nightmare if you used structured programming. But structure would work very well creating a accounting package..

Been writing &amp; building items since the early 70's for places and clients I have worked. Used about every system in the book so to speak. No one system can do all. That's why we dont have a few tools but unbeleviable amount. The right tool for the right job. Or as a Dr said to me. "The right juce for the right bug." Else not solving the problem.</htmltext>
<tokenext>This sounds and kind of looks like another description of Rapid Prototyping or how a artist does a work of art .
Do a bit.. Backup... Look at it from all angles .
and continue on .
When will these " Thinkers " realize one size doe not fit all .
You need to think of " how to do the problem " along with " How to solving the problem " .. . This can work for " Project XYZ " thats so open would be a nightmare if you used structured programming .
But structure would work very well creating a accounting package. . Been writing &amp; building items since the early 70 's for places and clients I have worked .
Used about every system in the book so to speak .
No one system can do all .
That 's why we dont have a few tools but unbeleviable amount .
The right tool for the right job .
Or as a Dr said to me .
" The right juce for the right bug .
" Else not solving the problem .</tokentext>
<sentencetext>This sounds and kind of looks like another description of Rapid Prototyping or how a artist does a work of art.
Do a bit.. Backup... Look at it from all angles.
and continue on.
When will these "Thinkers" realize one size doe not fit all.
You need to think of "how to do the problem" along with "How to solving the problem"...

This can work for "Project XYZ" thats so open would be a nightmare if you used structured programming.
But structure would work very well creating a accounting package..

Been writing &amp; building items since the early 70's for places and clients I have worked.
Used about every system in the book so to speak.
No one system can do all.
That's why we dont have a few tools but unbeleviable amount.
The right tool for the right job.
Or as a Dr said to me.
"The right juce for the right bug.
" Else not solving the problem.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121262</id>
	<title>Re:Ah, a new entry</title>
	<author>Anonymous</author>
	<datestamp>1258365180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Absolutely not. Writing something in an "agile" way is not the same thing as producing something that is "agile". As an example, a project here at work was a 2 year development effort, for a (in the grand scheme of things) pretty boring CRUD/workflow type app. What would be the reasonable approach to take to build 20 modules, all with pretty similar features? Write (or buy) an engine, pushing as much details as possible as data (configuration files). Adding a new module should this take days; changing modules later should be trivial... agile, so to speak.<br><br>But what the development team did was to go out of their way to not either buy or write an engine. I'm not sure if this was because they are Java types, and doing configuration driven, engine based, coding is just alien to that culture, and/or because the main "agile developer" said loudly things like "the customer didn't' ask for it! I cant build an engine!" and shite like that. They did it in an agile way, 2 week iterations, constantly tweaking the base classes, but producing very boring, very static, functional, but uninspired, very non-agile software.<br><br>Doing things "right" would mean building an engine, and solving the specific problems as an afterthought, and giving users the power to update things... To produce, at the very least, software which can quickly change. Ideally, producing software which can be changed by the users.. Agile guys will never do this, because they would just do the update in a 2 week cycle.<br><br>I'm not quote prepared to extrapolate from this single example that agile development doesn't lead to agile computing, but it isn't a stretch.</div>
	</htmltext>
<tokenext>Absolutely not .
Writing something in an " agile " way is not the same thing as producing something that is " agile " .
As an example , a project here at work was a 2 year development effort , for a ( in the grand scheme of things ) pretty boring CRUD/workflow type app .
What would be the reasonable approach to take to build 20 modules , all with pretty similar features ?
Write ( or buy ) an engine , pushing as much details as possible as data ( configuration files ) .
Adding a new module should this take days ; changing modules later should be trivial... agile , so to speak.But what the development team did was to go out of their way to not either buy or write an engine .
I 'm not sure if this was because they are Java types , and doing configuration driven , engine based , coding is just alien to that culture , and/or because the main " agile developer " said loudly things like " the customer did n't ' ask for it !
I cant build an engine !
" and shite like that .
They did it in an agile way , 2 week iterations , constantly tweaking the base classes , but producing very boring , very static , functional , but uninspired , very non-agile software.Doing things " right " would mean building an engine , and solving the specific problems as an afterthought , and giving users the power to update things... To produce , at the very least , software which can quickly change .
Ideally , producing software which can be changed by the users.. Agile guys will never do this , because they would just do the update in a 2 week cycle.I 'm not quote prepared to extrapolate from this single example that agile development does n't lead to agile computing , but it is n't a stretch .</tokentext>
<sentencetext>Absolutely not.
Writing something in an "agile" way is not the same thing as producing something that is "agile".
As an example, a project here at work was a 2 year development effort, for a (in the grand scheme of things) pretty boring CRUD/workflow type app.
What would be the reasonable approach to take to build 20 modules, all with pretty similar features?
Write (or buy) an engine, pushing as much details as possible as data (configuration files).
Adding a new module should this take days; changing modules later should be trivial... agile, so to speak.But what the development team did was to go out of their way to not either buy or write an engine.
I'm not sure if this was because they are Java types, and doing configuration driven, engine based, coding is just alien to that culture, and/or because the main "agile developer" said loudly things like "the customer didn't' ask for it!
I cant build an engine!
" and shite like that.
They did it in an agile way, 2 week iterations, constantly tweaking the base classes, but producing very boring, very static, functional, but uninspired, very non-agile software.Doing things "right" would mean building an engine, and solving the specific problems as an afterthought, and giving users the power to update things... To produce, at the very least, software which can quickly change.
Ideally, producing software which can be changed by the users.. Agile guys will never do this, because they would just do the update in a 2 week cycle.I'm not quote prepared to extrapolate from this single example that agile development doesn't lead to agile computing, but it isn't a stretch.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116092</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118906</id>
	<title>Re:Oh, THAT strawman</title>
	<author>deoxyribonucleose</author>
	<datestamp>1258400340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Oh, right, yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the "agile" crowd, and wasn't applied that way. Ever heard of iterations? Right. Apparently the agile crowd still never heard that anyone else uses those.</p></div><p>Congratulations on never having been exposed to the literal waterfall. In other news, it's still very much alive and kicking, despite the intent of the original paper to promote the spiral (incremental) model. (Hint to moderators: change parent from +5 insightful to +5 painfully funny.)</p></div>
	</htmltext>
<tokenext>Oh , right , yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the " agile " crowd , and was n't applied that way .
Ever heard of iterations ?
Right. Apparently the agile crowd still never heard that anyone else uses those.Congratulations on never having been exposed to the literal waterfall .
In other news , it 's still very much alive and kicking , despite the intent of the original paper to promote the spiral ( incremental ) model .
( Hint to moderators : change parent from + 5 insightful to + 5 painfully funny .
)</tokentext>
<sentencetext>Oh, right, yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the "agile" crowd, and wasn't applied that way.
Ever heard of iterations?
Right. Apparently the agile crowd still never heard that anyone else uses those.Congratulations on never having been exposed to the literal waterfall.
In other news, it's still very much alive and kicking, despite the intent of the original paper to promote the spiral (incremental) model.
(Hint to moderators: change parent from +5 insightful to +5 painfully funny.
)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121526</id>
	<title>Not quite on the 2nd link...</title>
	<author>bADlOGIN</author>
	<datestamp>1258366320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Steve Yegge's post is (line for line) more of a masturbation session on how cool Google is.<br><br>Although he also makes the point quite well that if you're all rock star coders in a company<br>driven by engineering instead of marketing, you don't need no "steenkin'" methodology.  But<br>then again, that's more of my first complaint now isn't it;)</htmltext>
<tokenext>Steve Yegge 's post is ( line for line ) more of a masturbation session on how cool Google is.Although he also makes the point quite well that if you 're all rock star coders in a companydriven by engineering instead of marketing , you do n't need no " steenkin ' " methodology .
Butthen again , that 's more of my first complaint now is n't it ; )</tokentext>
<sentencetext>Steve Yegge's post is (line for line) more of a masturbation session on how cool Google is.Although he also makes the point quite well that if you're all rock star coders in a companydriven by engineering instead of marketing, you don't need no "steenkin'" methodology.
Butthen again, that's more of my first complaint now isn't it;)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120382</id>
	<title>Re:PyPy - crashing and burning with "agile".</title>
	<author>Anonymous</author>
	<datestamp>1258404780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>From what I remember - and I do remember back when the project was originally announced - PyPy was NEVER supposed to be particularly fast or particularly 'finished'. I mean, think: it's a python implementation *written in python*. The points of the project were supposedly that 1) in the act of writing it, they may find out more about the language, and that new knowledge could be used to fix the reference implementation, and 2) they could use it as a framework for quickly trying out new features for feasibility checks, and then some of that may show up in future versions of python. (And I suppose a potential #3: if you REALLY needed a custom version of python, once pypy got rolling it'd be easier to do your custom version in pypy than by modifying cpython).</p><p>I guess what I'm trying to say is that it's hard to honestly blame their methodology for not producing a finished project in this case, when there never was a concrete end goal to begin with - NO possible methodology would produce a magical faster-than-C version of PyPy.</p></htmltext>
<tokenext>From what I remember - and I do remember back when the project was originally announced - PyPy was NEVER supposed to be particularly fast or particularly 'finished' .
I mean , think : it 's a python implementation * written in python * .
The points of the project were supposedly that 1 ) in the act of writing it , they may find out more about the language , and that new knowledge could be used to fix the reference implementation , and 2 ) they could use it as a framework for quickly trying out new features for feasibility checks , and then some of that may show up in future versions of python .
( And I suppose a potential # 3 : if you REALLY needed a custom version of python , once pypy got rolling it 'd be easier to do your custom version in pypy than by modifying cpython ) .I guess what I 'm trying to say is that it 's hard to honestly blame their methodology for not producing a finished project in this case , when there never was a concrete end goal to begin with - NO possible methodology would produce a magical faster-than-C version of PyPy .</tokentext>
<sentencetext>From what I remember - and I do remember back when the project was originally announced - PyPy was NEVER supposed to be particularly fast or particularly 'finished'.
I mean, think: it's a python implementation *written in python*.
The points of the project were supposedly that 1) in the act of writing it, they may find out more about the language, and that new knowledge could be used to fix the reference implementation, and 2) they could use it as a framework for quickly trying out new features for feasibility checks, and then some of that may show up in future versions of python.
(And I suppose a potential #3: if you REALLY needed a custom version of python, once pypy got rolling it'd be easier to do your custom version in pypy than by modifying cpython).I guess what I'm trying to say is that it's hard to honestly blame their methodology for not producing a finished project in this case, when there never was a concrete end goal to begin with - NO possible methodology would produce a magical faster-than-C version of PyPy.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930</id>
	<title>Oh, THAT strawman</title>
	<author>Anonymous</author>
	<datestamp>1258389720000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Oh, right, yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the "agile" crowd, and wasn't applied that way. Ever heard of iterations? Right. Apparently the agile crowd still never heard that anyone else uses those.</p></htmltext>
<tokenext>Oh , right , yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the " agile " crowd , and was n't applied that way .
Ever heard of iterations ?
Right. Apparently the agile crowd still never heard that anyone else uses those .</tokentext>
<sentencetext>Oh, right, yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the "agile" crowd, and wasn't applied that way.
Ever heard of iterations?
Right. Apparently the agile crowd still never heard that anyone else uses those.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30126708</id>
	<title>Re:From one end to the other</title>
	<author>7 digits</author>
	<datestamp>1258490520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt; How about right-designing a system based on the complexity of the scope and the key personnel involved?</p><p>Get a cool name for that methodology or just shut up.</p></htmltext>
<tokenext>&gt; How about right-designing a system based on the complexity of the scope and the key personnel involved ? Get a cool name for that methodology or just shut up .</tokentext>
<sentencetext>&gt; How about right-designing a system based on the complexity of the scope and the key personnel involved?Get a cool name for that methodology or just shut up.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116110</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122854</id>
	<title>Re:Ad hoc is best</title>
	<author>Anonymous</author>
	<datestamp>1258371060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Excellent!  The problem is that the PHB's don't want to admit that they need to hire good people, as such people are hard to identify and appear expensive.  They'd rather get 4 offshore programmers for $40K each than one strong local person for $100K because it looks so much more cost-effective.  And it gives them a reason to call themselves 'managers'.</p></htmltext>
<tokenext>Excellent !
The problem is that the PHB 's do n't want to admit that they need to hire good people , as such people are hard to identify and appear expensive .
They 'd rather get 4 offshore programmers for $ 40K each than one strong local person for $ 100K because it looks so much more cost-effective .
And it gives them a reason to call themselves 'managers' .</tokentext>
<sentencetext>Excellent!
The problem is that the PHB's don't want to admit that they need to hire good people, as such people are hard to identify and appear expensive.
They'd rather get 4 offshore programmers for $40K each than one strong local person for $100K because it looks so much more cost-effective.
And it gives them a reason to call themselves 'managers'.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116142</id>
	<title>Agile is monthly waterfall.</title>
	<author>Anonymous</author>
	<datestamp>1258390620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Agile Development is a monthly waterfall.  You have short cycles, but if anything, there is even MORE up front planning than you would get for each sprint than a waterfall model and precious little time to change if things need to be retasked.</p><p>The only real advance in methodologies as of late has been to include automated testing.</p></htmltext>
<tokenext>Agile Development is a monthly waterfall .
You have short cycles , but if anything , there is even MORE up front planning than you would get for each sprint than a waterfall model and precious little time to change if things need to be retasked.The only real advance in methodologies as of late has been to include automated testing .</tokentext>
<sentencetext>Agile Development is a monthly waterfall.
You have short cycles, but if anything, there is even MORE up front planning than you would get for each sprint than a waterfall model and precious little time to change if things need to be retasked.The only real advance in methodologies as of late has been to include automated testing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356</id>
	<title>Re:Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258391580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>The only Agile Programming method is to trust your workers, and give them what they need to get it done.</p><p>My company said it was agile, but every process was waterfall with the names changed.  More gates, more reviews, more layoffs and offshoring.</p><p>I could support my application 100\% and have time for other development, but instead I have to train other teams (10 people at least at this point) and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.</p><p>Trust your coders, give them access they need.  Then, when someone inevitably breaks your rules, hold them accountable.  That's the key.  Don't change the rules for everyone so you can answer "What have you done to prevent this from happening again?"  The answer should be "We enforced our current policies, the person has had all access stripped, then terminated, and a reminder sent out."</p><p>I can't do agile development if<nobr> <wbr></nobr>.NET has built-in limitations which require a change request to an offshore server admin support group that doesn't even work my hours.  So I sit idly until the workday ends, wake up the next morning and realize the sa team wants more information.  I just bypass the whole thing and develop locally, but I can't always demo locally.  If I could configure the box myself, I'd be able to document what I did so I can make an implementation guide, but I can't even do that - the dev servers are locked down.  I am expected to document steps that I can't perform myself, nor test.  That adds time to development.</p><p>Trust your coders, work closely with them, and get something working.  Then plan for changes, because there will be design updates as well as requirement updates.</p><p>It all boils down to hiring people who can code either quickly or generically, so that when something changes they can respond - and then allowing them to respond.</p></htmltext>
<tokenext>The only Agile Programming method is to trust your workers , and give them what they need to get it done.My company said it was agile , but every process was waterfall with the names changed .
More gates , more reviews , more layoffs and offshoring.I could support my application 100 \ % and have time for other development , but instead I have to train other teams ( 10 people at least at this point ) and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.Trust your coders , give them access they need .
Then , when someone inevitably breaks your rules , hold them accountable .
That 's the key .
Do n't change the rules for everyone so you can answer " What have you done to prevent this from happening again ?
" The answer should be " We enforced our current policies , the person has had all access stripped , then terminated , and a reminder sent out .
" I ca n't do agile development if .NET has built-in limitations which require a change request to an offshore server admin support group that does n't even work my hours .
So I sit idly until the workday ends , wake up the next morning and realize the sa team wants more information .
I just bypass the whole thing and develop locally , but I ca n't always demo locally .
If I could configure the box myself , I 'd be able to document what I did so I can make an implementation guide , but I ca n't even do that - the dev servers are locked down .
I am expected to document steps that I ca n't perform myself , nor test .
That adds time to development.Trust your coders , work closely with them , and get something working .
Then plan for changes , because there will be design updates as well as requirement updates.It all boils down to hiring people who can code either quickly or generically , so that when something changes they can respond - and then allowing them to respond .</tokentext>
<sentencetext>The only Agile Programming method is to trust your workers, and give them what they need to get it done.My company said it was agile, but every process was waterfall with the names changed.
More gates, more reviews, more layoffs and offshoring.I could support my application 100\% and have time for other development, but instead I have to train other teams (10 people at least at this point) and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.Trust your coders, give them access they need.
Then, when someone inevitably breaks your rules, hold them accountable.
That's the key.
Don't change the rules for everyone so you can answer "What have you done to prevent this from happening again?
"  The answer should be "We enforced our current policies, the person has had all access stripped, then terminated, and a reminder sent out.
"I can't do agile development if .NET has built-in limitations which require a change request to an offshore server admin support group that doesn't even work my hours.
So I sit idly until the workday ends, wake up the next morning and realize the sa team wants more information.
I just bypass the whole thing and develop locally, but I can't always demo locally.
If I could configure the box myself, I'd be able to document what I did so I can make an implementation guide, but I can't even do that - the dev servers are locked down.
I am expected to document steps that I can't perform myself, nor test.
That adds time to development.Trust your coders, work closely with them, and get something working.
Then plan for changes, because there will be design updates as well as requirement updates.It all boils down to hiring people who can code either quickly or generically, so that when something changes they can respond - and then allowing them to respond.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124534</id>
	<title>title sure represents the whole agile "movement"</title>
	<author>Anonymous</author>
	<datestamp>1258380360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Becoming Agile: In An Imperfect World,"</p><p>Sort of like saying: Agile (i.e. Scrum) is perfect [methodology], and the world is not. Typical attitude of most Scrum evangelists: if your scrum project fails, it's because you didn't "implement" scrum correctly, you screwed up. i.e. Don't blame the game, blame the players.</p><p>I smell an air of elitism in this book. Top of the hype curve? Yep.</p></htmltext>
<tokenext>" Becoming Agile : In An Imperfect World , " Sort of like saying : Agile ( i.e .
Scrum ) is perfect [ methodology ] , and the world is not .
Typical attitude of most Scrum evangelists : if your scrum project fails , it 's because you did n't " implement " scrum correctly , you screwed up .
i.e. Do n't blame the game , blame the players.I smell an air of elitism in this book .
Top of the hype curve ?
Yep .</tokentext>
<sentencetext>"Becoming Agile: In An Imperfect World,"Sort of like saying: Agile (i.e.
Scrum) is perfect [methodology], and the world is not.
Typical attitude of most Scrum evangelists: if your scrum project fails, it's because you didn't "implement" scrum correctly, you screwed up.
i.e. Don't blame the game, blame the players.I smell an air of elitism in this book.
Top of the hype curve?
Yep.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118634</id>
	<title>Stop with the "methodologies" already!</title>
	<author>DrVomact</author>
	<datestamp>1258399500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>While the this methodology and... The Agile methodologies which are described...In describing these development methodologies...non-religious presentation of multiple Agile methodologies...</p></div> </blockquote><p>The word <em> <strong>method</strong> </em> may be defined as "a systematic way of accomplishing a task"; near-synonyms include "procedure" or "technique". The word <em> <strong>methodology</strong></em>  means "a <em>study of methods</em>", or perhaps "a comparison of methods", or "a science of methods".</p><p>This substitution of the word "methodology" for "method" happens so frequently that one could argue this is just one of those shifts in English usage that happen now and then, and it's time to stop obsessing about it. I don't think this is such a case&mdash;I think if a writer uses long, pretentious words in place of simpler, more direct ones, then this should serve as a warning to the reader: stilted diction may serve to obscure a lack of substance.</p><p>
Now, about the word "agile"...as a buzzword it's become quite raddled by excessive use. I'm surprised someone is brave enough to use it in the title of a book.</p></div>
	</htmltext>
<tokenext>While the this methodology and... The Agile methodologies which are described...In describing these development methodologies...non-religious presentation of multiple Agile methodologies... The word method may be defined as " a systematic way of accomplishing a task " ; near-synonyms include " procedure " or " technique " .
The word methodology means " a study of methods " , or perhaps " a comparison of methods " , or " a science of methods " .This substitution of the word " methodology " for " method " happens so frequently that one could argue this is just one of those shifts in English usage that happen now and then , and it 's time to stop obsessing about it .
I do n't think this is such a case    I think if a writer uses long , pretentious words in place of simpler , more direct ones , then this should serve as a warning to the reader : stilted diction may serve to obscure a lack of substance .
Now , about the word " agile " ...as a buzzword it 's become quite raddled by excessive use .
I 'm surprised someone is brave enough to use it in the title of a book .</tokentext>
<sentencetext>While the this methodology and... The Agile methodologies which are described...In describing these development methodologies...non-religious presentation of multiple Agile methodologies... The word  method  may be defined as "a systematic way of accomplishing a task"; near-synonyms include "procedure" or "technique".
The word  methodology  means "a study of methods", or perhaps "a comparison of methods", or "a science of methods".This substitution of the word "methodology" for "method" happens so frequently that one could argue this is just one of those shifts in English usage that happen now and then, and it's time to stop obsessing about it.
I don't think this is such a case—I think if a writer uses long, pretentious words in place of simpler, more direct ones, then this should serve as a warning to the reader: stilted diction may serve to obscure a lack of substance.
Now, about the word "agile"...as a buzzword it's become quite raddled by excessive use.
I'm surprised someone is brave enough to use it in the title of a book.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119818</id>
	<title>Re:Methodology fads</title>
	<author>Darinbob</author>
	<datestamp>1258403040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It does work at the right granularity.  Implementing a straight forward feature that is well understood works best without having to waste time being interrupted by process or creating more documents than actual code or carving deadlines in stone.<br><br>At some point, the actual work needs to be done, real code gets typed, and the results tested.  That's the point when the process needs to back off and let stuff happen.</htmltext>
<tokenext>It does work at the right granularity .
Implementing a straight forward feature that is well understood works best without having to waste time being interrupted by process or creating more documents than actual code or carving deadlines in stone.At some point , the actual work needs to be done , real code gets typed , and the results tested .
That 's the point when the process needs to back off and let stuff happen .</tokentext>
<sentencetext>It does work at the right granularity.
Implementing a straight forward feature that is well understood works best without having to waste time being interrupted by process or creating more documents than actual code or carving deadlines in stone.At some point, the actual work needs to be done, real code gets typed, and the results tested.
That's the point when the process needs to back off and let stuff happen.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117640</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117248</id>
	<title>Not to be pedantic, but...</title>
	<author>heironymous</author>
	<datestamp>1258395300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Royce was actually arguing <i>against</i> waterfall, but a poorly worded caption led to much misunderstanding. Waterfall is almost certainly the most expensive meme in history.</p></htmltext>
<tokenext>Royce was actually arguing against waterfall , but a poorly worded caption led to much misunderstanding .
Waterfall is almost certainly the most expensive meme in history .</tokentext>
<sentencetext>Royce was actually arguing against waterfall, but a poorly worded caption led to much misunderstanding.
Waterfall is almost certainly the most expensive meme in history.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119356</id>
	<title>agile is not 'yawn' you moron.</title>
	<author>unity100</author>
	<datestamp>1258401600000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>0</modscore>
	<htmltext><p>just look at microsoft. just look at how their products become outdated even before getting into the market.</p><p>there are still a lot of people who work in deep vestiges of corporate structure where this kind of old development shit is still taken as a reality of life apparently. you build code like you build a bridge, taking years and years of time and rigid structures built on other rigid components. and you are still getting paid.</p><p>the reality is, the place you are currently at is little different from an island stuck in time. it will change. reality will catch up.</p></htmltext>
<tokenext>just look at microsoft .
just look at how their products become outdated even before getting into the market.there are still a lot of people who work in deep vestiges of corporate structure where this kind of old development shit is still taken as a reality of life apparently .
you build code like you build a bridge , taking years and years of time and rigid structures built on other rigid components .
and you are still getting paid.the reality is , the place you are currently at is little different from an island stuck in time .
it will change .
reality will catch up .</tokentext>
<sentencetext>just look at microsoft.
just look at how their products become outdated even before getting into the market.there are still a lot of people who work in deep vestiges of corporate structure where this kind of old development shit is still taken as a reality of life apparently.
you build code like you build a bridge, taking years and years of time and rigid structures built on other rigid components.
and you are still getting paid.the reality is, the place you are currently at is little different from an island stuck in time.
it will change.
reality will catch up.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124882</id>
	<title>Something devoutly to be wished for</title>
	<author>Snaller</author>
	<datestamp>1258383540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Who doesn't want an agile girlfriend!</p></htmltext>
<tokenext>Who does n't want an agile girlfriend !</tokentext>
<sentencetext>Who doesn't want an agile girlfriend!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116098</id>
	<title>Ad hoc is best</title>
	<author>etymxris</author>
	<datestamp>1258390500000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>The best programmers utilize domain specific knowledge gained through years of experience to perform the project design and development tasks that make sense. Trying to generalize one model to fit all domains is doomed to failure. Mainframe COBOL screens work differently than web screens which work differently than low level screen drivers and so on.</p><p>If you're starting work in a new domain, no methodology is magically going to make things work. New domains of development require plenty of experimentation and failure. How to best build the project is going to depend on what comes out of that experimentation.</p><p>And above all, the most important factor is people. You need smart people. No amount of clever methodology is going to make mediocre programmers create a great project. And for smart people, SDLC usually stands in the way of what they already know works best.</p></htmltext>
<tokenext>The best programmers utilize domain specific knowledge gained through years of experience to perform the project design and development tasks that make sense .
Trying to generalize one model to fit all domains is doomed to failure .
Mainframe COBOL screens work differently than web screens which work differently than low level screen drivers and so on.If you 're starting work in a new domain , no methodology is magically going to make things work .
New domains of development require plenty of experimentation and failure .
How to best build the project is going to depend on what comes out of that experimentation.And above all , the most important factor is people .
You need smart people .
No amount of clever methodology is going to make mediocre programmers create a great project .
And for smart people , SDLC usually stands in the way of what they already know works best .</tokentext>
<sentencetext>The best programmers utilize domain specific knowledge gained through years of experience to perform the project design and development tasks that make sense.
Trying to generalize one model to fit all domains is doomed to failure.
Mainframe COBOL screens work differently than web screens which work differently than low level screen drivers and so on.If you're starting work in a new domain, no methodology is magically going to make things work.
New domains of development require plenty of experimentation and failure.
How to best build the project is going to depend on what comes out of that experimentation.And above all, the most important factor is people.
You need smart people.
No amount of clever methodology is going to make mediocre programmers create a great project.
And for smart people, SDLC usually stands in the way of what they already know works best.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117142</id>
	<title>The users are the problem</title>
	<author>Maximum Prophet</author>
	<datestamp>1258394940000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext>My biggest problem with quick prototypes are the users that expect too much.
<br> <br>
Me:  Here's the prototype.  It's black and white, but the finished product will be in full color.
<br>
Them:  This menu item is supposed to be green.
<br>
Me:  That's because the prototype is in black and white.  We're just trying to get the text and spacing correct
<br>
Them:  That item is supposed to be red...
<br> <br>
Managing user's expectations during the prototype phase can be a full-time job. (:-(</htmltext>
<tokenext>My biggest problem with quick prototypes are the users that expect too much .
Me : Here 's the prototype .
It 's black and white , but the finished product will be in full color .
Them : This menu item is supposed to be green .
Me : That 's because the prototype is in black and white .
We 're just trying to get the text and spacing correct Them : That item is supposed to be red.. . Managing user 's expectations during the prototype phase can be a full-time job .
( : - (</tokentext>
<sentencetext>My biggest problem with quick prototypes are the users that expect too much.
Me:  Here's the prototype.
It's black and white, but the finished product will be in full color.
Them:  This menu item is supposed to be green.
Me:  That's because the prototype is in black and white.
We're just trying to get the text and spacing correct

Them:  That item is supposed to be red...
 
Managing user's expectations during the prototype phase can be a full-time job.
(:-(</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119210</id>
	<title>Methodology is like cooking</title>
	<author>pcraven</author>
	<datestamp>1258401180000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>Methodology books are like recipe book. Good chefs own many of them, and draw on the knowledge and ideas inside.</p><p>But buying and following a cookbook does not make you an expert chef.</p></htmltext>
<tokenext>Methodology books are like recipe book .
Good chefs own many of them , and draw on the knowledge and ideas inside.But buying and following a cookbook does not make you an expert chef .</tokentext>
<sentencetext>Methodology books are like recipe book.
Good chefs own many of them, and draw on the knowledge and ideas inside.But buying and following a cookbook does not make you an expert chef.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124222</id>
	<title>Re:How to turn your skilled employees into cogs</title>
	<author>Anonymous</author>
	<datestamp>1258378080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I really strongly disagree with most of what you say.</p><p>In my (long) experience, the best developers are not introverted little lambs who can't function if their work is on display, and who only exist to scratch their own personal technical itches.  I've met those people and had to work with them, and frankly, I would be more than happy for them to go find somewhere else to work.  They are not even close to the best developers, although they may very technically skilled people.</p><p>Agile provides feedback cycles to developers, managers and stakeholders on a variety of levels.  And in my experience, good managers, developers and stakeholders welcome this feedback, as it means they're building something that people actually want and will get used.</p></htmltext>
<tokenext>I really strongly disagree with most of what you say.In my ( long ) experience , the best developers are not introverted little lambs who ca n't function if their work is on display , and who only exist to scratch their own personal technical itches .
I 've met those people and had to work with them , and frankly , I would be more than happy for them to go find somewhere else to work .
They are not even close to the best developers , although they may very technically skilled people.Agile provides feedback cycles to developers , managers and stakeholders on a variety of levels .
And in my experience , good managers , developers and stakeholders welcome this feedback , as it means they 're building something that people actually want and will get used .</tokentext>
<sentencetext>I really strongly disagree with most of what you say.In my (long) experience, the best developers are not introverted little lambs who can't function if their work is on display, and who only exist to scratch their own personal technical itches.
I've met those people and had to work with them, and frankly, I would be more than happy for them to go find somewhere else to work.
They are not even close to the best developers, although they may very technically skilled people.Agile provides feedback cycles to developers, managers and stakeholders on a variety of levels.
And in my experience, good managers, developers and stakeholders welcome this feedback, as it means they're building something that people actually want and will get used.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116598</id>
	<title>Re:Oh, THAT strawman</title>
	<author>Anonymous</author>
	<datestamp>1258392960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I don't see why people criticize C for poorly supporting object-oriented programming when there have been a number of languages that build on C that have supported it for years.</p></htmltext>
<tokenext>I do n't see why people criticize C for poorly supporting object-oriented programming when there have been a number of languages that build on C that have supported it for years .</tokentext>
<sentencetext>I don't see why people criticize C for poorly supporting object-oriented programming when there have been a number of languages that build on C that have supported it for years.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118772</id>
	<title>Re:How to turn your skilled employees into cogs</title>
	<author>MartinSchou</author>
	<datestamp>1258399920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><blockquote><div><p>. Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity.</p></div></blockquote><p>Very true.</p><p>The biggest surprise I had in my professional life was when I was stuck on a particular problem. Completely stuck. So I tried doing other stuff in the mean time. Then I rand out of stuff to do. Posted on newsgroups and forums, but still no answers.</p><p>So I asked my boss if he had anything else I could do, while waiting. "Go play solitaire, read a book, go for a run. But not too far, and keep your cell on you if we need you."</p><p>He knew that some things cannot be forced. So I got paid to sit on my ass and read books for two days until the answer popped into my head. Sometimes the best way to be productive is to just sit back, relax and do nothing.</p></div>
	</htmltext>
<tokenext>.
Often times , managers walk through a room , and if they see a bunch of people typing away or debating some design issue , then they see that busyness as productivity.Very true.The biggest surprise I had in my professional life was when I was stuck on a particular problem .
Completely stuck .
So I tried doing other stuff in the mean time .
Then I rand out of stuff to do .
Posted on newsgroups and forums , but still no answers.So I asked my boss if he had anything else I could do , while waiting .
" Go play solitaire , read a book , go for a run .
But not too far , and keep your cell on you if we need you .
" He knew that some things can not be forced .
So I got paid to sit on my ass and read books for two days until the answer popped into my head .
Sometimes the best way to be productive is to just sit back , relax and do nothing .</tokentext>
<sentencetext>.
Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity.Very true.The biggest surprise I had in my professional life was when I was stuck on a particular problem.
Completely stuck.
So I tried doing other stuff in the mean time.
Then I rand out of stuff to do.
Posted on newsgroups and forums, but still no answers.So I asked my boss if he had anything else I could do, while waiting.
"Go play solitaire, read a book, go for a run.
But not too far, and keep your cell on you if we need you.
"He knew that some things cannot be forced.
So I got paid to sit on my ass and read books for two days until the answer popped into my head.
Sometimes the best way to be productive is to just sit back, relax and do nothing.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115942</id>
	<title>The first step to becoming agile</title>
	<author>Fear the Clam</author>
	<datestamp>1258389780000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>Put down the Cheetos, lard-ass.</p></htmltext>
<tokenext>Put down the Cheetos , lard-ass .</tokentext>
<sentencetext>Put down the Cheetos, lard-ass.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122788</id>
	<title>No more night-time builds means agile is possible?</title>
	<author>mcalwell</author>
	<datestamp>1258370760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm not too young to remember when a software change meant an overnight build before testing could be done the next day.<br> And then testing involved aspects of system performance which simply don't apply in many environments today - memory leaks, null pointer exceptions, DLL hell, and so on. There was a much stronger case for a more rigorous and pedestrian process, because the costs of change were higher. Being able to change and test code on the fly is something to to be taken advantage of.<br>

That doesn't mean methodology should be thrown out of the window. A solid, lean, clean, transparent, demarcated set of classes to describe the general system and initial problem will give you flexibility to change. Keep your business, data and presentation layers separate. Always maintain stable interfaces. It doesn't have to be dogmatic.</htmltext>
<tokenext>I 'm not too young to remember when a software change meant an overnight build before testing could be done the next day .
And then testing involved aspects of system performance which simply do n't apply in many environments today - memory leaks , null pointer exceptions , DLL hell , and so on .
There was a much stronger case for a more rigorous and pedestrian process , because the costs of change were higher .
Being able to change and test code on the fly is something to to be taken advantage of .
That does n't mean methodology should be thrown out of the window .
A solid , lean , clean , transparent , demarcated set of classes to describe the general system and initial problem will give you flexibility to change .
Keep your business , data and presentation layers separate .
Always maintain stable interfaces .
It does n't have to be dogmatic .</tokentext>
<sentencetext>I'm not too young to remember when a software change meant an overnight build before testing could be done the next day.
And then testing involved aspects of system performance which simply don't apply in many environments today - memory leaks, null pointer exceptions, DLL hell, and so on.
There was a much stronger case for a more rigorous and pedestrian process, because the costs of change were higher.
Being able to change and test code on the fly is something to to be taken advantage of.
That doesn't mean methodology should be thrown out of the window.
A solid, lean, clean, transparent, demarcated set of classes to describe the general system and initial problem will give you flexibility to change.
Keep your business, data and presentation layers separate.
Always maintain stable interfaces.
It doesn't have to be dogmatic.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119400</id>
	<title>Re:Evolutionary Prototyping</title>
	<author>quanticle</author>
	<datestamp>1258401720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>This approach is horrible for things that have to work perfectly the first time (e.g. rockets to Mars), but for web development seems to be a decent approach.</p></div><p>Doesn't NASA use a fair amount of prototyping when they're designing new rocket systems?  I mean, there's nothing like building a small scale version to see a preview of what you've got to deal with when building the full scale system.</p></div>
	</htmltext>
<tokenext>This approach is horrible for things that have to work perfectly the first time ( e.g .
rockets to Mars ) , but for web development seems to be a decent approach.Does n't NASA use a fair amount of prototyping when they 're designing new rocket systems ?
I mean , there 's nothing like building a small scale version to see a preview of what you 've got to deal with when building the full scale system .</tokentext>
<sentencetext>This approach is horrible for things that have to work perfectly the first time (e.g.
rockets to Mars), but for web development seems to be a decent approach.Doesn't NASA use a fair amount of prototyping when they're designing new rocket systems?
I mean, there's nothing like building a small scale version to see a preview of what you've got to deal with when building the full scale system.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116346</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470</id>
	<title>PyPy - crashing and burning with "agile".</title>
	<author>Animats</author>
	<datestamp>1258392240000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>
The attempt to write a Python implementation in Python, <a href="http://codespeak.net/pypy/dist/pypy/doc/" title="codespeak.net">PyPy</a> [codespeak.net], turned into a death march.  The project has been underway since at least 2003 (when they had their first "sprint"), never produced a usable system, and the European Union pulled the plug on funding.  But the project limps on.  There's a released version. It's slower than CPython.  There's supposed to be a "just in time" compiler Real Soon Now.  (This is try #2 at a JIT, not counting the schemes for outputting Java bytecode and Javascript.)  Six years in on a compiler project, and no product.
</p><p>
The PyPy project is very "agile".  They have "sprints".  They have "flexibility".  They have nightly builds.  They have mailing lists and trackers.  They support multiple output back-ends.  They have about 50 contributors.  What they don't have is a usable product.
</p><p>
Meanwhile, one programmer produced <a href="http://shed-skin.blogspot.com/" title="blogspot.com">Shed Skin</a> [blogspot.com], which compiles Python to C++, with a speed gain of 5x to 50x over CPython.
</p><p>
When the problem is dominated by design and architecture, "agile" doesn't help.</p></htmltext>
<tokenext>The attempt to write a Python implementation in Python , PyPy [ codespeak.net ] , turned into a death march .
The project has been underway since at least 2003 ( when they had their first " sprint " ) , never produced a usable system , and the European Union pulled the plug on funding .
But the project limps on .
There 's a released version .
It 's slower than CPython .
There 's supposed to be a " just in time " compiler Real Soon Now .
( This is try # 2 at a JIT , not counting the schemes for outputting Java bytecode and Javascript .
) Six years in on a compiler project , and no product .
The PyPy project is very " agile " .
They have " sprints " .
They have " flexibility " .
They have nightly builds .
They have mailing lists and trackers .
They support multiple output back-ends .
They have about 50 contributors .
What they do n't have is a usable product .
Meanwhile , one programmer produced Shed Skin [ blogspot.com ] , which compiles Python to C + + , with a speed gain of 5x to 50x over CPython .
When the problem is dominated by design and architecture , " agile " does n't help .</tokentext>
<sentencetext>
The attempt to write a Python implementation in Python, PyPy [codespeak.net], turned into a death march.
The project has been underway since at least 2003 (when they had their first "sprint"), never produced a usable system, and the European Union pulled the plug on funding.
But the project limps on.
There's a released version.
It's slower than CPython.
There's supposed to be a "just in time" compiler Real Soon Now.
(This is try #2 at a JIT, not counting the schemes for outputting Java bytecode and Javascript.
)  Six years in on a compiler project, and no product.
The PyPy project is very "agile".
They have "sprints".
They have "flexibility".
They have nightly builds.
They have mailing lists and trackers.
They support multiple output back-ends.
They have about 50 contributors.
What they don't have is a usable product.
Meanwhile, one programmer produced Shed Skin [blogspot.com], which compiles Python to C++, with a speed gain of 5x to 50x over CPython.
When the problem is dominated by design and architecture, "agile" doesn't help.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30127928</id>
	<title>Re:The users are the problem</title>
	<author>Civil\_Disobedient</author>
	<datestamp>1258466880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>Me: Here's the prototype. It's black and white, but the finished product will be in full color.<br>Them: This menu item is supposed to be green.</i></p><p>Jesus Christ this is so painfully true.</p></htmltext>
<tokenext>Me : Here 's the prototype .
It 's black and white , but the finished product will be in full color.Them : This menu item is supposed to be green.Jesus Christ this is so painfully true .</tokentext>
<sentencetext>Me: Here's the prototype.
It's black and white, but the finished product will be in full color.Them: This menu item is supposed to be green.Jesus Christ this is so painfully true.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117142</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115884</id>
	<title>fresh piss</title>
	<author>Anonymous</author>
	<datestamp>1258389540000</datestamp>
	<modclass>None</modclass>
	<modscore>-1</modscore>
	<htmltext><p>frist post</p></htmltext>
<tokenext>frist post</tokentext>
<sentencetext>frist post</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846</id>
	<title>How to turn your skilled employees into cogs</title>
	<author>composer777</author>
	<datestamp>1258393740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>I think the appeal with agile development is that it removes any barriers that programmers might have, such as rigid milestones, etc, and basically allows management to do what they want in terms of setting goals.  It also is appealing to management because the knowledge sharing implies that they can get rid of their most expensive employees after a period of time (once the knowledge has dispersed).  Specialized knowledge is an anathema to management, as it means that you have to pay that person more, and it's critical to the business, it's harder to fire them.</p><p>We have to evaluate agile based on it's real world results, not what the books describe.  In the real-world, agile creates a very high-pressure work environment, where personal space is non-existent, everyone is watching you, and your work is constantly on display.  This pressure can produce productivity gains but I would say that in the long run these gains aren't sustainable.  I think agile is a very poor fit for your average introvert, which, imagine that, describes most programmers very well.  What I believe will happen is that over time the better developers will move to a work place where things aren't quite so agile.</p><p>In the mean time, throwing out such ideas as design first, is going to cost us, big time.  I think that software quality will drop, but it won't be obvious, as "quality" and "productivity" aren't things that are easily measurable.  Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity.  No, I think the drop in productivity will become apparent when non-agile competitors clean their clocks, but then it will be too late.</p></htmltext>
<tokenext>I think the appeal with agile development is that it removes any barriers that programmers might have , such as rigid milestones , etc , and basically allows management to do what they want in terms of setting goals .
It also is appealing to management because the knowledge sharing implies that they can get rid of their most expensive employees after a period of time ( once the knowledge has dispersed ) .
Specialized knowledge is an anathema to management , as it means that you have to pay that person more , and it 's critical to the business , it 's harder to fire them.We have to evaluate agile based on it 's real world results , not what the books describe .
In the real-world , agile creates a very high-pressure work environment , where personal space is non-existent , everyone is watching you , and your work is constantly on display .
This pressure can produce productivity gains but I would say that in the long run these gains are n't sustainable .
I think agile is a very poor fit for your average introvert , which , imagine that , describes most programmers very well .
What I believe will happen is that over time the better developers will move to a work place where things are n't quite so agile.In the mean time , throwing out such ideas as design first , is going to cost us , big time .
I think that software quality will drop , but it wo n't be obvious , as " quality " and " productivity " are n't things that are easily measurable .
Often times , managers walk through a room , and if they see a bunch of people typing away or debating some design issue , then they see that busyness as productivity .
No , I think the drop in productivity will become apparent when non-agile competitors clean their clocks , but then it will be too late .</tokentext>
<sentencetext>I think the appeal with agile development is that it removes any barriers that programmers might have, such as rigid milestones, etc, and basically allows management to do what they want in terms of setting goals.
It also is appealing to management because the knowledge sharing implies that they can get rid of their most expensive employees after a period of time (once the knowledge has dispersed).
Specialized knowledge is an anathema to management, as it means that you have to pay that person more, and it's critical to the business, it's harder to fire them.We have to evaluate agile based on it's real world results, not what the books describe.
In the real-world, agile creates a very high-pressure work environment, where personal space is non-existent, everyone is watching you, and your work is constantly on display.
This pressure can produce productivity gains but I would say that in the long run these gains aren't sustainable.
I think agile is a very poor fit for your average introvert, which, imagine that, describes most programmers very well.
What I believe will happen is that over time the better developers will move to a work place where things aren't quite so agile.In the mean time, throwing out such ideas as design first, is going to cost us, big time.
I think that software quality will drop, but it won't be obvious, as "quality" and "productivity" aren't things that are easily measurable.
Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity.
No, I think the drop in productivity will become apparent when non-agile competitors clean their clocks, but then it will be too late.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115938</id>
	<title>Become Agile By</title>
	<author>Anonymous</author>
	<datestamp>1258389720000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>NOT using <a href="http://www.microsoft.com/" title="microsoft.com" rel="nofollow">MicroCRAP</a> [microsoft.com].</p><p>Yours In Olenegorsk,<br>Kilgore Trout</p></htmltext>
<tokenext>NOT using MicroCRAP [ microsoft.com ] .Yours In Olenegorsk,Kilgore Trout</tokentext>
<sentencetext>NOT using MicroCRAP [microsoft.com].Yours In Olenegorsk,Kilgore Trout</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117280</id>
	<title>Re:Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258395420000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>As a technical writer, I can see producing user documentation in small software projects using Agile is possible, but my experience in large, enterprise projects is that Agile is outright hostile to multi-layered user documentation.</p><p>Providing estimates on how long it will take to write and produce podcasts DURING THIS SPRINT -- for a feature the developers may or may not deliver,<nobr> <wbr></nobr>... meh.</p></htmltext>
<tokenext>As a technical writer , I can see producing user documentation in small software projects using Agile is possible , but my experience in large , enterprise projects is that Agile is outright hostile to multi-layered user documentation.Providing estimates on how long it will take to write and produce podcasts DURING THIS SPRINT -- for a feature the developers may or may not deliver , ... meh .</tokentext>
<sentencetext>As a technical writer, I can see producing user documentation in small software projects using Agile is possible, but my experience in large, enterprise projects is that Agile is outright hostile to multi-layered user documentation.Providing estimates on how long it will take to write and produce podcasts DURING THIS SPRINT -- for a feature the developers may or may not deliver, ... meh.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122642</id>
	<title>Re:How to turn your skilled employees into cogs</title>
	<author>hibiki\_r</author>
	<datestamp>1258370040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>If anything, Agile requires high quality developers to be very successful: Since the design process is diluted, you can't get away with having one or two people that run the show technically and a bunch of drones: Bad developers that can't shape up throw a wrench into the system, and send quality down to the toilet.</p><p>An agile system where the developers are actually talented raises their skill levels as they go along, and it can be very rewarding to everyone involved. Eventually management can just set them loose on a project, knowing not just that the end result will be good, but that most issues with requirements will be dealt with before they become a serious problem.</p><p>If anything, the problems I've had getting Agile implemented is getting management to accept the budget issues that come from leaving behind a model of two very good developers/architects and a bunch of bums paid a pittance.</p></htmltext>
<tokenext>If anything , Agile requires high quality developers to be very successful : Since the design process is diluted , you ca n't get away with having one or two people that run the show technically and a bunch of drones : Bad developers that ca n't shape up throw a wrench into the system , and send quality down to the toilet.An agile system where the developers are actually talented raises their skill levels as they go along , and it can be very rewarding to everyone involved .
Eventually management can just set them loose on a project , knowing not just that the end result will be good , but that most issues with requirements will be dealt with before they become a serious problem.If anything , the problems I 've had getting Agile implemented is getting management to accept the budget issues that come from leaving behind a model of two very good developers/architects and a bunch of bums paid a pittance .</tokentext>
<sentencetext>If anything, Agile requires high quality developers to be very successful: Since the design process is diluted, you can't get away with having one or two people that run the show technically and a bunch of drones: Bad developers that can't shape up throw a wrench into the system, and send quality down to the toilet.An agile system where the developers are actually talented raises their skill levels as they go along, and it can be very rewarding to everyone involved.
Eventually management can just set them loose on a project, knowing not just that the end result will be good, but that most issues with requirements will be dealt with before they become a serious problem.If anything, the problems I've had getting Agile implemented is getting management to accept the budget issues that come from leaving behind a model of two very good developers/architects and a bunch of bums paid a pittance.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120594</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117370</id>
	<title>Re:Methodology fads</title>
	<author>ducomputergeek</author>
	<datestamp>1258395780000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>We're a small company, so we can probably get away with it, but I require my coders to show up twice a week to the office for regular meetings and then be available if something comes up.  All our code is either in SVN or Git repositories depending on the project.  (Our Java team likes SVN, the web development team likes Git.  Usually one isn't dealing with the other).  We just come up with a list of milestones and due dates and then I get out of their way.  Once a new feature is added, we test for bugs, and usually the last week of the month is documentation.</p></htmltext>
<tokenext>We 're a small company , so we can probably get away with it , but I require my coders to show up twice a week to the office for regular meetings and then be available if something comes up .
All our code is either in SVN or Git repositories depending on the project .
( Our Java team likes SVN , the web development team likes Git .
Usually one is n't dealing with the other ) .
We just come up with a list of milestones and due dates and then I get out of their way .
Once a new feature is added , we test for bugs , and usually the last week of the month is documentation .</tokentext>
<sentencetext>We're a small company, so we can probably get away with it, but I require my coders to show up twice a week to the office for regular meetings and then be available if something comes up.
All our code is either in SVN or Git repositories depending on the project.
(Our Java team likes SVN, the web development team likes Git.
Usually one isn't dealing with the other).
We just come up with a list of milestones and due dates and then I get out of their way.
Once a new feature is added, we test for bugs, and usually the last week of the month is documentation.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30126184</id>
	<title>Re:PyPy - crashing and burning with "agile".</title>
	<author>cecom</author>
	<datestamp>1258397520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't think your comparison between PyPy and Shed Skin is valid. Without commenting on the merits of either project, I have to say that an efficient implementation of a convenient subset of a language is vastly easier than an efficient implementation of the whole language. The latter might not even be possible at all.</p><p>Shed Skin is not Python. It is a language that has some syntactic similarity to Python and a few similar libraries. Again, I am not commenting on the merit of the project - just stating facts.</p><p>Case in point for Java, some of GCJ's important static optimizations for Java were actually unusable when used on a real Java project like Eclipse. GCJ does support most of the language, but when used in that mode the code it is significantly slower than a JIT (perhaps surprising many people).</p><p>My personal opinion about PyPy, in case anyone cares, is that it is interesting, but if the intent is to have a practical result it is clearly a mistake.</p></htmltext>
<tokenext>I do n't think your comparison between PyPy and Shed Skin is valid .
Without commenting on the merits of either project , I have to say that an efficient implementation of a convenient subset of a language is vastly easier than an efficient implementation of the whole language .
The latter might not even be possible at all.Shed Skin is not Python .
It is a language that has some syntactic similarity to Python and a few similar libraries .
Again , I am not commenting on the merit of the project - just stating facts.Case in point for Java , some of GCJ 's important static optimizations for Java were actually unusable when used on a real Java project like Eclipse .
GCJ does support most of the language , but when used in that mode the code it is significantly slower than a JIT ( perhaps surprising many people ) .My personal opinion about PyPy , in case anyone cares , is that it is interesting , but if the intent is to have a practical result it is clearly a mistake .</tokentext>
<sentencetext>I don't think your comparison between PyPy and Shed Skin is valid.
Without commenting on the merits of either project, I have to say that an efficient implementation of a convenient subset of a language is vastly easier than an efficient implementation of the whole language.
The latter might not even be possible at all.Shed Skin is not Python.
It is a language that has some syntactic similarity to Python and a few similar libraries.
Again, I am not commenting on the merit of the project - just stating facts.Case in point for Java, some of GCJ's important static optimizations for Java were actually unusable when used on a real Java project like Eclipse.
GCJ does support most of the language, but when used in that mode the code it is significantly slower than a JIT (perhaps surprising many people).My personal opinion about PyPy, in case anyone cares, is that it is interesting, but if the intent is to have a practical result it is clearly a mistake.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116326</id>
	<title>Re:Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258391520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I wonder what the fad of the 2020s will be?</p></div><p>I'm almost certain that the language fad will be functional programming, unless of course something even bigger and sloppier comes along to counteract Moore's Law. The management and process fad? Who cares? Except for a lucky few, we'll all have to nod and smile and suck it up until the next silver bullet comes along.</p></div>
	</htmltext>
<tokenext>I wonder what the fad of the 2020s will be ? I 'm almost certain that the language fad will be functional programming , unless of course something even bigger and sloppier comes along to counteract Moore 's Law .
The management and process fad ?
Who cares ?
Except for a lucky few , we 'll all have to nod and smile and suck it up until the next silver bullet comes along .</tokentext>
<sentencetext>I wonder what the fad of the 2020s will be?I'm almost certain that the language fad will be functional programming, unless of course something even bigger and sloppier comes along to counteract Moore's Law.
The management and process fad?
Who cares?
Except for a lucky few, we'll all have to nod and smile and suck it up until the next silver bullet comes along.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118938</id>
	<title>Re:Methodology fads</title>
	<author>maxwell demon</author>
	<datestamp>1258400460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Whatever it is, it will certainly (again) not replace whatever was in use before, but the waterfall process. Every method always is intended to replace the waterfall process. If the waterfall process survived so many alternate methods, it must be really good!</p></htmltext>
<tokenext>Whatever it is , it will certainly ( again ) not replace whatever was in use before , but the waterfall process .
Every method always is intended to replace the waterfall process .
If the waterfall process survived so many alternate methods , it must be really good !</tokentext>
<sentencetext>Whatever it is, it will certainly (again) not replace whatever was in use before, but the waterfall process.
Every method always is intended to replace the waterfall process.
If the waterfall process survived so many alternate methods, it must be really good!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121142</id>
	<title>Re:Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258364760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"I could support my application 100\% and have time for other development, but instead I have to train other teams (10 people at least at this point) and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me."</p><p>I worked with you.  You are the typical, "oh, yes, I'm really an ununderstood star rounded by morons".  The fact is you don't know what a team is and why you are expected to work by the group.  You are fired on the spot on my book.</p></htmltext>
<tokenext>" I could support my application 100 \ % and have time for other development , but instead I have to train other teams ( 10 people at least at this point ) and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me .
" I worked with you .
You are the typical , " oh , yes , I 'm really an ununderstood star rounded by morons " .
The fact is you do n't know what a team is and why you are expected to work by the group .
You are fired on the spot on my book .</tokentext>
<sentencetext>"I could support my application 100\% and have time for other development, but instead I have to train other teams (10 people at least at this point) and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.
"I worked with you.
You are the typical, "oh, yes, I'm really an ununderstood star rounded by morons".
The fact is you don't know what a team is and why you are expected to work by the group.
You are fired on the spot on my book.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116152</id>
	<title>AGILE is about Mangagement CONTROL</title>
	<author>Anonymous</author>
	<datestamp>1258390680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Not about actually getting stuff done.  Its a new age GANTT chart remake that serves to generate a smokescreen for upper mangement about progress on technical projects. As a developer I can't fully estimate how long Schtuff is going to take to build but I can give you a firm idea of  how long the next 3-6 steps will take. That unfortuneately sends traditional MBA weenies (like me) into apoceleptic fits.</p><p>The Spiral aka Boehm method still kicks the most ass as far I am concerned.</p><p>Sadly Agile and other silver bullet methods provide the means of producing better looking charts and really at some level of idiot manager its all about the slick charts, gradients in the powerpoints and how much ass you kiss. Results matter but if they don't like you they will resent you for doing good and making them look bad.  As a result project managers become chart bitches and become List Management Engineers.</p><p>I'm also a huge fan of hiring fewer smarter people than huge crews of people because of channels of communication issues..</p></htmltext>
<tokenext>Not about actually getting stuff done .
Its a new age GANTT chart remake that serves to generate a smokescreen for upper mangement about progress on technical projects .
As a developer I ca n't fully estimate how long Schtuff is going to take to build but I can give you a firm idea of how long the next 3-6 steps will take .
That unfortuneately sends traditional MBA weenies ( like me ) into apoceleptic fits.The Spiral aka Boehm method still kicks the most ass as far I am concerned.Sadly Agile and other silver bullet methods provide the means of producing better looking charts and really at some level of idiot manager its all about the slick charts , gradients in the powerpoints and how much ass you kiss .
Results matter but if they do n't like you they will resent you for doing good and making them look bad .
As a result project managers become chart bitches and become List Management Engineers.I 'm also a huge fan of hiring fewer smarter people than huge crews of people because of channels of communication issues. .</tokentext>
<sentencetext>Not about actually getting stuff done.
Its a new age GANTT chart remake that serves to generate a smokescreen for upper mangement about progress on technical projects.
As a developer I can't fully estimate how long Schtuff is going to take to build but I can give you a firm idea of  how long the next 3-6 steps will take.
That unfortuneately sends traditional MBA weenies (like me) into apoceleptic fits.The Spiral aka Boehm method still kicks the most ass as far I am concerned.Sadly Agile and other silver bullet methods provide the means of producing better looking charts and really at some level of idiot manager its all about the slick charts, gradients in the powerpoints and how much ass you kiss.
Results matter but if they don't like you they will resent you for doing good and making them look bad.
As a result project managers become chart bitches and become List Management Engineers.I'm also a huge fan of hiring fewer smarter people than huge crews of people because of channels of communication issues..</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30125102</id>
	<title>Mistake in the overview...</title>
	<author>Money for Nothin'</author>
	<datestamp>1258385520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>The Waterfall Model stressed rigid functional and design specification of the program(s) to be constructed in advance of any code development. While the this methodology and other early formal tools for Software Engineering were infinitely preferable to the chaos and ad-hoc programming-without-design practices of early systems,</p></div></blockquote><p>The author of this<nobr> <wbr></nobr>/. post erroneously completed that last sentence.  Appended above should be "it was replaced by a return to those same engineering failures of chaos and ad-hoc programming-without-design practices wrought under the name of Agile".</p><p>Pig, meet lipstick.  In practice, Agile = cowboy coding; I've never seen it done any other way, even though yes, in theory it *shouldn't* be that way...</p></div>
	</htmltext>
<tokenext>The Waterfall Model stressed rigid functional and design specification of the program ( s ) to be constructed in advance of any code development .
While the this methodology and other early formal tools for Software Engineering were infinitely preferable to the chaos and ad-hoc programming-without-design practices of early systems,The author of this / .
post erroneously completed that last sentence .
Appended above should be " it was replaced by a return to those same engineering failures of chaos and ad-hoc programming-without-design practices wrought under the name of Agile " .Pig , meet lipstick .
In practice , Agile = cowboy coding ; I 've never seen it done any other way , even though yes , in theory it * should n't * be that way.. .</tokentext>
<sentencetext>The Waterfall Model stressed rigid functional and design specification of the program(s) to be constructed in advance of any code development.
While the this methodology and other early formal tools for Software Engineering were infinitely preferable to the chaos and ad-hoc programming-without-design practices of early systems,The author of this /.
post erroneously completed that last sentence.
Appended above should be "it was replaced by a return to those same engineering failures of chaos and ad-hoc programming-without-design practices wrought under the name of Agile".Pig, meet lipstick.
In practice, Agile = cowboy coding; I've never seen it done any other way, even though yes, in theory it *shouldn't* be that way...
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124094</id>
	<title>Re:Oh and the second agile dogma is stupid</title>
	<author>Anonymous</author>
	<datestamp>1258377360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It's not that organisations have a problem with comprehensive documentation, which I agree, never exists in a good, usable or maintained form.</p><p>It's that organisations can tie themselves in knots trying to produce said comprehensive documentation before allowing anything to be signed off.</p><p>I guess you've never worked for government...</p></htmltext>
<tokenext>It 's not that organisations have a problem with comprehensive documentation , which I agree , never exists in a good , usable or maintained form.It 's that organisations can tie themselves in knots trying to produce said comprehensive documentation before allowing anything to be signed off.I guess you 've never worked for government.. .</tokentext>
<sentencetext>It's not that organisations have a problem with comprehensive documentation, which I agree, never exists in a good, usable or maintained form.It's that organisations can tie themselves in knots trying to produce said comprehensive documentation before allowing anything to be signed off.I guess you've never worked for government...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116522</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117640</id>
	<title>Re:Methodology fads</title>
	<author>pnewhook</author>
	<datestamp>1258396500000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>That is a "throw it over the wall" approach which time and countless failed programs have shown *DOES NOT WORK*.</p></htmltext>
<tokenext>That is a " throw it over the wall " approach which time and countless failed programs have shown * DOES NOT WORK * .</tokentext>
<sentencetext>That is a "throw it over the wall" approach which time and countless failed programs have shown *DOES NOT WORK*.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116120</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118168</id>
	<title>Huge  Problems</title>
	<author>bodland</author>
	<datestamp>1258398060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>When companies move to agile style of programming (I call it Git'er done) they immediately see benefit with the speedy deployment of apps and processes. Roll the camera forward three to five years the failure to include data cleanup, loopback and redesign methods for "shortcuts and workarounds" becomes crippling. Apps that are implemented result of "git'r done agility" result in a cross platform spider-web of dependencies that is unstable and needlessly tied to one another. The entire business becomes trapped up in a giant ball of code that is unraveling in multiple places.
<br>
<br>
In the real world there is no discipline in undisciplined programming methods and deployment.</htmltext>
<tokenext>When companies move to agile style of programming ( I call it Git'er done ) they immediately see benefit with the speedy deployment of apps and processes .
Roll the camera forward three to five years the failure to include data cleanup , loopback and redesign methods for " shortcuts and workarounds " becomes crippling .
Apps that are implemented result of " git'r done agility " result in a cross platform spider-web of dependencies that is unstable and needlessly tied to one another .
The entire business becomes trapped up in a giant ball of code that is unraveling in multiple places .
In the real world there is no discipline in undisciplined programming methods and deployment .</tokentext>
<sentencetext>When companies move to agile style of programming (I call it Git'er done) they immediately see benefit with the speedy deployment of apps and processes.
Roll the camera forward three to five years the failure to include data cleanup, loopback and redesign methods for "shortcuts and workarounds" becomes crippling.
Apps that are implemented result of "git'r done agility" result in a cross platform spider-web of dependencies that is unstable and needlessly tied to one another.
The entire business becomes trapped up in a giant ball of code that is unraveling in multiple places.
In the real world there is no discipline in undisciplined programming methods and deployment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30147018</id>
	<title>Re:The users are the problem</title>
	<author>alexo</author>
	<datestamp>1257104940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>My biggest problem with quick prototypes are the users that expect too much.</p></div> </blockquote><p>That is why I don't call them "prototypes" anymore.  "Proof of concept" usually works better.</p></div>
	</htmltext>
<tokenext>My biggest problem with quick prototypes are the users that expect too much .
That is why I do n't call them " prototypes " anymore .
" Proof of concept " usually works better .</tokentext>
<sentencetext>My biggest problem with quick prototypes are the users that expect too much.
That is why I don't call them "prototypes" anymore.
"Proof of concept" usually works better.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117142</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</id>
	<title>Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258389540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Every decade or generation management and process fads change.  All of them have their faults and all of them have their benefits, and none are ideal for all situations.</p><p>I wonder what the fad of the 2020s will be?</p></htmltext>
<tokenext>Every decade or generation management and process fads change .
All of them have their faults and all of them have their benefits , and none are ideal for all situations.I wonder what the fad of the 2020s will be ?</tokentext>
<sentencetext>Every decade or generation management and process fads change.
All of them have their faults and all of them have their benefits, and none are ideal for all situations.I wonder what the fad of the 2020s will be?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120594</id>
	<title>Re:How to turn your skilled employees into cogs</title>
	<author>DeadlyBattleRobot</author>
	<datestamp>1258362360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Agile's appeal to the corporate world is understandable. Turn an anarchic, creative, random process into a measurable machine operation. Developers now become robots in the clone army. And there is buy in at many levels. Now imagine your group's most obnoxious administrative assistant becoming your scrum supervisor. It's a way for the non technical to make themselves relevant.</p></htmltext>
<tokenext>Agile 's appeal to the corporate world is understandable .
Turn an anarchic , creative , random process into a measurable machine operation .
Developers now become robots in the clone army .
And there is buy in at many levels .
Now imagine your group 's most obnoxious administrative assistant becoming your scrum supervisor .
It 's a way for the non technical to make themselves relevant .</tokentext>
<sentencetext>Agile's appeal to the corporate world is understandable.
Turn an anarchic, creative, random process into a measurable machine operation.
Developers now become robots in the clone army.
And there is buy in at many levels.
Now imagine your group's most obnoxious administrative assistant becoming your scrum supervisor.
It's a way for the non technical to make themselves relevant.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117332</id>
	<title>Rational</title>
	<author>cbreaker</author>
	<datestamp>1258395660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>There's plenty of different methodologies to writing software.   IBM's Rational system combines project management, a feature request system and a code management system into an iterative development structure that I found to be very robust and fun to work with.<br><br>The idea is to start writing code now.   Write the code, make sure your concepts work - and before it's been written into a budget and had time allocated to it.   With each iteration of the development process, you can bring together more code and more features until you reach a release state.<br><br>Some things are better done the Old Way (limited scope project, etc) but for more major development cycles there are better ways.</htmltext>
<tokenext>There 's plenty of different methodologies to writing software .
IBM 's Rational system combines project management , a feature request system and a code management system into an iterative development structure that I found to be very robust and fun to work with.The idea is to start writing code now .
Write the code , make sure your concepts work - and before it 's been written into a budget and had time allocated to it .
With each iteration of the development process , you can bring together more code and more features until you reach a release state.Some things are better done the Old Way ( limited scope project , etc ) but for more major development cycles there are better ways .</tokentext>
<sentencetext>There's plenty of different methodologies to writing software.
IBM's Rational system combines project management, a feature request system and a code management system into an iterative development structure that I found to be very robust and fun to work with.The idea is to start writing code now.
Write the code, make sure your concepts work - and before it's been written into a budget and had time allocated to it.
With each iteration of the development process, you can bring together more code and more features until you reach a release state.Some things are better done the Old Way (limited scope project, etc) but for more major development cycles there are better ways.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116394</id>
	<title>Ah well...</title>
	<author>Anonymous</author>
	<datestamp>1258391820000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>When you use the Waterfall Model there's bound to be some splashback...</htmltext>
<tokenext>When you use the Waterfall Model there 's bound to be some splashback.. .</tokentext>
<sentencetext>When you use the Waterfall Model there's bound to be some splashback...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119688</id>
	<title>Methodology Labels</title>
	<author>Anonymous</author>
	<datestamp>1258402680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Does anyone else think the mere act of labeling these things causes more than its fair share of problems?</p><p>Regardless of the methodology you use, I can't imagine there's a single person that hasn't deviated from that methodology when circumstances dictated.  As far as I can tell, the sole purpose for giving these things names is so that we can sell the idea to the non-technical decision makers who are still trying to turn developers into interchangeable parts.</p></htmltext>
<tokenext>Does anyone else think the mere act of labeling these things causes more than its fair share of problems ? Regardless of the methodology you use , I ca n't imagine there 's a single person that has n't deviated from that methodology when circumstances dictated .
As far as I can tell , the sole purpose for giving these things names is so that we can sell the idea to the non-technical decision makers who are still trying to turn developers into interchangeable parts .</tokentext>
<sentencetext>Does anyone else think the mere act of labeling these things causes more than its fair share of problems?Regardless of the methodology you use, I can't imagine there's a single person that hasn't deviated from that methodology when circumstances dictated.
As far as I can tell, the sole purpose for giving these things names is so that we can sell the idea to the non-technical decision makers who are still trying to turn developers into interchangeable parts.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124436</id>
	<title>Re:Here are a few criticisms...</title>
	<author>Anonymous</author>
	<datestamp>1258379640000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext>Steve-yegge's blog is interesting on how Google worked back in 2006, but it's 2009 and life is pretty different in most parts of Google.
<br>
<br>
Also for a guy at Google, it's a great perspective on how to do Google-like apps, but do you think Google could build a flawless flight control, power plant control or embedded system?
<br>
<br>
Nope, especially with the process he calls "good agile". That's why they hired the ex-danger guys to develop Android for instance and now applying Agile likely. Agile excels when you're framework is already written, otherwise <i>it's a crap shoot</i> as the lower level code (embedded, OS, driver, etc..) you go.</htmltext>
<tokenext>Steve-yegge 's blog is interesting on how Google worked back in 2006 , but it 's 2009 and life is pretty different in most parts of Google .
Also for a guy at Google , it 's a great perspective on how to do Google-like apps , but do you think Google could build a flawless flight control , power plant control or embedded system ?
Nope , especially with the process he calls " good agile " .
That 's why they hired the ex-danger guys to develop Android for instance and now applying Agile likely .
Agile excels when you 're framework is already written , otherwise it 's a crap shoot as the lower level code ( embedded , OS , driver , etc.. ) you go .</tokentext>
<sentencetext>Steve-yegge's blog is interesting on how Google worked back in 2006, but it's 2009 and life is pretty different in most parts of Google.
Also for a guy at Google, it's a great perspective on how to do Google-like apps, but do you think Google could build a flawless flight control, power plant control or embedded system?
Nope, especially with the process he calls "good agile".
That's why they hired the ex-danger guys to develop Android for instance and now applying Agile likely.
Agile excels when you're framework is already written, otherwise it's a crap shoot as the lower level code (embedded, OS, driver, etc..) you go.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115836</id>
	<title>PDF of old paper was Slashdotted!</title>
	<author>Anonymous</author>
	<datestamp>1258389300000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Here's a little snippet. My secretary had it pulled up on his screen.</p><blockquote><div><p>MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS<br>Dr. Winston W. Rovce</p><p>INTRODUCTION<br>l am going to describe my personal views about managing large software developments. I have had<br>various assignments during the past nit,.: years, mostly concerned with the development of software packages<br>for spacecraft mission planning, commanding and post-flight analysis. In these assignments I have experienced<br>different degrees of success with respect to arriving at an operational state, on-time, and within costs. I have<br>become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.</p><p>COMPUTER PROGRAM DEVELOPMENT FUNCTIONS<br>There are two essential steps common to all computer program developments, regardless of size or<br>complexity. There is first an analysis step, followed second by a coding step as depicted in Figure 1. This sort<br>of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the<br>final product is to be operated by those who built it - as is typically done with computer programs for internal<br>use. It is also the kind of development effort for which most customers are happy to pay, since both steps<br>involve genuinely creative work which directly contributes to the usefulness of the final product. An<br>implementation plan to manufacture larger software systems, and keyed only to these steps, however, is doomed<br>
&nbsp; to failure. Many additional development steps are required, none contribute as directly to the final product as<br>analysis and coding, and all drive up the development costs. Customer personnel typically would rather not pay<br>for them, and development personnel would rather not implement them. The prime function of management<br>is to sell these concepts to both groups and then enforce compliance on the part of development personnel.</p></div></blockquote><p>I read through several pages and glossed through the rest. Good ideas consider how far this goes back. Definitely worth the read IMO.</p></div>
	</htmltext>
<tokenext>Here 's a little snippet .
My secretary had it pulled up on his screen.MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMSDr .
Winston W. RovceINTRODUCTIONl am going to describe my personal views about managing large software developments .
I have hadvarious assignments during the past nit, .
: years , mostly concerned with the development of software packagesfor spacecraft mission planning , commanding and post-flight analysis .
In these assignments I have experienceddifferent degrees of success with respect to arriving at an operational state , on-time , and within costs .
I havebecome prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.COMPUTER PROGRAM DEVELOPMENT FUNCTIONSThere are two essential steps common to all computer program developments , regardless of size orcomplexity .
There is first an analysis step , followed second by a coding step as depicted in Figure 1 .
This sortof very simple implementation concept is in fact all that is required if the effort is sufficiently small and if thefinal product is to be operated by those who built it - as is typically done with computer programs for internaluse .
It is also the kind of development effort for which most customers are happy to pay , since both stepsinvolve genuinely creative work which directly contributes to the usefulness of the final product .
Animplementation plan to manufacture larger software systems , and keyed only to these steps , however , is doomed   to failure .
Many additional development steps are required , none contribute as directly to the final product asanalysis and coding , and all drive up the development costs .
Customer personnel typically would rather not payfor them , and development personnel would rather not implement them .
The prime function of managementis to sell these concepts to both groups and then enforce compliance on the part of development personnel.I read through several pages and glossed through the rest .
Good ideas consider how far this goes back .
Definitely worth the read IMO .</tokentext>
<sentencetext>Here's a little snippet.
My secretary had it pulled up on his screen.MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMSDr.
Winston W. RovceINTRODUCTIONl am going to describe my personal views about managing large software developments.
I have hadvarious assignments during the past nit,.
: years, mostly concerned with the development of software packagesfor spacecraft mission planning, commanding and post-flight analysis.
In these assignments I have experienceddifferent degrees of success with respect to arriving at an operational state, on-time, and within costs.
I havebecome prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.COMPUTER PROGRAM DEVELOPMENT FUNCTIONSThere are two essential steps common to all computer program developments, regardless of size orcomplexity.
There is first an analysis step, followed second by a coding step as depicted in Figure 1.
This sortof very simple implementation concept is in fact all that is required if the effort is sufficiently small and if thefinal product is to be operated by those who built it - as is typically done with computer programs for internaluse.
It is also the kind of development effort for which most customers are happy to pay, since both stepsinvolve genuinely creative work which directly contributes to the usefulness of the final product.
Animplementation plan to manufacture larger software systems, and keyed only to these steps, however, is doomed
  to failure.
Many additional development steps are required, none contribute as directly to the final product asanalysis and coding, and all drive up the development costs.
Customer personnel typically would rather not payfor them, and development personnel would rather not implement them.
The prime function of managementis to sell these concepts to both groups and then enforce compliance on the part of development personnel.I read through several pages and glossed through the rest.
Good ideas consider how far this goes back.
Definitely worth the read IMO.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116324</id>
	<title>Re:Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258391520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>They even seem to come with the weird religious rhetoric, too, promising that if only you embrace <i>$Methodology</i>, your life will change. Well, except the ultra-oppressive ones like CMMI: it demands that you accept CMMI or be destroyed.</p><p>It seems to be a fact of life that these things are going to float around, so I guess what makes sense is figuring out which ones are relatively better or worse, and what ideas from them are relatively useful or not. As (excellent tech blogger) YosefK <a href="http://www.yosefk.com/blog/extreme-programming-explained.html" title="yosefk.com">put it</a> [yosefk.com] in a review of an Extreme Programming book:</p><blockquote><div><p>This quote is right from the book cover. "Extreme Programming Explained. EMBRACE CHANGE." Does it freak you out the way it freaks me out? Maybe it's because of the cultural gap created by my Russian origins? Nay, I know plenty of English slogans I can relate to. Say, "Trust a condom". Beats "Embrace change" hands-down. Changes come in two flavors, good and bad. Should I "embrace" both kinds?</p><p>[...]</p><blockquote><div><p>"The key to XP is integrity, acting in harmony with my true values The past five years have been a journey of changing my actual values into those I wanted to hold."</p></div></blockquote><p>"Journey". Talking about being good. Do you like hippies? I like hippies more than nazis. I like XP more than CMM. But IMO the hippie world view and general style is suboptimal.</p></div></blockquote></div>
	</htmltext>
<tokenext>They even seem to come with the weird religious rhetoric , too , promising that if only you embrace $ Methodology , your life will change .
Well , except the ultra-oppressive ones like CMMI : it demands that you accept CMMI or be destroyed.It seems to be a fact of life that these things are going to float around , so I guess what makes sense is figuring out which ones are relatively better or worse , and what ideas from them are relatively useful or not .
As ( excellent tech blogger ) YosefK put it [ yosefk.com ] in a review of an Extreme Programming book : This quote is right from the book cover .
" Extreme Programming Explained .
EMBRACE CHANGE .
" Does it freak you out the way it freaks me out ?
Maybe it 's because of the cultural gap created by my Russian origins ?
Nay , I know plenty of English slogans I can relate to .
Say , " Trust a condom " .
Beats " Embrace change " hands-down .
Changes come in two flavors , good and bad .
Should I " embrace " both kinds ? [ .. .
] " The key to XP is integrity , acting in harmony with my true values The past five years have been a journey of changing my actual values into those I wanted to hold. " " Journey " .
Talking about being good .
Do you like hippies ?
I like hippies more than nazis .
I like XP more than CMM .
But IMO the hippie world view and general style is suboptimal .</tokentext>
<sentencetext>They even seem to come with the weird religious rhetoric, too, promising that if only you embrace $Methodology, your life will change.
Well, except the ultra-oppressive ones like CMMI: it demands that you accept CMMI or be destroyed.It seems to be a fact of life that these things are going to float around, so I guess what makes sense is figuring out which ones are relatively better or worse, and what ideas from them are relatively useful or not.
As (excellent tech blogger) YosefK put it [yosefk.com] in a review of an Extreme Programming book:This quote is right from the book cover.
"Extreme Programming Explained.
EMBRACE CHANGE.
" Does it freak you out the way it freaks me out?
Maybe it's because of the cultural gap created by my Russian origins?
Nay, I know plenty of English slogans I can relate to.
Say, "Trust a condom".
Beats "Embrace change" hands-down.
Changes come in two flavors, good and bad.
Should I "embrace" both kinds?[...
]"The key to XP is integrity, acting in harmony with my true values The past five years have been a journey of changing my actual values into those I wanted to hold.""Journey".
Talking about being good.
Do you like hippies?
I like hippies more than nazis.
I like XP more than CMM.
But IMO the hippie world view and general style is suboptimal.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060</id>
	<title>Here are a few criticisms...</title>
	<author>Spy der Mann</author>
	<datestamp>1258390320000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>of agile software development.</p><p><a href="http://www.softwarereality.com/lifecycle/xp/case\_against\_xp.jsp" title="softwarereality.com">http://www.softwarereality.com/lifecycle/xp/case\_against\_xp.jsp</a> [softwarereality.com]</p><p><a href="http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile\_27.html" title="blogspot.com">http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile\_27.html</a> [blogspot.com]</p></htmltext>
<tokenext>of agile software development.http : //www.softwarereality.com/lifecycle/xp/case \ _against \ _xp.jsp [ softwarereality.com ] http : //steve-yegge.blogspot.com/2006/09/good-agile-bad-agile \ _27.html [ blogspot.com ]</tokentext>
<sentencetext>of agile software development.http://www.softwarereality.com/lifecycle/xp/case\_against\_xp.jsp [softwarereality.com]http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile\_27.html [blogspot.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116624</id>
	<title>Agile and embedded systems?</title>
	<author>Anonymous Meoward</author>
	<datestamp>1258393080000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Who here has actually used Agile for embedded systems work? What were your experiences?</p></htmltext>
<tokenext>Who here has actually used Agile for embedded systems work ?
What were your experiences ?</tokentext>
<sentencetext>Who here has actually used Agile for embedded systems work?
What were your experiences?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121374</id>
	<title>Re:Here are a few criticisms...</title>
	<author>Tellarin</author>
	<datestamp>1258365600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The first link starts with a mistake and is from 2003. A lot has changed in "agile development" since then.</p><p>And the second actually praises the way Google does things (quite "agile" if I may say so) while criticizing fads and the methodology-of-the-month.</p><p>I couldn't agree more with Steve about how bad it is with the agile fad and all the courses and whatever people keep selling and hyping about. And I do hate using to world<br>agile to mean so much different stuff.</p><p>But not-so-rigid-development-processes-that-kind-of-code-common-sense-about-development are indeed good in many scenarios. It's just not necessary to turn that into a religion as many people do.</p></htmltext>
<tokenext>The first link starts with a mistake and is from 2003 .
A lot has changed in " agile development " since then.And the second actually praises the way Google does things ( quite " agile " if I may say so ) while criticizing fads and the methodology-of-the-month.I could n't agree more with Steve about how bad it is with the agile fad and all the courses and whatever people keep selling and hyping about .
And I do hate using to worldagile to mean so much different stuff.But not-so-rigid-development-processes-that-kind-of-code-common-sense-about-development are indeed good in many scenarios .
It 's just not necessary to turn that into a religion as many people do .</tokentext>
<sentencetext>The first link starts with a mistake and is from 2003.
A lot has changed in "agile development" since then.And the second actually praises the way Google does things (quite "agile" if I may say so) while criticizing fads and the methodology-of-the-month.I couldn't agree more with Steve about how bad it is with the agile fad and all the courses and whatever people keep selling and hyping about.
And I do hate using to worldagile to mean so much different stuff.But not-so-rigid-development-processes-that-kind-of-code-common-sense-about-development are indeed good in many scenarios.
It's just not necessary to turn that into a religion as many people do.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119168</id>
	<title>Step 1</title>
	<author>Anonymous</author>
	<datestamp>1258401060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The easiest way is to make sure you give yourself high dexterity.  I recommend 16 or higher.</p></htmltext>
<tokenext>The easiest way is to make sure you give yourself high dexterity .
I recommend 16 or higher .</tokentext>
<sentencetext>The easiest way is to make sure you give yourself high dexterity.
I recommend 16 or higher.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116182</id>
	<title>I'm fucking a ballerina</title>
	<author>Anonymous</author>
	<datestamp>1258390860000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>Does that make me agile?</p></htmltext>
<tokenext>Does that make me agile ?</tokentext>
<sentencetext>Does that make me agile?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119458</id>
	<title>I love when developers talk project management</title>
	<author>Anonymous</author>
	<datestamp>1258401960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>First, I'll start out in stating that I am both PMP and CSM certified with plenty of experience as a PM and a BA. I always find it interesting that developers have no qualms sitting back and criticizing PM methodologies or PMs who may try to do something a little different. If it's so common sense or easy, why don't you do it?</p><p>There is no best methodology when it comes to PM, and anyone who says there is, is full of it. A good PM should be able to draw upon their knowledge and experience to find the best fit for the company and culture. Scrum has serious flaws. The project isn't thought through enough, the time line isn't established early and it's extremely easy to loose features/functionality because it wasn't in the story, which was never thought out. Waterfall has flaws too. I can't stand sending out a request for approval to submit a change request updating requirement 4.3.2.5.6.4.3.3 to change the word pare to pair.</p><p>It's all about finding balance and taking the positive aspects of each and incorporating them into each project. What worked for one isn't necessarily going to work for the next, and as soon as people get over the idea of I'm this methodology or this methodology and focus on producing results consistent with expectations in a timely manner, we'll all be better for it.</p></htmltext>
<tokenext>First , I 'll start out in stating that I am both PMP and CSM certified with plenty of experience as a PM and a BA .
I always find it interesting that developers have no qualms sitting back and criticizing PM methodologies or PMs who may try to do something a little different .
If it 's so common sense or easy , why do n't you do it ? There is no best methodology when it comes to PM , and anyone who says there is , is full of it .
A good PM should be able to draw upon their knowledge and experience to find the best fit for the company and culture .
Scrum has serious flaws .
The project is n't thought through enough , the time line is n't established early and it 's extremely easy to loose features/functionality because it was n't in the story , which was never thought out .
Waterfall has flaws too .
I ca n't stand sending out a request for approval to submit a change request updating requirement 4.3.2.5.6.4.3.3 to change the word pare to pair.It 's all about finding balance and taking the positive aspects of each and incorporating them into each project .
What worked for one is n't necessarily going to work for the next , and as soon as people get over the idea of I 'm this methodology or this methodology and focus on producing results consistent with expectations in a timely manner , we 'll all be better for it .</tokentext>
<sentencetext>First, I'll start out in stating that I am both PMP and CSM certified with plenty of experience as a PM and a BA.
I always find it interesting that developers have no qualms sitting back and criticizing PM methodologies or PMs who may try to do something a little different.
If it's so common sense or easy, why don't you do it?There is no best methodology when it comes to PM, and anyone who says there is, is full of it.
A good PM should be able to draw upon their knowledge and experience to find the best fit for the company and culture.
Scrum has serious flaws.
The project isn't thought through enough, the time line isn't established early and it's extremely easy to loose features/functionality because it wasn't in the story, which was never thought out.
Waterfall has flaws too.
I can't stand sending out a request for approval to submit a change request updating requirement 4.3.2.5.6.4.3.3 to change the word pare to pair.It's all about finding balance and taking the positive aspects of each and incorporating them into each project.
What worked for one isn't necessarily going to work for the next, and as soon as people get over the idea of I'm this methodology or this methodology and focus on producing results consistent with expectations in a timely manner, we'll all be better for it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30127240</id>
	<title>Re:Oh and the second agile dogma is stupid</title>
	<author>Le Tmraire</author>
	<datestamp>1258456320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think this has to do with how you read and interpret the agile manifesto. The second dogma says:"Working software over comprehensive documentation." And not <b>vs.</b>  comprehensive documentation. <br> <br>I have been in software projects where after 18 months (!) of development we had nothing to show except for tons of documentation and designs. I have also been in scrum driven projects were we had little but very useful documentation. <br> <br>So, in my book, <b>Agile != no documentation.</b> Agile == make only the documentation that is useful and wanted by the customer.</htmltext>
<tokenext>I think this has to do with how you read and interpret the agile manifesto .
The second dogma says : " Working software over comprehensive documentation .
" And not vs. comprehensive documentation .
I have been in software projects where after 18 months ( !
) of development we had nothing to show except for tons of documentation and designs .
I have also been in scrum driven projects were we had little but very useful documentation .
So , in my book , Agile ! = no documentation .
Agile = = make only the documentation that is useful and wanted by the customer .</tokentext>
<sentencetext>I think this has to do with how you read and interpret the agile manifesto.
The second dogma says:"Working software over comprehensive documentation.
" And not vs.  comprehensive documentation.
I have been in software projects where after 18 months (!
) of development we had nothing to show except for tons of documentation and designs.
I have also been in scrum driven projects were we had little but very useful documentation.
So, in my book, Agile != no documentation.
Agile == make only the documentation that is useful and wanted by the customer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116522</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118594</id>
	<title>Re:Methodology fads</title>
	<author>MartinSchou</author>
	<datestamp>1258399320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.</p></div></blockquote><p>Or find someone who can quickly pick up the work, when you inevitably die horribly in a plane crash on New Years, when the commercial airliner experiences a catastrophic failure and both sets of stabilizers snap off, causing it to crash right into your living room.</p><p>It's terribly precise, I know, but hey - you were being overly paranoid.</p></div>
	</htmltext>
<tokenext>and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.Or find someone who can quickly pick up the work , when you inevitably die horribly in a plane crash on New Years , when the commercial airliner experiences a catastrophic failure and both sets of stabilizers snap off , causing it to crash right into your living room.It 's terribly precise , I know , but hey - you were being overly paranoid .</tokentext>
<sentencetext>and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.Or find someone who can quickly pick up the work, when you inevitably die horribly in a plane crash on New Years, when the commercial airliner experiences a catastrophic failure and both sets of stabilizers snap off, causing it to crash right into your living room.It's terribly precise, I know, but hey - you were being overly paranoid.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30123502</id>
	<title>Agile = Advance</title>
	<author>Jack9</author>
	<datestamp>1258374060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Acronyms and paradigms aside from SCRUM, there is no other project framework that has processes to identify and highlight the interests of all parties involved in development, other than BUG TRACKING.</p><p>Business interests are described, enumerated and ranked then broken down.<br>Technical difficulties are described, broken down, enumerated and ranked.<br>Work is broken down, allocated and individual tasks assigned to and by tiers matching your company's hierarchy.<br>Metrics can be performed and any interest can track what happened and why (if you have decent SCRUM management software).</p><p>Talented developers don't mind (as per all the posts here), weak developers can be pointed out and weak managers are unhappy they need to spell out what they want. More things get done faster. Simply said. SCRUM doesn't address bug tracking, which is the only weakness I have found. Take care of designing how you will deal with bugs during a Sprint. Any other system, is probably usable, but certainly less efficient.</p><p>The identification and organization of addressing the various interests is much better than having (non-?)technical designs drawn up prior to implementation. This is what I have seen come out of Agile (which is just "Lean" repackaged) that can be used at any company, so I call it an advance. Not perfect, just a GOOD THING(tm).</p></htmltext>
<tokenext>Acronyms and paradigms aside from SCRUM , there is no other project framework that has processes to identify and highlight the interests of all parties involved in development , other than BUG TRACKING.Business interests are described , enumerated and ranked then broken down.Technical difficulties are described , broken down , enumerated and ranked.Work is broken down , allocated and individual tasks assigned to and by tiers matching your company 's hierarchy.Metrics can be performed and any interest can track what happened and why ( if you have decent SCRUM management software ) .Talented developers do n't mind ( as per all the posts here ) , weak developers can be pointed out and weak managers are unhappy they need to spell out what they want .
More things get done faster .
Simply said .
SCRUM does n't address bug tracking , which is the only weakness I have found .
Take care of designing how you will deal with bugs during a Sprint .
Any other system , is probably usable , but certainly less efficient.The identification and organization of addressing the various interests is much better than having ( non- ?
) technical designs drawn up prior to implementation .
This is what I have seen come out of Agile ( which is just " Lean " repackaged ) that can be used at any company , so I call it an advance .
Not perfect , just a GOOD THING ( tm ) .</tokentext>
<sentencetext>Acronyms and paradigms aside from SCRUM, there is no other project framework that has processes to identify and highlight the interests of all parties involved in development, other than BUG TRACKING.Business interests are described, enumerated and ranked then broken down.Technical difficulties are described, broken down, enumerated and ranked.Work is broken down, allocated and individual tasks assigned to and by tiers matching your company's hierarchy.Metrics can be performed and any interest can track what happened and why (if you have decent SCRUM management software).Talented developers don't mind (as per all the posts here), weak developers can be pointed out and weak managers are unhappy they need to spell out what they want.
More things get done faster.
Simply said.
SCRUM doesn't address bug tracking, which is the only weakness I have found.
Take care of designing how you will deal with bugs during a Sprint.
Any other system, is probably usable, but certainly less efficient.The identification and organization of addressing the various interests is much better than having (non-?
)technical designs drawn up prior to implementation.
This is what I have seen come out of Agile (which is just "Lean" repackaged) that can be used at any company, so I call it an advance.
Not perfect, just a GOOD THING(tm).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116454</id>
	<title>Yeah, it's great when you do agile</title>
	<author>NotSoHeavyD3</author>
	<datestamp>1258392180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>and everybody is theoretically supposed to be able to do system analysis, coding, and QA. That way nobody is unique and it's much easier for them to lay you off and swap some new cog into the machine. (Ok, so I just got laid off and I was on one of the agile teams. Actually we had a bunch of agile teams and they pretty much dumped most of the people on them and kept people who weren't on them because they had unique skills. I know, I should have seen that one coming.)</htmltext>
<tokenext>and everybody is theoretically supposed to be able to do system analysis , coding , and QA .
That way nobody is unique and it 's much easier for them to lay you off and swap some new cog into the machine .
( Ok , so I just got laid off and I was on one of the agile teams .
Actually we had a bunch of agile teams and they pretty much dumped most of the people on them and kept people who were n't on them because they had unique skills .
I know , I should have seen that one coming .
)</tokentext>
<sentencetext>and everybody is theoretically supposed to be able to do system analysis, coding, and QA.
That way nobody is unique and it's much easier for them to lay you off and swap some new cog into the machine.
(Ok, so I just got laid off and I was on one of the agile teams.
Actually we had a bunch of agile teams and they pretty much dumped most of the people on them and kept people who weren't on them because they had unique skills.
I know, I should have seen that one coming.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120972</id>
	<title>I wish it were a fad. Agile means rewrite</title>
	<author>Anonymous</author>
	<datestamp>1258363980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I hate fads but this new agile nonsense isn't your regular fad. It's much much worse. I've seen "agile" used as an excuse to deliver a substantially changed final spec well into the final stages of development, then wonder why the product, which started off as one thing has been so completely MANGLED to become that other thing, performs poorly and is buggy. It's like starting off with a spec for a bridge then in the months where the bridge is almost complete despite incomplete documentation asking for that bridge to now become an ocean liner.</p><p>Furthermore all of the tools that do work - unit testing, continuous integration, thorough peer review, can all be used with other methodologies without being mangled by the mentality that is agile.</p></htmltext>
<tokenext>I hate fads but this new agile nonsense is n't your regular fad .
It 's much much worse .
I 've seen " agile " used as an excuse to deliver a substantially changed final spec well into the final stages of development , then wonder why the product , which started off as one thing has been so completely MANGLED to become that other thing , performs poorly and is buggy .
It 's like starting off with a spec for a bridge then in the months where the bridge is almost complete despite incomplete documentation asking for that bridge to now become an ocean liner.Furthermore all of the tools that do work - unit testing , continuous integration , thorough peer review , can all be used with other methodologies without being mangled by the mentality that is agile .</tokentext>
<sentencetext>I hate fads but this new agile nonsense isn't your regular fad.
It's much much worse.
I've seen "agile" used as an excuse to deliver a substantially changed final spec well into the final stages of development, then wonder why the product, which started off as one thing has been so completely MANGLED to become that other thing, performs poorly and is buggy.
It's like starting off with a spec for a bridge then in the months where the bridge is almost complete despite incomplete documentation asking for that bridge to now become an ocean liner.Furthermore all of the tools that do work - unit testing, continuous integration, thorough peer review, can all be used with other methodologies without being mangled by the mentality that is agile.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116092</id>
	<title>Ah, a new entry</title>
	<author>HangingChad</author>
	<datestamp>1258390440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>A new entry for you Buzzword Bingo cards.  The big question is whether "Agile Computing" and "Agile Development" should be separate squares or lumped under "Agile"?

</p><p>I vote for a single "Agile" square.</p></htmltext>
<tokenext>A new entry for you Buzzword Bingo cards .
The big question is whether " Agile Computing " and " Agile Development " should be separate squares or lumped under " Agile " ?
I vote for a single " Agile " square .</tokentext>
<sentencetext>A new entry for you Buzzword Bingo cards.
The big question is whether "Agile Computing" and "Agile Development" should be separate squares or lumped under "Agile"?
I vote for a single "Agile" square.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121338</id>
	<title>Re:Ad hoc is best</title>
	<author>recharged95</author>
	<datestamp>1258365480000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you've been in the business for &gt;15yrs.
<br>
<br>
Smart people can still make a project fail miserably. 50/50 they also get in the way of a project (by miscalculating priorities for instance).
<br>
<br>
You don't just need smart people: you need the <i>right</i> people. That's called a team. To the MBA's, that management 101, and is no different for the s/w field. Bring the wrong team, and I guarantee it will fail.</htmltext>
<tokenext>If you 've been in the business for &gt; 15yrs .
Smart people can still make a project fail miserably .
50/50 they also get in the way of a project ( by miscalculating priorities for instance ) .
You do n't just need smart people : you need the right people .
That 's called a team .
To the MBA 's , that management 101 , and is no different for the s/w field .
Bring the wrong team , and I guarantee it will fail .</tokentext>
<sentencetext>If you've been in the business for &gt;15yrs.
Smart people can still make a project fail miserably.
50/50 they also get in the way of a project (by miscalculating priorities for instance).
You don't just need smart people: you need the right people.
That's called a team.
To the MBA's, that management 101, and is no different for the s/w field.
Bring the wrong team, and I guarantee it will fail.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116098</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117278</id>
	<title>Re:Here are a few criticisms...</title>
	<author>Anonymous</author>
	<datestamp>1258395420000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>Agile has turned out to be the worst of Micromanagement.  Make replaceable parts out of every developer.  I doubt developers will be motivated to dig their own graves.</p><p>http://en.wikipedia.org/wiki/Micro\_Management</p></htmltext>
<tokenext>Agile has turned out to be the worst of Micromanagement .
Make replaceable parts out of every developer .
I doubt developers will be motivated to dig their own graves.http : //en.wikipedia.org/wiki/Micro \ _Management</tokentext>
<sentencetext>Agile has turned out to be the worst of Micromanagement.
Make replaceable parts out of every developer.
I doubt developers will be motivated to dig their own graves.http://en.wikipedia.org/wiki/Micro\_Management</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118374</id>
	<title>The big flaw of Agile</title>
	<author>tjstork</author>
	<datestamp>1258398600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Is that, everyone gets so caught up in "hours burned" for each scrum, that what is actually getting burned takes a back seat to the deliverable.  I was on a sprint where I had no hours burned for three days, which really, really sucked.  But at the end, I was the only one that actually had a product that you could do sprint demo with.</p></htmltext>
<tokenext>Is that , everyone gets so caught up in " hours burned " for each scrum , that what is actually getting burned takes a back seat to the deliverable .
I was on a sprint where I had no hours burned for three days , which really , really sucked .
But at the end , I was the only one that actually had a product that you could do sprint demo with .</tokentext>
<sentencetext>Is that, everyone gets so caught up in "hours burned" for each scrum, that what is actually getting burned takes a back seat to the deliverable.
I was on a sprint where I had no hours burned for three days, which really, really sucked.
But at the end, I was the only one that actually had a product that you could do sprint demo with.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116146</id>
	<title>Agile development in engineering?</title>
	<author>140Mandak262Jamuna</author>
	<datestamp>1258390620000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>Our company is trying to switch to Agile methods and have bought some software. Hoping to get training scheduled soon. But from what I see in the intro so far, all the examples are from GUI development or web support or IT where a large number of coders with very similar skill set is used to implement from the scratch a new application for deployment.<p>

But our company software has a large installed base and we need to fix bugs in existing code and somehow graft new functionalities into existing architecture with full backward compatibility for old saved data. And the skill set of coders varies widely. There are just a couple who can even touch isoparametric element stiffness matrix code, to name just one example. I still dont know how agile is going to change the way those two guys work. </p><p>

I see the advantages of early feedback, and early testing, testing partial implementations etc. But at some point for some kind of code development, Agile may not be the best way to do the code. And I am hoping the training will shed light on where I can use Agile and where I should stay clear of it. I don't want to jump on a band wagon because it is the latest and then have a minor revolt among my padavans.</p></htmltext>
<tokenext>Our company is trying to switch to Agile methods and have bought some software .
Hoping to get training scheduled soon .
But from what I see in the intro so far , all the examples are from GUI development or web support or IT where a large number of coders with very similar skill set is used to implement from the scratch a new application for deployment .
But our company software has a large installed base and we need to fix bugs in existing code and somehow graft new functionalities into existing architecture with full backward compatibility for old saved data .
And the skill set of coders varies widely .
There are just a couple who can even touch isoparametric element stiffness matrix code , to name just one example .
I still dont know how agile is going to change the way those two guys work .
I see the advantages of early feedback , and early testing , testing partial implementations etc .
But at some point for some kind of code development , Agile may not be the best way to do the code .
And I am hoping the training will shed light on where I can use Agile and where I should stay clear of it .
I do n't want to jump on a band wagon because it is the latest and then have a minor revolt among my padavans .</tokentext>
<sentencetext>Our company is trying to switch to Agile methods and have bought some software.
Hoping to get training scheduled soon.
But from what I see in the intro so far, all the examples are from GUI development or web support or IT where a large number of coders with very similar skill set is used to implement from the scratch a new application for deployment.
But our company software has a large installed base and we need to fix bugs in existing code and somehow graft new functionalities into existing architecture with full backward compatibility for old saved data.
And the skill set of coders varies widely.
There are just a couple who can even touch isoparametric element stiffness matrix code, to name just one example.
I still dont know how agile is going to change the way those two guys work.
I see the advantages of early feedback, and early testing, testing partial implementations etc.
But at some point for some kind of code development, Agile may not be the best way to do the code.
And I am hoping the training will shed light on where I can use Agile and where I should stay clear of it.
I don't want to jump on a band wagon because it is the latest and then have a minor revolt among my padavans.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120578</id>
	<title>Avalanche Development Process</title>
	<author>Hairy1</author>
	<datestamp>1258362360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Waterfall? Agile? All are passing fads. There is only one correct methodology, and you are probably using it already - Avalanche Software Development Process:<br><a href="http://www.youtube.com/watch?v=yR\_XIPOkSmQ" title="youtube.com">http://www.youtube.com/watch?v=yR\_XIPOkSmQ</a> [youtube.com]</p><p>Or perhaps you would like to actually implement Appropriate Design:<br><a href="http://www.youtube.com/watch?v=lNUQIjGe-ec" title="youtube.com">http://www.youtube.com/watch?v=lNUQIjGe-ec</a> [youtube.com]</p></htmltext>
<tokenext>Waterfall ?
Agile ? All are passing fads .
There is only one correct methodology , and you are probably using it already - Avalanche Software Development Process : http : //www.youtube.com/watch ? v = yR \ _XIPOkSmQ [ youtube.com ] Or perhaps you would like to actually implement Appropriate Design : http : //www.youtube.com/watch ? v = lNUQIjGe-ec [ youtube.com ]</tokentext>
<sentencetext>Waterfall?
Agile? All are passing fads.
There is only one correct methodology, and you are probably using it already - Avalanche Software Development Process:http://www.youtube.com/watch?v=yR\_XIPOkSmQ [youtube.com]Or perhaps you would like to actually implement Appropriate Design:http://www.youtube.com/watch?v=lNUQIjGe-ec [youtube.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116346</id>
	<title>Evolutionary Prototyping</title>
	<author>PIPBoy3000</author>
	<datestamp>1258391580000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>My preferred approach these days is what I think is technically called Evolutionary Prototyping.  Basically you start with some rough requirements, make something to show people, get more refined requirements, and repeat.  At some point when the product is useful, you go live, but in reality you're never done and just the time between deployments gets longer.
<br> <br>
This approach is horrible for things that have to work perfectly the first time (e.g. rockets to Mars), but for web development seems to be a decent approach.  It's also hard to estimate how long something will take, as the requirements aren't known up front.  Still, it's what I've been using for years.  I don't think I knew what it was called until our organization brought in a consultant to talk about this stuff.</htmltext>
<tokenext>My preferred approach these days is what I think is technically called Evolutionary Prototyping .
Basically you start with some rough requirements , make something to show people , get more refined requirements , and repeat .
At some point when the product is useful , you go live , but in reality you 're never done and just the time between deployments gets longer .
This approach is horrible for things that have to work perfectly the first time ( e.g .
rockets to Mars ) , but for web development seems to be a decent approach .
It 's also hard to estimate how long something will take , as the requirements are n't known up front .
Still , it 's what I 've been using for years .
I do n't think I knew what it was called until our organization brought in a consultant to talk about this stuff .</tokentext>
<sentencetext>My preferred approach these days is what I think is technically called Evolutionary Prototyping.
Basically you start with some rough requirements, make something to show people, get more refined requirements, and repeat.
At some point when the product is useful, you go live, but in reality you're never done and just the time between deployments gets longer.
This approach is horrible for things that have to work perfectly the first time (e.g.
rockets to Mars), but for web development seems to be a decent approach.
It's also hard to estimate how long something will take, as the requirements aren't known up front.
Still, it's what I've been using for years.
I don't think I knew what it was called until our organization brought in a consultant to talk about this stuff.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124620</id>
	<title>Re:Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258380960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Say what you will.   Software may be agile, but the infrastructure is still waterfall.</p></htmltext>
<tokenext>Say what you will .
Software may be agile , but the infrastructure is still waterfall .</tokentext>
<sentencetext>Say what you will.
Software may be agile, but the infrastructure is still waterfall.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115894</id>
	<title>Waterfall</title>
	<author>Anonymous</author>
	<datestamp>1258389600000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>Waterfall crushes a piece of my soul every day.</p></htmltext>
<tokenext>Waterfall crushes a piece of my soul every day .</tokentext>
<sentencetext>Waterfall crushes a piece of my soul every day.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119018</id>
	<title>Agile vs. Predictive</title>
	<author>Anonymous</author>
	<datestamp>1258400640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Management buys into "Agile" because they think it means "fast"<nobr> <wbr></nobr>... "We'll get our software developed faster!!! Run, Team, Run!"</p><p>The reality is that "Agile" means agile, not fast. To understand this, consider the difference between a bicycle (a very agile vehicle), and a 53' long 18-wheel truck (not even close to agile).</p><p>Which vehicle you want to use depends on what you need to do:</p><p>If you launch one space shuttle every five years, but it absolutely positively must work as planned the first time; then you use a predictive model (CMMI); because the process will force you to dot every i, cross every t, and sacrifice the proper amount of goats to the correct evil deities at the most auspicious times for doing so, and your shuttle will launch without blowing up.</p><p>If you've got a small online game, and you need to add new user-ready features constantly, and the end users are happy with "a little rough around the edges", then use an agile model (XP, SCRUM, etc.); it'll help you respond to user feedback in time for it to be useful.</p><p>You wouldn't use a bicycle to haul 50,000 lbs from Florida to Washington, and you wouldn't use a big rig truck to deliver hundreds of small packages to hundreds of different addresses in downtown NYC.</p><p>Why would anybody expect a software process to fit every kind of software to be developed?</p></htmltext>
<tokenext>Management buys into " Agile " because they think it means " fast " ... " We 'll get our software developed faster ! ! !
Run , Team , Run !
" The reality is that " Agile " means agile , not fast .
To understand this , consider the difference between a bicycle ( a very agile vehicle ) , and a 53 ' long 18-wheel truck ( not even close to agile ) .Which vehicle you want to use depends on what you need to do : If you launch one space shuttle every five years , but it absolutely positively must work as planned the first time ; then you use a predictive model ( CMMI ) ; because the process will force you to dot every i , cross every t , and sacrifice the proper amount of goats to the correct evil deities at the most auspicious times for doing so , and your shuttle will launch without blowing up.If you 've got a small online game , and you need to add new user-ready features constantly , and the end users are happy with " a little rough around the edges " , then use an agile model ( XP , SCRUM , etc .
) ; it 'll help you respond to user feedback in time for it to be useful.You would n't use a bicycle to haul 50,000 lbs from Florida to Washington , and you would n't use a big rig truck to deliver hundreds of small packages to hundreds of different addresses in downtown NYC.Why would anybody expect a software process to fit every kind of software to be developed ?</tokentext>
<sentencetext>Management buys into "Agile" because they think it means "fast" ... "We'll get our software developed faster!!!
Run, Team, Run!
"The reality is that "Agile" means agile, not fast.
To understand this, consider the difference between a bicycle (a very agile vehicle), and a 53' long 18-wheel truck (not even close to agile).Which vehicle you want to use depends on what you need to do:If you launch one space shuttle every five years, but it absolutely positively must work as planned the first time; then you use a predictive model (CMMI); because the process will force you to dot every i, cross every t, and sacrifice the proper amount of goats to the correct evil deities at the most auspicious times for doing so, and your shuttle will launch without blowing up.If you've got a small online game, and you need to add new user-ready features constantly, and the end users are happy with "a little rough around the edges", then use an agile model (XP, SCRUM, etc.
); it'll help you respond to user feedback in time for it to be useful.You wouldn't use a bicycle to haul 50,000 lbs from Florida to Washington, and you wouldn't use a big rig truck to deliver hundreds of small packages to hundreds of different addresses in downtown NYC.Why would anybody expect a software process to fit every kind of software to be developed?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117180</id>
	<title>Menthodologies</title>
	<author>Anonymous</author>
	<datestamp>1258395060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>"Among the more popular Agile Menthodologies are "</p><p>What's a Menthodology?  Is that a minty way of making software?</p></htmltext>
<tokenext>" Among the more popular Agile Menthodologies are " What 's a Menthodology ?
Is that a minty way of making software ?</tokentext>
<sentencetext>"Among the more popular Agile Menthodologies are "What's a Menthodology?
Is that a minty way of making software?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119676</id>
	<title>Re:Methodology fads</title>
	<author>Darinbob</author>
	<datestamp>1258402680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>A problem with many of these methodologies is that they claim to be the silver bullet, or at least be a one-size-fits-all approach.  The waterfall model may be inefficient for short quick feature changes to existing products, but on the other hand the Agile approach is not very good for long term project planning and infrastructures.  Often these methodologies become ideologies, with proponents pushing the ideas religiously.  Ie, the project manager who has the attitude that everything will be great if everyone would just do what he says, or that problems in the past were do to imperfect implementation of the methodology.<br><br>These aren't completely snake oil, but there's a bit of that substance mixed in to be sure.</htmltext>
<tokenext>A problem with many of these methodologies is that they claim to be the silver bullet , or at least be a one-size-fits-all approach .
The waterfall model may be inefficient for short quick feature changes to existing products , but on the other hand the Agile approach is not very good for long term project planning and infrastructures .
Often these methodologies become ideologies , with proponents pushing the ideas religiously .
Ie , the project manager who has the attitude that everything will be great if everyone would just do what he says , or that problems in the past were do to imperfect implementation of the methodology.These are n't completely snake oil , but there 's a bit of that substance mixed in to be sure .</tokentext>
<sentencetext>A problem with many of these methodologies is that they claim to be the silver bullet, or at least be a one-size-fits-all approach.
The waterfall model may be inefficient for short quick feature changes to existing products, but on the other hand the Agile approach is not very good for long term project planning and infrastructures.
Often these methodologies become ideologies, with proponents pushing the ideas religiously.
Ie, the project manager who has the attitude that everything will be great if everyone would just do what he says, or that problems in the past were do to imperfect implementation of the methodology.These aren't completely snake oil, but there's a bit of that substance mixed in to be sure.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118098</id>
	<title>Re:Agile development in engineering?</title>
	<author>Anonymous</author>
	<datestamp>1258397880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I ask you that you go into it with an open mind. Agile stuff has been treated as an overhyped bogeyman (look at all the posts here) and understandably many of us geeks are very cautious to approach it. However, if you pull the layers of hype and bullshit away, you recognize that it's just a different mindset that guides the work. This mindset happens to work a lot better with people and software (I am now convinced of this).</p><p>I'm hoping that you have a good instructor for training. But also, I am hoping that you have access to that instructor for questions afterwards, because that's really the most useful part. Every kind of training I've seen presents idealized examples to some degree, but a smart instructor will be able to tell you how you can work your situation.</p><p>For example, for varied skill sets, once you make up your team, try to take on a mix of stories (simplified use cases) that *approximately* reflects the skills breakdown. For example, if you have only two people that can touch your matrix code, take only on one or two matrix-work-intensive stories per sprint. After all, you have to be realistic.</p><p>(However, maybe a third person on your team would like to learn this matrix code. By sitting that person down with the matrix code expert and going through several dev tasks together, that person may learn something and may pick up these skills. Sure, it will feel slower at first, but now you have greater versatility in your team.)</p><p>If you are primarily doing fixes, then just reflect that in your wording of the stories. For example, we had to do some work to improve the startup performance of our product. We came up with stories that said, "As an administrator, I want my server to restart in less than X seconds." When we did some loose estimates, we realized that this was too much work to fit into a one-week sprint. So we split it into "As an administrator, I want my server to restart in less than X seconds, on Windows" and "... on Linux." This is because after doing some investigation, we realized that there was a lot of different work to be done for Windows vs Linux. This is not a perfect split of user stories (you want to keep such platform details out as much as possible), but that's OK. Do what works for you.</p><p>I have resolved to myself that, if I can help it, I am never again going to work at a place that does old-school waterfall. My team right now is in the middle of a transition to a Scrum-esque approach. We are running into plenty of problems, our team members have varied skills and some are much more versatile than others (Etc etc). However, it's already a better situation than what we had before.</p><p>So far, I am enjoying working off a prioritized product backlog, concentrating on getting smaller features DONE DONE, working in short iterations (2 weeks), and having the team who is fairly open to "let's change it if it doesn't work".</p><p>For one, many times before, spend months nailing down a long list of requirements, estimating the whole freaking thing, arguing between product management and engineering, cutting things to try to fit a set of features into some deadline (based on start-of-project estimates). Our product management would fight to keep certain things in that were important but not that important (because they did not want them to get dropped until the next release, that was many many months away). The developers (including me) would sit there, pulling estimates out of our collective ass for a ton of features, with barely any information for some of them.</p><p>Then we'd write extensive software requirement specifications (SRS) based on what was agreed to be implemented. The QA would go off to write test cases based on those SRSs. Of course, the use cases in these requirements were too detailed in some respects and not detailed enough in others, and completely missing the boat in yet other aspects. But, since they were signed off as "complete", we spent the rest of the project following what was agreed upon in the beginning instead of adjusting to the new proc</p></htmltext>
<tokenext>I ask you that you go into it with an open mind .
Agile stuff has been treated as an overhyped bogeyman ( look at all the posts here ) and understandably many of us geeks are very cautious to approach it .
However , if you pull the layers of hype and bullshit away , you recognize that it 's just a different mindset that guides the work .
This mindset happens to work a lot better with people and software ( I am now convinced of this ) .I 'm hoping that you have a good instructor for training .
But also , I am hoping that you have access to that instructor for questions afterwards , because that 's really the most useful part .
Every kind of training I 've seen presents idealized examples to some degree , but a smart instructor will be able to tell you how you can work your situation.For example , for varied skill sets , once you make up your team , try to take on a mix of stories ( simplified use cases ) that * approximately * reflects the skills breakdown .
For example , if you have only two people that can touch your matrix code , take only on one or two matrix-work-intensive stories per sprint .
After all , you have to be realistic .
( However , maybe a third person on your team would like to learn this matrix code .
By sitting that person down with the matrix code expert and going through several dev tasks together , that person may learn something and may pick up these skills .
Sure , it will feel slower at first , but now you have greater versatility in your team .
) If you are primarily doing fixes , then just reflect that in your wording of the stories .
For example , we had to do some work to improve the startup performance of our product .
We came up with stories that said , " As an administrator , I want my server to restart in less than X seconds .
" When we did some loose estimates , we realized that this was too much work to fit into a one-week sprint .
So we split it into " As an administrator , I want my server to restart in less than X seconds , on Windows " and " ... on Linux .
" This is because after doing some investigation , we realized that there was a lot of different work to be done for Windows vs Linux .
This is not a perfect split of user stories ( you want to keep such platform details out as much as possible ) , but that 's OK. Do what works for you.I have resolved to myself that , if I can help it , I am never again going to work at a place that does old-school waterfall .
My team right now is in the middle of a transition to a Scrum-esque approach .
We are running into plenty of problems , our team members have varied skills and some are much more versatile than others ( Etc etc ) .
However , it 's already a better situation than what we had before.So far , I am enjoying working off a prioritized product backlog , concentrating on getting smaller features DONE DONE , working in short iterations ( 2 weeks ) , and having the team who is fairly open to " let 's change it if it does n't work " .For one , many times before , spend months nailing down a long list of requirements , estimating the whole freaking thing , arguing between product management and engineering , cutting things to try to fit a set of features into some deadline ( based on start-of-project estimates ) .
Our product management would fight to keep certain things in that were important but not that important ( because they did not want them to get dropped until the next release , that was many many months away ) .
The developers ( including me ) would sit there , pulling estimates out of our collective ass for a ton of features , with barely any information for some of them.Then we 'd write extensive software requirement specifications ( SRS ) based on what was agreed to be implemented .
The QA would go off to write test cases based on those SRSs .
Of course , the use cases in these requirements were too detailed in some respects and not detailed enough in others , and completely missing the boat in yet other aspects .
But , since they were signed off as " complete " , we spent the rest of the project following what was agreed upon in the beginning instead of adjusting to the new proc</tokentext>
<sentencetext>I ask you that you go into it with an open mind.
Agile stuff has been treated as an overhyped bogeyman (look at all the posts here) and understandably many of us geeks are very cautious to approach it.
However, if you pull the layers of hype and bullshit away, you recognize that it's just a different mindset that guides the work.
This mindset happens to work a lot better with people and software (I am now convinced of this).I'm hoping that you have a good instructor for training.
But also, I am hoping that you have access to that instructor for questions afterwards, because that's really the most useful part.
Every kind of training I've seen presents idealized examples to some degree, but a smart instructor will be able to tell you how you can work your situation.For example, for varied skill sets, once you make up your team, try to take on a mix of stories (simplified use cases) that *approximately* reflects the skills breakdown.
For example, if you have only two people that can touch your matrix code, take only on one or two matrix-work-intensive stories per sprint.
After all, you have to be realistic.
(However, maybe a third person on your team would like to learn this matrix code.
By sitting that person down with the matrix code expert and going through several dev tasks together, that person may learn something and may pick up these skills.
Sure, it will feel slower at first, but now you have greater versatility in your team.
)If you are primarily doing fixes, then just reflect that in your wording of the stories.
For example, we had to do some work to improve the startup performance of our product.
We came up with stories that said, "As an administrator, I want my server to restart in less than X seconds.
" When we did some loose estimates, we realized that this was too much work to fit into a one-week sprint.
So we split it into "As an administrator, I want my server to restart in less than X seconds, on Windows" and "... on Linux.
" This is because after doing some investigation, we realized that there was a lot of different work to be done for Windows vs Linux.
This is not a perfect split of user stories (you want to keep such platform details out as much as possible), but that's OK. Do what works for you.I have resolved to myself that, if I can help it, I am never again going to work at a place that does old-school waterfall.
My team right now is in the middle of a transition to a Scrum-esque approach.
We are running into plenty of problems, our team members have varied skills and some are much more versatile than others (Etc etc).
However, it's already a better situation than what we had before.So far, I am enjoying working off a prioritized product backlog, concentrating on getting smaller features DONE DONE, working in short iterations (2 weeks), and having the team who is fairly open to "let's change it if it doesn't work".For one, many times before, spend months nailing down a long list of requirements, estimating the whole freaking thing, arguing between product management and engineering, cutting things to try to fit a set of features into some deadline (based on start-of-project estimates).
Our product management would fight to keep certain things in that were important but not that important (because they did not want them to get dropped until the next release, that was many many months away).
The developers (including me) would sit there, pulling estimates out of our collective ass for a ton of features, with barely any information for some of them.Then we'd write extensive software requirement specifications (SRS) based on what was agreed to be implemented.
The QA would go off to write test cases based on those SRSs.
Of course, the use cases in these requirements were too detailed in some respects and not detailed enough in others, and completely missing the boat in yet other aspects.
But, since they were signed off as "complete", we spent the rest of the project following what was agreed upon in the beginning instead of adjusting to the new proc</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116146</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121238</id>
	<title>Re:Methodology fads</title>
	<author>Anonymous</author>
	<datestamp>1258365060000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><i> Trust your coders, give them access they need.</i>
<br>
<br>
Yeah, cause they will get laid off first. Most coders actually end up sabotaging the whole project, cause in the Agile "way", no one but the product owners gets the blame of failure. So if the project fails, the whole team usually gets the boot.

<br>
<br>
Someone show me one agile success that has been around for 5yrs? A real success (e.g. it runs the Boeing 787 flight computer "level") Google and MS are exceptions, cause they do Agile, but their main products are not done in the Agile way anymore...
<br>
<br>
Also, it is democratic coding, everyone's agenda's come out to play and you'll find not everyone is willing to tackle everything at full speed: some coders don't want to work much (slackers/job hoppers), some want to take all the cool work (resume builders), some want only specific problems (the PhDs), some want the critical-path problems (the prima donnas and corporate climbers), and some want the quickest tasks (the integrators/business coders). With no real schedule, index cards that only team members <b>with the same domain knowledge</b> know how to interpret and no responsibility (it's done when it's done mentality)--it just creates a game environment (coding is fun!) that ends up being a sweat shop from the 10K view.

<br>
<br>
And yes, agilista is a stupid name that conjures up religious/fanboy fantasies--              there, I said it.</htmltext>
<tokenext>Trust your coders , give them access they need .
Yeah , cause they will get laid off first .
Most coders actually end up sabotaging the whole project , cause in the Agile " way " , no one but the product owners gets the blame of failure .
So if the project fails , the whole team usually gets the boot .
Someone show me one agile success that has been around for 5yrs ?
A real success ( e.g .
it runs the Boeing 787 flight computer " level " ) Google and MS are exceptions , cause they do Agile , but their main products are not done in the Agile way anymore.. . Also , it is democratic coding , everyone 's agenda 's come out to play and you 'll find not everyone is willing to tackle everything at full speed : some coders do n't want to work much ( slackers/job hoppers ) , some want to take all the cool work ( resume builders ) , some want only specific problems ( the PhDs ) , some want the critical-path problems ( the prima donnas and corporate climbers ) , and some want the quickest tasks ( the integrators/business coders ) .
With no real schedule , index cards that only team members with the same domain knowledge know how to interpret and no responsibility ( it 's done when it 's done mentality ) --it just creates a game environment ( coding is fun !
) that ends up being a sweat shop from the 10K view .
And yes , agilista is a stupid name that conjures up religious/fanboy fantasies-- there , I said it .</tokentext>
<sentencetext> Trust your coders, give them access they need.
Yeah, cause they will get laid off first.
Most coders actually end up sabotaging the whole project, cause in the Agile "way", no one but the product owners gets the blame of failure.
So if the project fails, the whole team usually gets the boot.
Someone show me one agile success that has been around for 5yrs?
A real success (e.g.
it runs the Boeing 787 flight computer "level") Google and MS are exceptions, cause they do Agile, but their main products are not done in the Agile way anymore...


Also, it is democratic coding, everyone's agenda's come out to play and you'll find not everyone is willing to tackle everything at full speed: some coders don't want to work much (slackers/job hoppers), some want to take all the cool work (resume builders), some want only specific problems (the PhDs), some want the critical-path problems (the prima donnas and corporate climbers), and some want the quickest tasks (the integrators/business coders).
With no real schedule, index cards that only team members with the same domain knowledge know how to interpret and no responsibility (it's done when it's done mentality)--it just creates a game environment (coding is fun!
) that ends up being a sweat shop from the 10K view.
And yes, agilista is a stupid name that conjures up religious/fanboy fantasies--              there, I said it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116252</id>
	<title>Re:Methodology fads</title>
	<author>Austerity Empowers</author>
	<datestamp>1258391160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't know, but 6 sigma has gone retro here. Here's to 2020 being late 90's dot com chaos!</p></htmltext>
<tokenext>I do n't know , but 6 sigma has gone retro here .
Here 's to 2020 being late 90 's dot com chaos !</tokentext>
<sentencetext>I don't know, but 6 sigma has gone retro here.
Here's to 2020 being late 90's dot com chaos!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116710</id>
	<title>Is to become Fragile</title>
	<author>Anonymous</author>
	<datestamp>1258393320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Stupid methodology for control freaks.  Micromanagement at its worst!</p></htmltext>
<tokenext>Stupid methodology for control freaks .
Micromanagement at its worst !</tokentext>
<sentencetext>Stupid methodology for control freaks.
Micromanagement at its worst!</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30147018
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117142
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116762
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118098
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116146
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124094
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116522
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30126184
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124436
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118772
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122642
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120594
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119818
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117640
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116120
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30126708
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116110
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121896
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116324
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117848
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116120
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118906
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124222
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121394
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117370
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118038
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116110
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30127928
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117142
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117280
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118938
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120382
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122854
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120972
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119676
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116598
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122338
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116092
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121380
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30128034
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116146
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121238
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116326
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118594
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30132062
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121374
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116252
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119026
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116120
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30127240
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116522
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124620
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121338
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116394
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121526
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30128536
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122062
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116098
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121142
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119362
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119400
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116346
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_11_16_1448204_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117278
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118168
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119210
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117332
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116152
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117120
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116142
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116182
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115892
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116762
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30132062
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119676
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116326
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116356
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117280
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121142
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121238
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117370
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118594
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116324
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120972
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116252
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118938
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124620
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122338
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116120
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117640
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119818
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119026
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117848
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118374
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117142
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30127928
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30147018
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116146
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30128034
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118098
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115942
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115894
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116346
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119400
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115836
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116470
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121394
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30128536
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121380
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120382
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30126184
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116110
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118038
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30126708
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116522
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30127240
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124094
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116846
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124222
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121896
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118772
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30120594
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122642
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116098
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122854
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30122062
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121338
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116390
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116092
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121262
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30115930
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30119362
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116598
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30118906
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116394
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_11_16_1448204.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30116060
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121374
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30124436
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30117278
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_11_16_1448204.30121526
</commentlist>
</conversation>
