<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_06_13_1859216</id>
	<title>Are Code Reviews Worth It?</title>
	<author>kdawson</author>
	<datestamp>1244884980000</datestamp>
	<htmltext>JamaicaBay writes <i>"I'm a development manager, and the other day my boss and I got into an argument over whether it's worth doing code reviews. In my shop we've done both code reviews and design reviews. They are all programmer-led.  What we've found is that code reviews take forever and tend to reveal less than good UI-level testing would. The payback on design reviews, meanwhile, is tremendous. Our code is intended for desktop, non-critical use, so I asked my boss to consider whether it was worth spending so much time on examining built code, given our experience not getting much out of it. I'm wondering whether the Slashdot crowd's experience has been similar."</i></htmltext>
<tokenext>JamaicaBay writes " I 'm a development manager , and the other day my boss and I got into an argument over whether it 's worth doing code reviews .
In my shop we 've done both code reviews and design reviews .
They are all programmer-led .
What we 've found is that code reviews take forever and tend to reveal less than good UI-level testing would .
The payback on design reviews , meanwhile , is tremendous .
Our code is intended for desktop , non-critical use , so I asked my boss to consider whether it was worth spending so much time on examining built code , given our experience not getting much out of it .
I 'm wondering whether the Slashdot crowd 's experience has been similar .
"</tokentext>
<sentencetext>JamaicaBay writes "I'm a development manager, and the other day my boss and I got into an argument over whether it's worth doing code reviews.
In my shop we've done both code reviews and design reviews.
They are all programmer-led.
What we've found is that code reviews take forever and tend to reveal less than good UI-level testing would.
The payback on design reviews, meanwhile, is tremendous.
Our code is intended for desktop, non-critical use, so I asked my boss to consider whether it was worth spending so much time on examining built code, given our experience not getting much out of it.
I'm wondering whether the Slashdot crowd's experience has been similar.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325201</id>
	<title>Re:Are they worth it?</title>
	<author>localtoast</author>
	<datestamp>1245012600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>That movie Tommy Boy comes to mind.  The quote was something like this:

I can take a dump in a box and mark it guaranteed. All that I've done is sold you a guaranteed piece of shit.</div>
	</htmltext>
<tokenext>That movie Tommy Boy comes to mind .
The quote was something like this : I can take a dump in a box and mark it guaranteed .
All that I 've done is sold you a guaranteed piece of shit .</tokentext>
<sentencetext>That movie Tommy Boy comes to mind.
The quote was something like this:

I can take a dump in a box and mark it guaranteed.
All that I've done is sold you a guaranteed piece of shit.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28408955</id>
	<title>Changeset based code-reviews</title>
	<author>cmayerhofer</author>
	<datestamp>1245577680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Code reviews have a lot of benefits, most important to find bugs during development phase and to enforce coding standards -- and they help to share knowledge about a peace of code with other team-members (called collective code ownership). But most often traditional inspection methods consumes a lot of time, hence developers are discouraged doing code reviews during their regular work. Nowadays physical code-review meetings are also a problem, because development teams are shared across offices/countries/continents, having different time-zones. The planning of review-meetings is hard or even not possible. Another problem is the delocalization of code in object-oriented and dynamic programming languages. Inheritance, dynamic binding &amp; co. make it hard to understand an instruction, since developers use foreign classes and frameworks, and the business logic is shared across them.<br><br>Based on our experiences from previous projects we developed a code-review tool which follows a different approach: The review item is one changeset in the revision control system. Further author/reviewer assignments are defined. The reviewer subscribes to changes (new revisions) from the author and gets a new review task if the author makes a commit to the respository. The assignments may be done in a peer to peer manner, where the developers inspect the code changes of one or more team members. Reading each others code has the consequence, that developers also learn the code from their colleagues, thus supporting collective code ownership. A more hierarchical approach would be to assign a senior developer to review the code for new or less experienced developers. The senior developer in the role of the reviewer may enforce coding standards and better code quality within the development team.<br><br>The review-tool is called ReviewClipse (see http://www.inso.tuwien.ac.at/projects/reviewclipse/ for more information). It is free, full-integrated into Eclipse, and very easy to install and to use. All review data is stored within files, shared with the already configured repository of the Eclipse project. So there is no need to setup any server-side application, apart from the already existing versioning system.</htmltext>
<tokenext>Code reviews have a lot of benefits , most important to find bugs during development phase and to enforce coding standards -- and they help to share knowledge about a peace of code with other team-members ( called collective code ownership ) .
But most often traditional inspection methods consumes a lot of time , hence developers are discouraged doing code reviews during their regular work .
Nowadays physical code-review meetings are also a problem , because development teams are shared across offices/countries/continents , having different time-zones .
The planning of review-meetings is hard or even not possible .
Another problem is the delocalization of code in object-oriented and dynamic programming languages .
Inheritance , dynamic binding &amp; co. make it hard to understand an instruction , since developers use foreign classes and frameworks , and the business logic is shared across them.Based on our experiences from previous projects we developed a code-review tool which follows a different approach : The review item is one changeset in the revision control system .
Further author/reviewer assignments are defined .
The reviewer subscribes to changes ( new revisions ) from the author and gets a new review task if the author makes a commit to the respository .
The assignments may be done in a peer to peer manner , where the developers inspect the code changes of one or more team members .
Reading each others code has the consequence , that developers also learn the code from their colleagues , thus supporting collective code ownership .
A more hierarchical approach would be to assign a senior developer to review the code for new or less experienced developers .
The senior developer in the role of the reviewer may enforce coding standards and better code quality within the development team.The review-tool is called ReviewClipse ( see http : //www.inso.tuwien.ac.at/projects/reviewclipse/ for more information ) .
It is free , full-integrated into Eclipse , and very easy to install and to use .
All review data is stored within files , shared with the already configured repository of the Eclipse project .
So there is no need to setup any server-side application , apart from the already existing versioning system .</tokentext>
<sentencetext>Code reviews have a lot of benefits, most important to find bugs during development phase and to enforce coding standards -- and they help to share knowledge about a peace of code with other team-members (called collective code ownership).
But most often traditional inspection methods consumes a lot of time, hence developers are discouraged doing code reviews during their regular work.
Nowadays physical code-review meetings are also a problem, because development teams are shared across offices/countries/continents, having different time-zones.
The planning of review-meetings is hard or even not possible.
Another problem is the delocalization of code in object-oriented and dynamic programming languages.
Inheritance, dynamic binding &amp; co. make it hard to understand an instruction, since developers use foreign classes and frameworks, and the business logic is shared across them.Based on our experiences from previous projects we developed a code-review tool which follows a different approach: The review item is one changeset in the revision control system.
Further author/reviewer assignments are defined.
The reviewer subscribes to changes (new revisions) from the author and gets a new review task if the author makes a commit to the respository.
The assignments may be done in a peer to peer manner, where the developers inspect the code changes of one or more team members.
Reading each others code has the consequence, that developers also learn the code from their colleagues, thus supporting collective code ownership.
A more hierarchical approach would be to assign a senior developer to review the code for new or less experienced developers.
The senior developer in the role of the reviewer may enforce coding standards and better code quality within the development team.The review-tool is called ReviewClipse (see http://www.inso.tuwien.ac.at/projects/reviewclipse/ for more information).
It is free, full-integrated into Eclipse, and very easy to install and to use.
All review data is stored within files, shared with the already configured repository of the Eclipse project.
So there is no need to setup any server-side application, apart from the already existing versioning system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322839</id>
	<title>Video on Code Review</title>
	<author>Anonymous</author>
	<datestamp>1244891280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Code review is often viewed as a compliance task, not productive. This video talks about what code review can be, and how to make it more effective.</p><p><a href="http://www.youtube.com/watch?v=m2yRrROifqc" title="youtube.com" rel="nofollow">Code Reviews</a> [youtube.com]</p></htmltext>
<tokenext>Code review is often viewed as a compliance task , not productive .
This video talks about what code review can be , and how to make it more effective.Code Reviews [ youtube.com ]</tokentext>
<sentencetext>Code review is often viewed as a compliance task, not productive.
This video talks about what code review can be, and how to make it more effective.Code Reviews [youtube.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28329349</id>
	<title>Will you take action and fire bad programmers?</title>
	<author>nicholdraper</author>
	<datestamp>1244974800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Code reviews are only as good as the reviewer.  I've worked for companies that do the team over-head approach -- mostly a waste of time.  Pair programming -- valuable for some programmers, frankly I don't mind having someone look over my shoulder, but it's boring as can be to watch someone else program, especially when I'm faster.
Reviewing code of a failing project can be very valuable, recently I was asked to look at another team's project at the company where I work.  I took on a few assignments to complete parts of the project, I learned that they had spent a year of development time and money to write a database access layer.  I reported to my boss that they had wasted the companies money, I rewrote my portion using the Microsoft supplied DataSet and showed a simple operation taking 4 seconds in place of 90 seconds.  Fortunately my boss took the corrective action and let the team go.  The entire review took about four months.
I know that is not what you are thinking of when you talk about code reviews, but, just looking for bugs in code is not enough.  You have to have a competent senior programmer who knows how to evaluate code.  Two bad programmers are not any better than one bad programmer.
Throw out the silly coding standards that say tab stops must be 4 spaces, and ask a good programmer to look at the code to see if he is willing to take ownership.  If you don't know if you have a good programmer, ask a programmer to add a couple of automated unit tests to the code you want reviewed.  That will result in a better code review than any meeting or pairing.</htmltext>
<tokenext>Code reviews are only as good as the reviewer .
I 've worked for companies that do the team over-head approach -- mostly a waste of time .
Pair programming -- valuable for some programmers , frankly I do n't mind having someone look over my shoulder , but it 's boring as can be to watch someone else program , especially when I 'm faster .
Reviewing code of a failing project can be very valuable , recently I was asked to look at another team 's project at the company where I work .
I took on a few assignments to complete parts of the project , I learned that they had spent a year of development time and money to write a database access layer .
I reported to my boss that they had wasted the companies money , I rewrote my portion using the Microsoft supplied DataSet and showed a simple operation taking 4 seconds in place of 90 seconds .
Fortunately my boss took the corrective action and let the team go .
The entire review took about four months .
I know that is not what you are thinking of when you talk about code reviews , but , just looking for bugs in code is not enough .
You have to have a competent senior programmer who knows how to evaluate code .
Two bad programmers are not any better than one bad programmer .
Throw out the silly coding standards that say tab stops must be 4 spaces , and ask a good programmer to look at the code to see if he is willing to take ownership .
If you do n't know if you have a good programmer , ask a programmer to add a couple of automated unit tests to the code you want reviewed .
That will result in a better code review than any meeting or pairing .</tokentext>
<sentencetext>Code reviews are only as good as the reviewer.
I've worked for companies that do the team over-head approach -- mostly a waste of time.
Pair programming -- valuable for some programmers, frankly I don't mind having someone look over my shoulder, but it's boring as can be to watch someone else program, especially when I'm faster.
Reviewing code of a failing project can be very valuable, recently I was asked to look at another team's project at the company where I work.
I took on a few assignments to complete parts of the project, I learned that they had spent a year of development time and money to write a database access layer.
I reported to my boss that they had wasted the companies money, I rewrote my portion using the Microsoft supplied DataSet and showed a simple operation taking 4 seconds in place of 90 seconds.
Fortunately my boss took the corrective action and let the team go.
The entire review took about four months.
I know that is not what you are thinking of when you talk about code reviews, but, just looking for bugs in code is not enough.
You have to have a competent senior programmer who knows how to evaluate code.
Two bad programmers are not any better than one bad programmer.
Throw out the silly coding standards that say tab stops must be 4 spaces, and ask a good programmer to look at the code to see if he is willing to take ownership.
If you don't know if you have a good programmer, ask a programmer to add a couple of automated unit tests to the code you want reviewed.
That will result in a better code review than any meeting or pairing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324065</id>
	<title>The real value of doing code reviews...</title>
	<author>The Famous Druid</author>
	<datestamp>1244905380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>...isn't how much bad code you find.<p>
It's how much bad code never gets written in the first place, because the programmer knows his/her code is going to be reviewed.</p><p>
When you know your code will be reviewed, you resist the temptation to take the quick-and-dirty shortcut that you know will get picked up in a review, you do it right the first time.</p></htmltext>
<tokenext>...is n't how much bad code you find .
It 's how much bad code never gets written in the first place , because the programmer knows his/her code is going to be reviewed .
When you know your code will be reviewed , you resist the temptation to take the quick-and-dirty shortcut that you know will get picked up in a review , you do it right the first time .</tokentext>
<sentencetext>...isn't how much bad code you find.
It's how much bad code never gets written in the first place, because the programmer knows his/her code is going to be reviewed.
When you know your code will be reviewed, you resist the temptation to take the quick-and-dirty shortcut that you know will get picked up in a review, you do it right the first time.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28335605</id>
	<title>Correct by Construction</title>
	<author>thethibs</author>
	<datestamp>1245082920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>We can't let this discussion pass without a word from Dijkstra (EWD340):</p><p> <i>
Argument three is based on the constructive approach to the problem of program correctness. Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer's burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. Argument three is essentially based on the following observation. If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof's requirements, then these correctness concerns turn out to be a very effective heuristic guidance. By definition this approach is only applicable when we restrict ourselves to intellectually manageable programs, but it provides us with effective means for finding a satisfactory one among these.
</i> </p></htmltext>
<tokenext>We ca n't let this discussion pass without a word from Dijkstra ( EWD340 ) : Argument three is based on the constructive approach to the problem of program correctness .
Today a usual technique is to make a program and then to test it .
But : program testing can be a very effective way to show the presence of bugs , but is hopelessly inadequate for showing their absence .
The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness .
But one should not first make the program and then prove its correctness , because then the requirement of providing the proof would only increase the poor programmer 's burden .
On the contrary : the programmer should let correctness proof and program grow hand in hand .
Argument three is essentially based on the following observation .
If one first asks oneself what the structure of a convincing proof would be and , having found this , then constructs a program satisfying this proof 's requirements , then these correctness concerns turn out to be a very effective heuristic guidance .
By definition this approach is only applicable when we restrict ourselves to intellectually manageable programs , but it provides us with effective means for finding a satisfactory one among these .</tokentext>
<sentencetext>We can't let this discussion pass without a word from Dijkstra (EWD340): 
Argument three is based on the constructive approach to the problem of program correctness.
Today a usual technique is to make a program and then to test it.
But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.
The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness.
But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer's burden.
On the contrary: the programmer should let correctness proof and program grow hand in hand.
Argument three is essentially based on the following observation.
If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof's requirements, then these correctness concerns turn out to be a very effective heuristic guidance.
By definition this approach is only applicable when we restrict ourselves to intellectually manageable programs, but it provides us with effective means for finding a satisfactory one among these.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322881</id>
	<title>Doesn't mean it was a value add.</title>
	<author>Anonymous</author>
	<datestamp>1244891760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Yes-  but would the time have been better spent on something else than an absolutely corner-case bug.   That's the question.  Not whether they can catch bugs...  They can!   But can you catch more with those same resources spent on UI testing, or writing automated tests.  Or is the business better off accepting that little bug and spending the time developing new work.   Just because a bug was found doesn't mean the exercise was valuable.</p></htmltext>
<tokenext>Yes- but would the time have been better spent on something else than an absolutely corner-case bug .
That 's the question .
Not whether they can catch bugs... They can !
But can you catch more with those same resources spent on UI testing , or writing automated tests .
Or is the business better off accepting that little bug and spending the time developing new work .
Just because a bug was found does n't mean the exercise was valuable .</tokentext>
<sentencetext>Yes-  but would the time have been better spent on something else than an absolutely corner-case bug.
That's the question.
Not whether they can catch bugs...  They can!
But can you catch more with those same resources spent on UI testing, or writing automated tests.
Or is the business better off accepting that little bug and spending the time developing new work.
Just because a bug was found doesn't mean the exercise was valuable.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322849</id>
	<title>Re:If you did test-driven development</title>
	<author>Anonymous</author>
	<datestamp>1244891400000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p><i>then code reviews would be redundant.</i></p><p>Err... no.  Testing is not a replacement for code reviews, which do a variety of things, including enforcing coding and commenting standards, act as sanity checks in implementation of design, etc.  They also find the bugs that you never thought to design tests against.</p><p>Test driven development is a good way of capturing requirements in testing up-front, rather than leaving that as a downstream activity the way conventional testing is done.  Doing test-driven development will not cause your test set to be any more thorough than a properly done V&amp;V test set.</p><p>A while back on<nobr> <wbr></nobr>/. we had a story about a serious bug in a major product (can't remember what it was) and someone commented that "this seems like the kind of thing that test-driven development would have caught" as if the tests the developers would have thought of doing in a test-driven environment would have been any different than the tests developers would have thought of doing in an environment with sane down-stream testing.  There is absolutely no reason to believe this.</p></htmltext>
<tokenext>then code reviews would be redundant.Err... no. Testing is not a replacement for code reviews , which do a variety of things , including enforcing coding and commenting standards , act as sanity checks in implementation of design , etc .
They also find the bugs that you never thought to design tests against.Test driven development is a good way of capturing requirements in testing up-front , rather than leaving that as a downstream activity the way conventional testing is done .
Doing test-driven development will not cause your test set to be any more thorough than a properly done V&amp;V test set.A while back on / .
we had a story about a serious bug in a major product ( ca n't remember what it was ) and someone commented that " this seems like the kind of thing that test-driven development would have caught " as if the tests the developers would have thought of doing in a test-driven environment would have been any different than the tests developers would have thought of doing in an environment with sane down-stream testing .
There is absolutely no reason to believe this .</tokentext>
<sentencetext>then code reviews would be redundant.Err... no.  Testing is not a replacement for code reviews, which do a variety of things, including enforcing coding and commenting standards, act as sanity checks in implementation of design, etc.
They also find the bugs that you never thought to design tests against.Test driven development is a good way of capturing requirements in testing up-front, rather than leaving that as a downstream activity the way conventional testing is done.
Doing test-driven development will not cause your test set to be any more thorough than a properly done V&amp;V test set.A while back on /.
we had a story about a serious bug in a major product (can't remember what it was) and someone commented that "this seems like the kind of thing that test-driven development would have caught" as if the tests the developers would have thought of doing in a test-driven environment would have been any different than the tests developers would have thought of doing in an environment with sane down-stream testing.
There is absolutely no reason to believe this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322675</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28353139</id>
	<title>Re:Depends what you are reviewing</title>
	<author>Anonymous</author>
	<datestamp>1245144720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Quite simply, code reviews cost money and production bugs cost money.</p><p>We do code reviews for anything where it'll either be devastating expensive if we encounter a failure or if it'll be very hard to detect a failure. Otherwise, in my particular line of work, it's more economical to accept a lower cost and faster pace of development at the expense of dealing with a few bugs that are discovered in production.</p></div><p>Yes, but code refactoring also costs money. If someone has to come back later to add functionality, but they can't figure out what is going on, it's a problem.</p></div>
	</htmltext>
<tokenext>Quite simply , code reviews cost money and production bugs cost money.We do code reviews for anything where it 'll either be devastating expensive if we encounter a failure or if it 'll be very hard to detect a failure .
Otherwise , in my particular line of work , it 's more economical to accept a lower cost and faster pace of development at the expense of dealing with a few bugs that are discovered in production.Yes , but code refactoring also costs money .
If someone has to come back later to add functionality , but they ca n't figure out what is going on , it 's a problem .</tokentext>
<sentencetext>Quite simply, code reviews cost money and production bugs cost money.We do code reviews for anything where it'll either be devastating expensive if we encounter a failure or if it'll be very hard to detect a failure.
Otherwise, in my particular line of work, it's more economical to accept a lower cost and faster pace of development at the expense of dealing with a few bugs that are discovered in production.Yes, but code refactoring also costs money.
If someone has to come back later to add functionality, but they can't figure out what is going on, it's a problem.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28332875</id>
	<title>In my experience...</title>
	<author>jazzduck</author>
	<datestamp>1245057240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In my experience, code reviews help the developer much more than they help the product. And this is a Good Thing.</p><p>Take me, for example. A few years ago, I was just out of college, 9 months on the job with a global consulting firm, working on a large Java-based web application for a government department. I was assigned a complex and poorly-defined module to write. While my first stab at the module worked fine, passed unit testing, and satisfied all the functional requirements, it was kludgy and would have been inelegant for maintenance programmers to work with. One of the project managers took the time (about two hours!) to go over my module, reading the code until he understood it, and then asked me penetrating questions and made really good suggestions about how to change it so that it didn't just work, but was elegant and maintainable as well.</p><p>Those two hours, and the subsequent 30 that I spent rewriting that module, cost my firm one or two thousand dollars, I suspect, on a fixed-price contract that was already over-budget. From an economic point of view, it made no sense for that review and rewrite to occur. But they made me into a much better developer both from a technical standpoint (I learned a better way to design the algorithm) and from a social standpoint (I learned a better way to make my code maintainable). I really liked being part of a company that was willing to sink that time and money into helping me improve my skills.</p><p>So should companies have code reviews? Absolutely -- if they care about increasing the skills and maturity of their developers. If they intend for their developers' skills to stagnate, and they don't understand the value of investing in the continued education of their staff, then surely not.</p></htmltext>
<tokenext>In my experience , code reviews help the developer much more than they help the product .
And this is a Good Thing.Take me , for example .
A few years ago , I was just out of college , 9 months on the job with a global consulting firm , working on a large Java-based web application for a government department .
I was assigned a complex and poorly-defined module to write .
While my first stab at the module worked fine , passed unit testing , and satisfied all the functional requirements , it was kludgy and would have been inelegant for maintenance programmers to work with .
One of the project managers took the time ( about two hours !
) to go over my module , reading the code until he understood it , and then asked me penetrating questions and made really good suggestions about how to change it so that it did n't just work , but was elegant and maintainable as well.Those two hours , and the subsequent 30 that I spent rewriting that module , cost my firm one or two thousand dollars , I suspect , on a fixed-price contract that was already over-budget .
From an economic point of view , it made no sense for that review and rewrite to occur .
But they made me into a much better developer both from a technical standpoint ( I learned a better way to design the algorithm ) and from a social standpoint ( I learned a better way to make my code maintainable ) .
I really liked being part of a company that was willing to sink that time and money into helping me improve my skills.So should companies have code reviews ?
Absolutely -- if they care about increasing the skills and maturity of their developers .
If they intend for their developers ' skills to stagnate , and they do n't understand the value of investing in the continued education of their staff , then surely not .</tokentext>
<sentencetext>In my experience, code reviews help the developer much more than they help the product.
And this is a Good Thing.Take me, for example.
A few years ago, I was just out of college, 9 months on the job with a global consulting firm, working on a large Java-based web application for a government department.
I was assigned a complex and poorly-defined module to write.
While my first stab at the module worked fine, passed unit testing, and satisfied all the functional requirements, it was kludgy and would have been inelegant for maintenance programmers to work with.
One of the project managers took the time (about two hours!
) to go over my module, reading the code until he understood it, and then asked me penetrating questions and made really good suggestions about how to change it so that it didn't just work, but was elegant and maintainable as well.Those two hours, and the subsequent 30 that I spent rewriting that module, cost my firm one or two thousand dollars, I suspect, on a fixed-price contract that was already over-budget.
From an economic point of view, it made no sense for that review and rewrite to occur.
But they made me into a much better developer both from a technical standpoint (I learned a better way to design the algorithm) and from a social standpoint (I learned a better way to make my code maintainable).
I really liked being part of a company that was willing to sink that time and money into helping me improve my skills.So should companies have code reviews?
Absolutely -- if they care about increasing the skills and maturity of their developers.
If they intend for their developers' skills to stagnate, and they don't understand the value of investing in the continued education of their staff, then surely not.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28346409</id>
	<title>Re:a fucktonne?</title>
	<author>Anonymous</author>
	<datestamp>1245159660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Damn europeans and their metric system.</p></div><p>lol heads up dude.   its like everyone BUT the US and their metric system.</p></div>
	</htmltext>
<tokenext>Damn europeans and their metric system.lol heads up dude .
its like everyone BUT the US and their metric system .</tokentext>
<sentencetext>Damn europeans and their metric system.lol heads up dude.
its like everyone BUT the US and their metric system.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28470583</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>Hurricane78</author>
	<datestamp>1245961620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>In a life critical system, it costs a fucktonne..</p></div><p>That's a "nice" way, of saying, that a human being just died for no reason at all, but you screwing up.<nobr> <wbr></nobr>:/</p><p>How many fucktonnes did the Iraq war cost btw?</p></div>
	</htmltext>
<tokenext>In a life critical system , it costs a fucktonne..That 's a " nice " way , of saying , that a human being just died for no reason at all , but you screwing up .
: /How many fucktonnes did the Iraq war cost btw ?</tokentext>
<sentencetext>In a life critical system, it costs a fucktonne..That's a "nice" way, of saying, that a human being just died for no reason at all, but you screwing up.
:/How many fucktonnes did the Iraq war cost btw?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28334479</id>
	<title>Re:Dijkstra's troll</title>
	<author>Ihlosi</author>
	<datestamp>1245077040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><i>The purpose of the few coding reviews I have assisted was only to improve code metrics in order to avoid:</i> <p>

Err<nobr> <wbr></nobr>... that's not the job of a code review. Make some coding guidelines and stick with them, e.g. no more than X levels of nesting unless you submit a written statement of necessity, functions should be no longer than Y lines (exceptions allowed), etc.</p></htmltext>
<tokenext>The purpose of the few coding reviews I have assisted was only to improve code metrics in order to avoid : Err ... that 's not the job of a code review .
Make some coding guidelines and stick with them , e.g .
no more than X levels of nesting unless you submit a written statement of necessity , functions should be no longer than Y lines ( exceptions allowed ) , etc .</tokentext>
<sentencetext>The purpose of the few coding reviews I have assisted was only to improve code metrics in order to avoid: 

Err ... that's not the job of a code review.
Make some coding guidelines and stick with them, e.g.
no more than X levels of nesting unless you submit a written statement of necessity, functions should be no longer than Y lines (exceptions allowed), etc.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323199</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322549</id>
	<title>Hell Fucking No</title>
	<author>Anonymous</author>
	<datestamp>1244888940000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>In particular, if you are reviewing H1B Visa Indian code then while doing the review you will end up wanting to slit your wrists.</p></htmltext>
<tokenext>In particular , if you are reviewing H1B Visa Indian code then while doing the review you will end up wanting to slit your wrists .</tokentext>
<sentencetext>In particular, if you are reviewing H1B Visa Indian code then while doing the review you will end up wanting to slit your wrists.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324613</id>
	<title>You are TOTALLY doing them wrong</title>
	<author>MobyDisk</author>
	<datestamp>1244914020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>code reviews take forever and tend to reveal less than good UI-level testing would</p></div><p>WOW.  Just WOW.  You must be doing a numer of things incorrectly.  Let me offer some suggestions:
(Although, UI testing is definitely a pre-requisite here, and nothing will find more bugs than just using the software.)
<br>
1) Everyone must read and understand the code before the review.<br>
2) Allocate time in the schedule for code reviews.<br>
3) 
4) No bosses, managers, testers, or other non-coding positions in the review.<br>
5) Do not read the code line-by-line or even function-by-function.  <br>
<br>
Everyone should have the code marked-up with comments and questions prior to the meeting.  The goal of the meeting is to go through those, not to go through the code itself.
The meeting should start with:
"Author: Has everyone read the code?"  If there are any "No's" then dismiss the meeting and those people can read the code during the time allocated for the meeting.
"Author: Are there any major design, or module-level questions or comments?"  This is the time to address major items like using the wrong tools, libraries, etc.  (Although in theory, those were caught during a design phase, but it can happen)
Now, go through the comments and questions.  Or go function-by-function if you can.  Maybe with "This function does X: Any comments or questions?  Next.  This function does Y..."
<br>
At this rate, you should be able to review weeks of code in an hour.</p></div>
	</htmltext>
<tokenext>code reviews take forever and tend to reveal less than good UI-level testing wouldWOW .
Just WOW .
You must be doing a numer of things incorrectly .
Let me offer some suggestions : ( Although , UI testing is definitely a pre-requisite here , and nothing will find more bugs than just using the software .
) 1 ) Everyone must read and understand the code before the review .
2 ) Allocate time in the schedule for code reviews .
3 ) 4 ) No bosses , managers , testers , or other non-coding positions in the review .
5 ) Do not read the code line-by-line or even function-by-function .
Everyone should have the code marked-up with comments and questions prior to the meeting .
The goal of the meeting is to go through those , not to go through the code itself .
The meeting should start with : " Author : Has everyone read the code ?
" If there are any " No 's " then dismiss the meeting and those people can read the code during the time allocated for the meeting .
" Author : Are there any major design , or module-level questions or comments ?
" This is the time to address major items like using the wrong tools , libraries , etc .
( Although in theory , those were caught during a design phase , but it can happen ) Now , go through the comments and questions .
Or go function-by-function if you can .
Maybe with " This function does X : Any comments or questions ?
Next. This function does Y... " At this rate , you should be able to review weeks of code in an hour .</tokentext>
<sentencetext>code reviews take forever and tend to reveal less than good UI-level testing wouldWOW.
Just WOW.
You must be doing a numer of things incorrectly.
Let me offer some suggestions:
(Although, UI testing is definitely a pre-requisite here, and nothing will find more bugs than just using the software.
)

1) Everyone must read and understand the code before the review.
2) Allocate time in the schedule for code reviews.
3) 
4) No bosses, managers, testers, or other non-coding positions in the review.
5) Do not read the code line-by-line or even function-by-function.
Everyone should have the code marked-up with comments and questions prior to the meeting.
The goal of the meeting is to go through those, not to go through the code itself.
The meeting should start with:
"Author: Has everyone read the code?
"  If there are any "No's" then dismiss the meeting and those people can read the code during the time allocated for the meeting.
"Author: Are there any major design, or module-level questions or comments?
"  This is the time to address major items like using the wrong tools, libraries, etc.
(Although in theory, those were caught during a design phase, but it can happen)
Now, go through the comments and questions.
Or go function-by-function if you can.
Maybe with "This function does X: Any comments or questions?
Next.  This function does Y..."

At this rate, you should be able to review weeks of code in an hour.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322697</id>
	<title>No doubt useful, but worth it...?</title>
	<author>Derekloffin</author>
	<datestamp>1244889960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I have no doubts at all that code reviews are highly useful.  They can discover coding errors that are insanely hard to discover other ways.  In anything that was critical, I would advocate them without the slightest hesitation.  However, since this about non-critical stuff, then it is far more questionable.  I think you should still use them, but on more limit basis.  There will always be the tasks that are highly technical internally that need a good thorough looking through the code as well as UI test, but generally it becomes much less useful in more simplistic tasks, and UI testing will quite often (still not always, but most often) reveal the same errors.  A good random inspection might be a decent replacement under these circumstances.</htmltext>
<tokenext>I have no doubts at all that code reviews are highly useful .
They can discover coding errors that are insanely hard to discover other ways .
In anything that was critical , I would advocate them without the slightest hesitation .
However , since this about non-critical stuff , then it is far more questionable .
I think you should still use them , but on more limit basis .
There will always be the tasks that are highly technical internally that need a good thorough looking through the code as well as UI test , but generally it becomes much less useful in more simplistic tasks , and UI testing will quite often ( still not always , but most often ) reveal the same errors .
A good random inspection might be a decent replacement under these circumstances .</tokentext>
<sentencetext>I have no doubts at all that code reviews are highly useful.
They can discover coding errors that are insanely hard to discover other ways.
In anything that was critical, I would advocate them without the slightest hesitation.
However, since this about non-critical stuff, then it is far more questionable.
I think you should still use them, but on more limit basis.
There will always be the tasks that are highly technical internally that need a good thorough looking through the code as well as UI test, but generally it becomes much less useful in more simplistic tasks, and UI testing will quite often (still not always, but most often) reveal the same errors.
A good random inspection might be a decent replacement under these circumstances.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322613</id>
	<title>U R DOIN IT WRONG :)</title>
	<author>RealTime</author>
	<datestamp>1244889420000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p><div class="quote"><p>What we've found is that code reviews take forever...</p></div><p>
Ugh.  Are you reviewing each individual commit (where code reviews are quick and very effective), or are you rounding up a bunch of developers in a conference room and reviewing an entire module using an overhead projector?
<br> <br>
Peer-to-peer reviews of individual diffs using good workflow tools have been <em>very</em> effective at several places I have worked and in open-source projects to which I have committed.
<br> <br>
Some of the fastest team development velocity I have experienced has been with peer code reviews within the team.
<br> <br>
A good style guide also helps...</p></div>
	</htmltext>
<tokenext>What we 've found is that code reviews take forever.. . Ugh. Are you reviewing each individual commit ( where code reviews are quick and very effective ) , or are you rounding up a bunch of developers in a conference room and reviewing an entire module using an overhead projector ?
Peer-to-peer reviews of individual diffs using good workflow tools have been very effective at several places I have worked and in open-source projects to which I have committed .
Some of the fastest team development velocity I have experienced has been with peer code reviews within the team .
A good style guide also helps.. .</tokentext>
<sentencetext>What we've found is that code reviews take forever...
Ugh.  Are you reviewing each individual commit (where code reviews are quick and very effective), or are you rounding up a bunch of developers in a conference room and reviewing an entire module using an overhead projector?
Peer-to-peer reviews of individual diffs using good workflow tools have been very effective at several places I have worked and in open-source projects to which I have committed.
Some of the fastest team development velocity I have experienced has been with peer code reviews within the team.
A good style guide also helps...
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323235</id>
	<title>Hidden cost to not doing them.</title>
	<author>Improv</author>
	<datestamp>1244895600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's not entirely about what they reveal once they've been established as good practice - there is also the fact that knowing that they will be done leads people to treat their code more carefully to begin with. In the deepest sense you'll never be able to compare what your code would be like if you did not have them - this is definitely not equivalent to what they turn up.</p></htmltext>
<tokenext>It 's not entirely about what they reveal once they 've been established as good practice - there is also the fact that knowing that they will be done leads people to treat their code more carefully to begin with .
In the deepest sense you 'll never be able to compare what your code would be like if you did not have them - this is definitely not equivalent to what they turn up .</tokentext>
<sentencetext>It's not entirely about what they reveal once they've been established as good practice - there is also the fact that knowing that they will be done leads people to treat their code more carefully to begin with.
In the deepest sense you'll never be able to compare what your code would be like if you did not have them - this is definitely not equivalent to what they turn up.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326417</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>Coz</author>
	<datestamp>1244992980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Amen.</p><p>One of the things that the metrics can hide, though, is the effect of institutionalizing reviews.  If you're on a long project with the same team, everyone begins to perform to a certain level and the code reviews seem to lose their importance.  It's ironic, it is.</p><p>If you have new folks join the team, though, it usually only takes a few code reviews for them to "get it" and figure out the level of expertise expected.</p><p>On my favorite project so far, we had full code reviews for the first phase, and dialed them back to "peer reviews" requiring only 2-3 folks to do online review of the code units.  Critical units were also reviewed by the lead developer and systems engineer responsible for that component.  It was very much worth it.</p></htmltext>
<tokenext>Amen.One of the things that the metrics can hide , though , is the effect of institutionalizing reviews .
If you 're on a long project with the same team , everyone begins to perform to a certain level and the code reviews seem to lose their importance .
It 's ironic , it is.If you have new folks join the team , though , it usually only takes a few code reviews for them to " get it " and figure out the level of expertise expected.On my favorite project so far , we had full code reviews for the first phase , and dialed them back to " peer reviews " requiring only 2-3 folks to do online review of the code units .
Critical units were also reviewed by the lead developer and systems engineer responsible for that component .
It was very much worth it .</tokentext>
<sentencetext>Amen.One of the things that the metrics can hide, though, is the effect of institutionalizing reviews.
If you're on a long project with the same team, everyone begins to perform to a certain level and the code reviews seem to lose their importance.
It's ironic, it is.If you have new folks join the team, though, it usually only takes a few code reviews for them to "get it" and figure out the level of expertise expected.On my favorite project so far, we had full code reviews for the first phase, and dialed them back to "peer reviews" requiring only 2-3 folks to do online review of the code units.
Critical units were also reviewed by the lead developer and systems engineer responsible for that component.
It was very much worth it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322623</id>
	<title>Line them up</title>
	<author>Anonymous</author>
	<datestamp>1244889480000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>Have each developer line up with his/her/its code printed out on a cue card board and stand in a line up.  Execute the least likely to make it to the compiler, then you will "motivate" the rest to write better code..</p></htmltext>
<tokenext>Have each developer line up with his/her/its code printed out on a cue card board and stand in a line up .
Execute the least likely to make it to the compiler , then you will " motivate " the rest to write better code. .</tokentext>
<sentencetext>Have each developer line up with his/her/its code printed out on a cue card board and stand in a line up.
Execute the least likely to make it to the compiler, then you will "motivate" the rest to write better code..</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322761</id>
	<title>Worth It But...</title>
	<author>EXTomar</author>
	<datestamp>1244890440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Code reviews are worth it but often the "cost" of doing proper reviews are underestimated.  To implement results of the review may cost a bit of time and money if not another review where if project managers and planners just assume its a "fast fix" then problems will arrise.</p></htmltext>
<tokenext>Code reviews are worth it but often the " cost " of doing proper reviews are underestimated .
To implement results of the review may cost a bit of time and money if not another review where if project managers and planners just assume its a " fast fix " then problems will arrise .</tokentext>
<sentencetext>Code reviews are worth it but often the "cost" of doing proper reviews are underestimated.
To implement results of the review may cost a bit of time and money if not another review where if project managers and planners just assume its a "fast fix" then problems will arrise.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322637</id>
	<title>Depends on what you're looking for</title>
	<author>ipoverscsi</author>
	<datestamp>1244889600000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p>Design reviews are useful to catch problems early on, particularly the selection of poor algorithms or data structures.  However, in the the software shops I've worked nobody does any documentation, which makes it particularly difficult to do a design review.  So, as you can imagine, I haven't got much experience with this area.</p><p>Code reviews, on the other hand, are more about auditing code to make sure that people are following the coding standards and policies.  After all, if you've got coding standards, how are you supposed to tell if anybody is following them without reviewing the code?  Once your coding standards have been institutionalized -- that is, most people have internalized them and following them -- then what's the point of a code review?</p><p>So your best bet, then, is to reserve code reviews for junior developers until the coding standards are internalized; and use design reviews for the architects.</p></htmltext>
<tokenext>Design reviews are useful to catch problems early on , particularly the selection of poor algorithms or data structures .
However , in the the software shops I 've worked nobody does any documentation , which makes it particularly difficult to do a design review .
So , as you can imagine , I have n't got much experience with this area.Code reviews , on the other hand , are more about auditing code to make sure that people are following the coding standards and policies .
After all , if you 've got coding standards , how are you supposed to tell if anybody is following them without reviewing the code ?
Once your coding standards have been institutionalized -- that is , most people have internalized them and following them -- then what 's the point of a code review ? So your best bet , then , is to reserve code reviews for junior developers until the coding standards are internalized ; and use design reviews for the architects .</tokentext>
<sentencetext>Design reviews are useful to catch problems early on, particularly the selection of poor algorithms or data structures.
However, in the the software shops I've worked nobody does any documentation, which makes it particularly difficult to do a design review.
So, as you can imagine, I haven't got much experience with this area.Code reviews, on the other hand, are more about auditing code to make sure that people are following the coding standards and policies.
After all, if you've got coding standards, how are you supposed to tell if anybody is following them without reviewing the code?
Once your coding standards have been institutionalized -- that is, most people have internalized them and following them -- then what's the point of a code review?So your best bet, then, is to reserve code reviews for junior developers until the coding standards are internalized; and use design reviews for the architects.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322729</id>
	<title>it always depends.</title>
	<author>tempest69</author>
	<datestamp>1244890140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Depends on the team, project and needs.<p>

If you have padawan coders, or coders from another corporation.. code reviews matter.. stylistically they wont mesh, they may have some foreign habits that you need to either squash or embrace.  These may be the people who do a C++ style for loop in perl when it is not appropriate.  These may be best-practices nazis.  These all warrant code review.</p><p>

If you are modifying byzantine code from the people who write HP office-jet software..  you need code review.</p><p>

If youre hooking up to an airplane or nuclear reactor.. you better know the answer.</p><p>

If you have grizzled coders who are stylistically homogenized, doing work that can have bugs... IE microsoft checkers (which allows you to change checkers in mid-double jump).. code review isnt so nessisary..</p><p>
Storm</p></htmltext>
<tokenext>Depends on the team , project and needs .
If you have padawan coders , or coders from another corporation.. code reviews matter.. stylistically they wont mesh , they may have some foreign habits that you need to either squash or embrace .
These may be the people who do a C + + style for loop in perl when it is not appropriate .
These may be best-practices nazis .
These all warrant code review .
If you are modifying byzantine code from the people who write HP office-jet software.. you need code review .
If youre hooking up to an airplane or nuclear reactor.. you better know the answer .
If you have grizzled coders who are stylistically homogenized , doing work that can have bugs... IE microsoft checkers ( which allows you to change checkers in mid-double jump ) .. code review isnt so nessisary. . Storm</tokentext>
<sentencetext>Depends on the team, project and needs.
If you have padawan coders, or coders from another corporation.. code reviews matter.. stylistically they wont mesh, they may have some foreign habits that you need to either squash or embrace.
These may be the people who do a C++ style for loop in perl when it is not appropriate.
These may be best-practices nazis.
These all warrant code review.
If you are modifying byzantine code from the people who write HP office-jet software..  you need code review.
If youre hooking up to an airplane or nuclear reactor.. you better know the answer.
If you have grizzled coders who are stylistically homogenized, doing work that can have bugs... IE microsoft checkers (which allows you to change checkers in mid-double jump).. code review isnt so nessisary..
Storm</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324989</id>
	<title>Depends on which stage of development you ask...</title>
	<author>freedom\_india</author>
	<datestamp>1244921460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It entirely depends on which stage of development you are.<br>If you are early in the cycle, and just building PoCs to validate architecture and design, then code reviews will be great in establishing basic discipline.<br>If you are late into development and want a code review to find out issues in design, then sorry, you are too late.<br>Code reviews establish base standards BEFORE the battle.<br>Like battle readiness inspection of troops.<br>It tells how you will code under fire.<br>But once the battle starts, you don't conduct inspections, because they are a waste of money and hell they do nothing.</p></htmltext>
<tokenext>It entirely depends on which stage of development you are.If you are early in the cycle , and just building PoCs to validate architecture and design , then code reviews will be great in establishing basic discipline.If you are late into development and want a code review to find out issues in design , then sorry , you are too late.Code reviews establish base standards BEFORE the battle.Like battle readiness inspection of troops.It tells how you will code under fire.But once the battle starts , you do n't conduct inspections , because they are a waste of money and hell they do nothing .</tokentext>
<sentencetext>It entirely depends on which stage of development you are.If you are early in the cycle, and just building PoCs to validate architecture and design, then code reviews will be great in establishing basic discipline.If you are late into development and want a code review to find out issues in design, then sorry, you are too late.Code reviews establish base standards BEFORE the battle.Like battle readiness inspection of troops.It tells how you will code under fire.But once the battle starts, you don't conduct inspections, because they are a waste of money and hell they do nothing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322799</id>
	<title>It's vital</title>
	<author>Comatose51</author>
	<datestamp>1244890920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>For a project that's more than one or two people, code reviews are vital.  They enforce consistency in style and methodology.  They also spread knowledge.  They mitigate the "bus factor" (how negatively impacted your project will be if someone is hit by a bus).  I've worked professionally at two companies.  One of them did not have code reviews.  Every time someone left the company, the project either grinds to a halt or they have to rewrite that person's work because no one else can understand it.  There were a ton of rewrites.  At my current company, we use Review Board (open source, built on Django) to do code reviews.  People don't leave often but they do transfer around the team to work on different sections.  That's rarely ever an issue because the code is understandable by all of us.  I work in both the UI and the middle layer with business logic and occasionally DB related code.  I can move between the three because the consistency that exists.  When I move into a new section, I do make mistakes but those mistakes are caught during code review and I learn.</htmltext>
<tokenext>For a project that 's more than one or two people , code reviews are vital .
They enforce consistency in style and methodology .
They also spread knowledge .
They mitigate the " bus factor " ( how negatively impacted your project will be if someone is hit by a bus ) .
I 've worked professionally at two companies .
One of them did not have code reviews .
Every time someone left the company , the project either grinds to a halt or they have to rewrite that person 's work because no one else can understand it .
There were a ton of rewrites .
At my current company , we use Review Board ( open source , built on Django ) to do code reviews .
People do n't leave often but they do transfer around the team to work on different sections .
That 's rarely ever an issue because the code is understandable by all of us .
I work in both the UI and the middle layer with business logic and occasionally DB related code .
I can move between the three because the consistency that exists .
When I move into a new section , I do make mistakes but those mistakes are caught during code review and I learn .</tokentext>
<sentencetext>For a project that's more than one or two people, code reviews are vital.
They enforce consistency in style and methodology.
They also spread knowledge.
They mitigate the "bus factor" (how negatively impacted your project will be if someone is hit by a bus).
I've worked professionally at two companies.
One of them did not have code reviews.
Every time someone left the company, the project either grinds to a halt or they have to rewrite that person's work because no one else can understand it.
There were a ton of rewrites.
At my current company, we use Review Board (open source, built on Django) to do code reviews.
People don't leave often but they do transfer around the team to work on different sections.
That's rarely ever an issue because the code is understandable by all of us.
I work in both the UI and the middle layer with business logic and occasionally DB related code.
I can move between the three because the consistency that exists.
When I move into a new section, I do make mistakes but those mistakes are caught during code review and I learn.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323641</id>
	<title>Re:If you're code review is taking forever...</title>
	<author>DoofusOfDeath</author>
	<datestamp>1244899800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Code reviews shouldn't be a "full stop, let's go over this" event. Code review should be a part of the every day workings of the development team. Nothing should go into version control's master/trunk/HEAD until it has been reviewed.</p></div> </blockquote><p>I don't think that's true.  Sometimes projects, especially new ones, are in phases where many ideas get tried out, partly to see how to best tackle a problem, and partly to tease out requirements.  When you have a small number of people working in that mode, and the trunk is <i>intended</i> to be a bit like the Wild West, code reviews can probably wait a while.</p></div>
	</htmltext>
<tokenext>Code reviews should n't be a " full stop , let 's go over this " event .
Code review should be a part of the every day workings of the development team .
Nothing should go into version control 's master/trunk/HEAD until it has been reviewed .
I do n't think that 's true .
Sometimes projects , especially new ones , are in phases where many ideas get tried out , partly to see how to best tackle a problem , and partly to tease out requirements .
When you have a small number of people working in that mode , and the trunk is intended to be a bit like the Wild West , code reviews can probably wait a while .</tokentext>
<sentencetext>Code reviews shouldn't be a "full stop, let's go over this" event.
Code review should be a part of the every day workings of the development team.
Nothing should go into version control's master/trunk/HEAD until it has been reviewed.
I don't think that's true.
Sometimes projects, especially new ones, are in phases where many ideas get tried out, partly to see how to best tackle a problem, and partly to tease out requirements.
When you have a small number of people working in that mode, and the trunk is intended to be a bit like the Wild West, code reviews can probably wait a while.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324577</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>DMeans</author>
	<datestamp>1244913540000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>I work for a very large software company, on a mission critical module used by very many companies.
- How much do reviews cost?  We don't care.
- How many defects are found?  Sometimes none.
- How much does it cost when a bug exists?  What you said.

Code reviews are mission critical to my team.  Software doesn't ship without them.
Sometimes the code review finds the bug, sometimes it doesn't.  But in the end, we have the check-box marked and it saves our bacon.</htmltext>
<tokenext>I work for a very large software company , on a mission critical module used by very many companies .
- How much do reviews cost ?
We do n't care .
- How many defects are found ?
Sometimes none .
- How much does it cost when a bug exists ?
What you said .
Code reviews are mission critical to my team .
Software does n't ship without them .
Sometimes the code review finds the bug , sometimes it does n't .
But in the end , we have the check-box marked and it saves our bacon .</tokentext>
<sentencetext>I work for a very large software company, on a mission critical module used by very many companies.
- How much do reviews cost?
We don't care.
- How many defects are found?
Sometimes none.
- How much does it cost when a bug exists?
What you said.
Code reviews are mission critical to my team.
Software doesn't ship without them.
Sometimes the code review finds the bug, sometimes it doesn't.
But in the end, we have the check-box marked and it saves our bacon.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</id>
	<title>a fucktonne?</title>
	<author>grahamsz</author>
	<datestamp>1244894280000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p>Damn europeans and their metric system.</p><p>How many shitloads are in a fucktonne?</p></htmltext>
<tokenext>Damn europeans and their metric system.How many shitloads are in a fucktonne ?</tokentext>
<sentencetext>Damn europeans and their metric system.How many shitloads are in a fucktonne?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323083</id>
	<title>They can be valuable</title>
	<author>realnrh</author>
	<datestamp>1244893920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It depends entirely on what your purpose for them is. You should have a good test suite that passes, good coverage, and have done some over-the-shoulder checks. Then the formal code review can be less about "Let's find bugs" as it is a style check and a chance for everyone else (who might get called upon to support the system later) to understand the general purpose, operation, and any clever bits. If your code review is supposed to be the bug hunt, then yeah, that's not efficient.</htmltext>
<tokenext>It depends entirely on what your purpose for them is .
You should have a good test suite that passes , good coverage , and have done some over-the-shoulder checks .
Then the formal code review can be less about " Let 's find bugs " as it is a style check and a chance for everyone else ( who might get called upon to support the system later ) to understand the general purpose , operation , and any clever bits .
If your code review is supposed to be the bug hunt , then yeah , that 's not efficient .</tokentext>
<sentencetext>It depends entirely on what your purpose for them is.
You should have a good test suite that passes, good coverage, and have done some over-the-shoulder checks.
Then the formal code review can be less about "Let's find bugs" as it is a style check and a chance for everyone else (who might get called upon to support the system later) to understand the general purpose, operation, and any clever bits.
If your code review is supposed to be the bug hunt, then yeah, that's not efficient.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28337515</id>
	<title>No Review</title>
	<author>Anonymous</author>
	<datestamp>1245090960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><br>Think of a place where there are no code reviews.
Where people hide there code and never learn from
each other.  Thats where I work...   I say do the
code reviews.</htmltext>
<tokenext>Think of a place where there are no code reviews .
Where people hide there code and never learn from each other .
Thats where I work... I say do the code reviews .</tokentext>
<sentencetext>Think of a place where there are no code reviews.
Where people hide there code and never learn from
each other.
Thats where I work...   I say do the
code reviews.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322863</id>
	<title>Figure out how much just one bug costs....</title>
	<author>Anonymous</author>
	<datestamp>1244891580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The simplest bug found post-ship is a helluva lot more than the most expensive code review you could ever have nightmares about.  So probably just every second or third code review (or maybe even less...) has to catch just <b>ONE</b> simple bug for all code reviews to be cost effective.  In other words, if two out of three code reviews are <b>totally</b> clean and the third finds just one bug, you're <b>AHEAD</b> in cost.  And we all know code reviews catch a helluva lot more than just one simple bug each.</p><p>Also, code reviews prevent programmers from deliberately writing obfuscated code.  FWIW, if you work for me and I catch you deliberately obfuscating code, you're on your way out.  Period.  It may take me a while, but you're gonna be <b>GONE</b> before long.</p></htmltext>
<tokenext>The simplest bug found post-ship is a helluva lot more than the most expensive code review you could ever have nightmares about .
So probably just every second or third code review ( or maybe even less... ) has to catch just ONE simple bug for all code reviews to be cost effective .
In other words , if two out of three code reviews are totally clean and the third finds just one bug , you 're AHEAD in cost .
And we all know code reviews catch a helluva lot more than just one simple bug each.Also , code reviews prevent programmers from deliberately writing obfuscated code .
FWIW , if you work for me and I catch you deliberately obfuscating code , you 're on your way out .
Period. It may take me a while , but you 're gon na be GONE before long .</tokentext>
<sentencetext>The simplest bug found post-ship is a helluva lot more than the most expensive code review you could ever have nightmares about.
So probably just every second or third code review (or maybe even less...) has to catch just ONE simple bug for all code reviews to be cost effective.
In other words, if two out of three code reviews are totally clean and the third finds just one bug, you're AHEAD in cost.
And we all know code reviews catch a helluva lot more than just one simple bug each.Also, code reviews prevent programmers from deliberately writing obfuscated code.
FWIW, if you work for me and I catch you deliberately obfuscating code, you're on your way out.
Period.  It may take me a while, but you're gonna be GONE before long.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322771</id>
	<title>Re:If you did test-driven development</title>
	<author>Nerdfest</author>
	<datestamp>1244890560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It is not redundant. You can use TDD and still have developers that write unmaintainable crap.</htmltext>
<tokenext>It is not redundant .
You can use TDD and still have developers that write unmaintainable crap .</tokentext>
<sentencetext>It is not redundant.
You can use TDD and still have developers that write unmaintainable crap.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322675</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327041</id>
	<title>Re:a fucktonne?</title>
	<author>jhd</author>
	<datestamp>1245000000000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>How many shitloads are in a fucktonne?</p></div><p>Wolfram Alpha knows<nobr> <wbr></nobr>;-)</p></div>
	</htmltext>
<tokenext>How many shitloads are in a fucktonne ? Wolfram Alpha knows ; - )</tokentext>
<sentencetext>How many shitloads are in a fucktonne?Wolfram Alpha knows ;-)
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325355</id>
	<title>old answer</title>
	<author>Anonymous</author>
	<datestamp>1244973180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>It's an old question, and there has been some academic research on the topic way back in 1980. Probably there has been predecessors and successors to this one. This study marks peer code review and dynamic simulation as the two most useful methods.</p><p>Take a look:  Benefit Analysis of Some Software Reliability Methodologies by Robert L. Glass, http://portal.acm.org/citation.cfm?id=1010797</p></htmltext>
<tokenext>It 's an old question , and there has been some academic research on the topic way back in 1980 .
Probably there has been predecessors and successors to this one .
This study marks peer code review and dynamic simulation as the two most useful methods.Take a look : Benefit Analysis of Some Software Reliability Methodologies by Robert L. Glass , http : //portal.acm.org/citation.cfm ? id = 1010797</tokentext>
<sentencetext>It's an old question, and there has been some academic research on the topic way back in 1980.
Probably there has been predecessors and successors to this one.
This study marks peer code review and dynamic simulation as the two most useful methods.Take a look:  Benefit Analysis of Some Software Reliability Methodologies by Robert L. Glass, http://portal.acm.org/citation.cfm?id=1010797</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323199</id>
	<title>Dijkstra's troll</title>
	<author>Anonymous</author>
	<datestamp>1244895180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>The purpose of the few coding reviews I have assisted was only to improve code metrics in order to avoid:<br>- too much nesting<br>- too long procedure or files<br>- languages syntaxes that are rarely the best one (operator ?, struct in C++,<nobr> <wbr></nobr>...)<br>The modified code has far better metrics, but has exactly the same number of bugs and is less readable because of the late cueless refactoring.</p><p>I hate the article of Dijkstra about the Goto, because of these practices that degenerated from it.<br>Computer programing should be an art form like poetry and music (D. Knuth) and shall not be restricted to a subset. It is as stupid as refusing alterations in music or avoiding rare words in books.</p></htmltext>
<tokenext>The purpose of the few coding reviews I have assisted was only to improve code metrics in order to avoid : - too much nesting- too long procedure or files- languages syntaxes that are rarely the best one ( operator ? , struct in C + + , ... ) The modified code has far better metrics , but has exactly the same number of bugs and is less readable because of the late cueless refactoring.I hate the article of Dijkstra about the Goto , because of these practices that degenerated from it.Computer programing should be an art form like poetry and music ( D. Knuth ) and shall not be restricted to a subset .
It is as stupid as refusing alterations in music or avoiding rare words in books .</tokentext>
<sentencetext>The purpose of the few coding reviews I have assisted was only to improve code metrics in order to avoid:- too much nesting- too long procedure or files- languages syntaxes that are rarely the best one (operator ?, struct in C++, ...)The modified code has far better metrics, but has exactly the same number of bugs and is less readable because of the late cueless refactoring.I hate the article of Dijkstra about the Goto, because of these practices that degenerated from it.Computer programing should be an art form like poetry and music (D. Knuth) and shall not be restricted to a subset.
It is as stupid as refusing alterations in music or avoiding rare words in books.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322739</id>
	<title>Re:Are they worth it?</title>
	<author>Anonymous</author>
	<datestamp>1244890200000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>
I did a code review once at a previous job.  It consisted of a bunch of people saying it looked good and one person giving wrong advice.  I later found a bug in the code that everyone had missed.  One person did comment afterwards that he learned a new trick reading my code.
</p><p>
I think a code review at hire time, as part of the interview process, might be good... hell mandatory.  I certainly wouldn't have hired the other developers in my group given the quality of code they produce (they were  hired before me by someone who wasn't particularly competent himself)</p></htmltext>
<tokenext>I did a code review once at a previous job .
It consisted of a bunch of people saying it looked good and one person giving wrong advice .
I later found a bug in the code that everyone had missed .
One person did comment afterwards that he learned a new trick reading my code .
I think a code review at hire time , as part of the interview process , might be good... hell mandatory .
I certainly would n't have hired the other developers in my group given the quality of code they produce ( they were hired before me by someone who was n't particularly competent himself )</tokentext>
<sentencetext>
I did a code review once at a previous job.
It consisted of a bunch of people saying it looked good and one person giving wrong advice.
I later found a bug in the code that everyone had missed.
One person did comment afterwards that he learned a new trick reading my code.
I think a code review at hire time, as part of the interview process, might be good... hell mandatory.
I certainly wouldn't have hired the other developers in my group given the quality of code they produce (they were  hired before me by someone who wasn't particularly competent himself)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326279</id>
	<title>Reviews work</title>
	<author>algoa456</author>
	<datestamp>1244991420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Code reviews work because when developers know their code is going to be scrutinized they improve their level of coding.

I've run developer shops for over 30 years and I've found that no matter what level the developer, if they are aware that their peers will review their code that take more care over it.

Will reviews make a poor developer a good developer? Of course not, but it will improve the quality, layout, documentation and general understanding that a developer has for the code he or she writes.  And as a bonus poor developers can get insights from good developers when they sit in on reviews.</htmltext>
<tokenext>Code reviews work because when developers know their code is going to be scrutinized they improve their level of coding .
I 've run developer shops for over 30 years and I 've found that no matter what level the developer , if they are aware that their peers will review their code that take more care over it .
Will reviews make a poor developer a good developer ?
Of course not , but it will improve the quality , layout , documentation and general understanding that a developer has for the code he or she writes .
And as a bonus poor developers can get insights from good developers when they sit in on reviews .</tokentext>
<sentencetext>Code reviews work because when developers know their code is going to be scrutinized they improve their level of coding.
I've run developer shops for over 30 years and I've found that no matter what level the developer, if they are aware that their peers will review their code that take more care over it.
Will reviews make a poor developer a good developer?
Of course not, but it will improve the quality, layout, documentation and general understanding that a developer has for the code he or she writes.
And as a bonus poor developers can get insights from good developers when they sit in on reviews.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323129</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>Anonymous</author>
	<datestamp>1244894460000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>I can say in our company the benefits are multi-fold.</p><p>Programmers skill levels vary.  And also vary by subject.  If you are going to allow someone to code the multi-threaded part of your project how do you insure that they've protected the write code the write way - which thread synchronization element did they use where?   Also remember the uproar about the code SGI put into Linux that SCO was bantering about.  I believe it was simple memory allocation.  Stuff that already existed elsewhere - duplicated uselessly.  Does everyone on your team know how to optimize C++ STL?</p><p>Then there is maintainability.  Lets forget outsourcing for a moment.  I'm currently rewriting a large chunk of code - written in C#.  If you think Java had a tough time in the early years because of junk 'web' programmers, you haven't seen anything yet.  Everyone and their mother thinks they can code in C#.  In my case the implications of using events, poor locking strategy etc. gave me the opportunity of 7x performance increase.  Yes, 700\%.  Apparently waiting for the GUI to update isn't good for a background thread.  They did things like send data across a network, start a thread to wait for response, then send an event to tell another thread that data had arrived.  From a design review I'm sure it looked OK.   "Hey we are doing asynch communication!!!!"</p><p>I know I hate it, but what about variable names.    Who checks if the comments make sense?</p><p>As the developers get better code reviews become less fruitful.  One of the issues I have now is that most sleep through the code review.  I don't mean literally, but I showed my code, everyone agreed it was good, only to have me go back to my desk and realize it would crash on one of the exception cases.  Hopefully testing would have caught it - we'll never know.</p><p>So... what we do for code review is a 1 on 1 session.  It is the developers job to convince the mentor that he, the developer, is doing the job right.  It is then the mentor who makes the final submission (he buys the donuts if the build breaks<nobr> <wbr></nobr>:) )  The idea is to keep from rubber stamping.</p><p>So defect catching is one part.  Performance another, and  maintainability yet another.</p><p>BTW, before my changes to the code, everyone thought our competitors product was better/faster.  Now we are about 20-30\% ahead of them.  So what did that cost our customer base?</p><p>Of course now everyone in the company thinks I'm god (my head barely gets through the door as it is).  If only we did this code review before we shipped.</p></htmltext>
<tokenext>I can say in our company the benefits are multi-fold.Programmers skill levels vary .
And also vary by subject .
If you are going to allow someone to code the multi-threaded part of your project how do you insure that they 've protected the write code the write way - which thread synchronization element did they use where ?
Also remember the uproar about the code SGI put into Linux that SCO was bantering about .
I believe it was simple memory allocation .
Stuff that already existed elsewhere - duplicated uselessly .
Does everyone on your team know how to optimize C + + STL ? Then there is maintainability .
Lets forget outsourcing for a moment .
I 'm currently rewriting a large chunk of code - written in C # .
If you think Java had a tough time in the early years because of junk 'web ' programmers , you have n't seen anything yet .
Everyone and their mother thinks they can code in C # .
In my case the implications of using events , poor locking strategy etc .
gave me the opportunity of 7x performance increase .
Yes , 700 \ % .
Apparently waiting for the GUI to update is n't good for a background thread .
They did things like send data across a network , start a thread to wait for response , then send an event to tell another thread that data had arrived .
From a design review I 'm sure it looked OK. " Hey we are doing asynch communication ! ! ! !
" I know I hate it , but what about variable names .
Who checks if the comments make sense ? As the developers get better code reviews become less fruitful .
One of the issues I have now is that most sleep through the code review .
I do n't mean literally , but I showed my code , everyone agreed it was good , only to have me go back to my desk and realize it would crash on one of the exception cases .
Hopefully testing would have caught it - we 'll never know.So... what we do for code review is a 1 on 1 session .
It is the developers job to convince the mentor that he , the developer , is doing the job right .
It is then the mentor who makes the final submission ( he buys the donuts if the build breaks : ) ) The idea is to keep from rubber stamping.So defect catching is one part .
Performance another , and maintainability yet another.BTW , before my changes to the code , everyone thought our competitors product was better/faster .
Now we are about 20-30 \ % ahead of them .
So what did that cost our customer base ? Of course now everyone in the company thinks I 'm god ( my head barely gets through the door as it is ) .
If only we did this code review before we shipped .</tokentext>
<sentencetext>I can say in our company the benefits are multi-fold.Programmers skill levels vary.
And also vary by subject.
If you are going to allow someone to code the multi-threaded part of your project how do you insure that they've protected the write code the write way - which thread synchronization element did they use where?
Also remember the uproar about the code SGI put into Linux that SCO was bantering about.
I believe it was simple memory allocation.
Stuff that already existed elsewhere - duplicated uselessly.
Does everyone on your team know how to optimize C++ STL?Then there is maintainability.
Lets forget outsourcing for a moment.
I'm currently rewriting a large chunk of code - written in C#.
If you think Java had a tough time in the early years because of junk 'web' programmers, you haven't seen anything yet.
Everyone and their mother thinks they can code in C#.
In my case the implications of using events, poor locking strategy etc.
gave me the opportunity of 7x performance increase.
Yes, 700\%.
Apparently waiting for the GUI to update isn't good for a background thread.
They did things like send data across a network, start a thread to wait for response, then send an event to tell another thread that data had arrived.
From a design review I'm sure it looked OK.   "Hey we are doing asynch communication!!!!
"I know I hate it, but what about variable names.
Who checks if the comments make sense?As the developers get better code reviews become less fruitful.
One of the issues I have now is that most sleep through the code review.
I don't mean literally, but I showed my code, everyone agreed it was good, only to have me go back to my desk and realize it would crash on one of the exception cases.
Hopefully testing would have caught it - we'll never know.So... what we do for code review is a 1 on 1 session.
It is the developers job to convince the mentor that he, the developer, is doing the job right.
It is then the mentor who makes the final submission (he buys the donuts if the build breaks :) )  The idea is to keep from rubber stamping.So defect catching is one part.
Performance another, and  maintainability yet another.BTW, before my changes to the code, everyone thought our competitors product was better/faster.
Now we are about 20-30\% ahead of them.
So what did that cost our customer base?Of course now everyone in the company thinks I'm god (my head barely gets through the door as it is).
If only we did this code review before we shipped.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324059</id>
	<title>Our Experience</title>
	<author>Javagator</author>
	<datestamp>1244905200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
I have always heard great things about code reviews.  However, our company recently began a policy of formal code reviews and they have not lived up to my expectations.  We rarely find any real bugs or serious design flaws.  We find things like minor coding standard violations, or "you should move this statement here to make things clearer".  While these findings may help improve the code, I don't think that they justify the time spent in review.  And these reviews are turning out to be very time consuming, not to mention one of the most boring things I have ever done at work.  This group of developers is one of the most talented and experienced groups that I have worked with.  One would think that if code reviews would work for anyone, they would work for us.
</p><p>
Incidentally, we do keep statistics on defects.  Unfortunately, the minor improvements we find make it seem like we are finding a reasonable number of defects.
</p></htmltext>
<tokenext>I have always heard great things about code reviews .
However , our company recently began a policy of formal code reviews and they have not lived up to my expectations .
We rarely find any real bugs or serious design flaws .
We find things like minor coding standard violations , or " you should move this statement here to make things clearer " .
While these findings may help improve the code , I do n't think that they justify the time spent in review .
And these reviews are turning out to be very time consuming , not to mention one of the most boring things I have ever done at work .
This group of developers is one of the most talented and experienced groups that I have worked with .
One would think that if code reviews would work for anyone , they would work for us .
Incidentally , we do keep statistics on defects .
Unfortunately , the minor improvements we find make it seem like we are finding a reasonable number of defects .</tokentext>
<sentencetext>
I have always heard great things about code reviews.
However, our company recently began a policy of formal code reviews and they have not lived up to my expectations.
We rarely find any real bugs or serious design flaws.
We find things like minor coding standard violations, or "you should move this statement here to make things clearer".
While these findings may help improve the code, I don't think that they justify the time spent in review.
And these reviews are turning out to be very time consuming, not to mention one of the most boring things I have ever done at work.
This group of developers is one of the most talented and experienced groups that I have worked with.
One would think that if code reviews would work for anyone, they would work for us.
Incidentally, we do keep statistics on defects.
Unfortunately, the minor improvements we find make it seem like we are finding a reasonable number of defects.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28339003</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>DigitalCrackPipe</author>
	<datestamp>1245097080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I agree - my first thought was that the reviews are being done wrong - perhaps focusing on the wrong things, inviting the wrong people, or just plain not having someone in charge to keep things flowing.
<br> <br>
My next thought is that the results of design reviews are going to be viewed differently - changing the color of a button is likely to be more noticable than fixing a buffer overflow that is only exhibited if the right data is input.
<br> <br>
My personal experience is that code reviews are invaluable when done right.  However, a huge number of people don't understand them at all and try to do them wrong.</htmltext>
<tokenext>I agree - my first thought was that the reviews are being done wrong - perhaps focusing on the wrong things , inviting the wrong people , or just plain not having someone in charge to keep things flowing .
My next thought is that the results of design reviews are going to be viewed differently - changing the color of a button is likely to be more noticable than fixing a buffer overflow that is only exhibited if the right data is input .
My personal experience is that code reviews are invaluable when done right .
However , a huge number of people do n't understand them at all and try to do them wrong .</tokentext>
<sentencetext>I agree - my first thought was that the reviews are being done wrong - perhaps focusing on the wrong things, inviting the wrong people, or just plain not having someone in charge to keep things flowing.
My next thought is that the results of design reviews are going to be viewed differently - changing the color of a button is likely to be more noticable than fixing a buffer overflow that is only exhibited if the right data is input.
My personal experience is that code reviews are invaluable when done right.
However, a huge number of people don't understand them at all and try to do them wrong.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327839</id>
	<title>Depends on who the reviewer is</title>
	<author>caywen</author>
	<datestamp>1245007740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Ideally, the reviewer will understand the context of the code and the context of the review. Reviews should only be conducted by 2 engineers who both have a deep sense of what level is appropriate.

I hate ending up with some ass who thinks every piece of code controls life and death, and happens to also think your variable naming is also going to kill people, too.</htmltext>
<tokenext>Ideally , the reviewer will understand the context of the code and the context of the review .
Reviews should only be conducted by 2 engineers who both have a deep sense of what level is appropriate .
I hate ending up with some ass who thinks every piece of code controls life and death , and happens to also think your variable naming is also going to kill people , too .</tokentext>
<sentencetext>Ideally, the reviewer will understand the context of the code and the context of the review.
Reviews should only be conducted by 2 engineers who both have a deep sense of what level is appropriate.
I hate ending up with some ass who thinks every piece of code controls life and death, and happens to also think your variable naming is also going to kill people, too.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323355</id>
	<title>As you say...</title>
	<author>nicoleb\_x</author>
	<datestamp>1244896800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>As you say, they have no value in your environment. OK, maybe your team can't do reviews, maybe there is no point as the code is just a bunch of UI junk that changes constantly. It's no big deal. Not every team uses every software development technique, nor should they. I happen to write lots of code as a team of one. I'd like to get others to look at the code but that isn't going to happen, so no code reviews. I still get paid, applications work, customers are happy...it can be done.</htmltext>
<tokenext>As you say , they have no value in your environment .
OK , maybe your team ca n't do reviews , maybe there is no point as the code is just a bunch of UI junk that changes constantly .
It 's no big deal .
Not every team uses every software development technique , nor should they .
I happen to write lots of code as a team of one .
I 'd like to get others to look at the code but that is n't going to happen , so no code reviews .
I still get paid , applications work , customers are happy...it can be done .</tokentext>
<sentencetext>As you say, they have no value in your environment.
OK, maybe your team can't do reviews, maybe there is no point as the code is just a bunch of UI junk that changes constantly.
It's no big deal.
Not every team uses every software development technique, nor should they.
I happen to write lots of code as a team of one.
I'd like to get others to look at the code but that isn't going to happen, so no code reviews.
I still get paid, applications work, customers are happy...it can be done.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325533</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>Carewolf</author>
	<datestamp>1244977200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Well, code reviews are boring to do, but has to be done be the best and most experienced developers usually the senior or lead developer. Some places doesn't understand that and just delegates this menial task to lower developers, or a team of inexperienced developers. Other places the top developer assigned the task, just skips through the code, because he thinks he has "better things to do".</p></htmltext>
<tokenext>Well , code reviews are boring to do , but has to be done be the best and most experienced developers usually the senior or lead developer .
Some places does n't understand that and just delegates this menial task to lower developers , or a team of inexperienced developers .
Other places the top developer assigned the task , just skips through the code , because he thinks he has " better things to do " .</tokentext>
<sentencetext>Well, code reviews are boring to do, but has to be done be the best and most experienced developers usually the senior or lead developer.
Some places doesn't understand that and just delegates this menial task to lower developers, or a team of inexperienced developers.
Other places the top developer assigned the task, just skips through the code, because he thinks he has "better things to do".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322625</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323261</id>
	<title>WTF does maybe mean?</title>
	<author>Anonymous</author>
	<datestamp>1244895900000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext>Are code reviews useful?
<br>
Lets see. Right click -&gt; View source this web page. In the first 10 lines I see a variable called <b>maybe</b> with no comments as to what it means.
<br>
Yes, code reviews are useful.</htmltext>
<tokenext>Are code reviews useful ?
Lets see .
Right click - &gt; View source this web page .
In the first 10 lines I see a variable called maybe with no comments as to what it means .
Yes , code reviews are useful .</tokentext>
<sentencetext>Are code reviews useful?
Lets see.
Right click -&gt; View source this web page.
In the first 10 lines I see a variable called maybe with no comments as to what it means.
Yes, code reviews are useful.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28336155</id>
	<title>Re:a fucktonne?</title>
	<author>fatboy</author>
	<datestamp>1245084960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Depends on if we are talking about imperial shitloads or not.</p></htmltext>
<tokenext>Depends on if we are talking about imperial shitloads or not .</tokentext>
<sentencetext>Depends on if we are talking about imperial shitloads or not.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325859</id>
	<title>Control</title>
	<author>DaveGod</author>
	<datestamp>1244985600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Coming at this from a general control perspective, controls operate at both detection and prevention. The code reviews may not be detecting many problems, but their existence may have an impact anyway. If nobody is reviewing code at all, would people approach their task differently? What would anyone know about the software quality other than "it works"? The process may also be valuable to management for other reasons. What does anyone know about the programmer's level of skill? Is the code documented for maintenance? </p></htmltext>
<tokenext>Coming at this from a general control perspective , controls operate at both detection and prevention .
The code reviews may not be detecting many problems , but their existence may have an impact anyway .
If nobody is reviewing code at all , would people approach their task differently ?
What would anyone know about the software quality other than " it works " ?
The process may also be valuable to management for other reasons .
What does anyone know about the programmer 's level of skill ?
Is the code documented for maintenance ?</tokentext>
<sentencetext>Coming at this from a general control perspective, controls operate at both detection and prevention.
The code reviews may not be detecting many problems, but their existence may have an impact anyway.
If nobody is reviewing code at all, would people approach their task differently?
What would anyone know about the software quality other than "it works"?
The process may also be valuable to management for other reasons.
What does anyone know about the programmer's level of skill?
Is the code documented for maintenance? </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323963</id>
	<title>You may not be doing them right</title>
	<author>crmartin</author>
	<datestamp>1244903760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Honestly, code reviews, historically, have proven to be about ten times as cost effective as other techniques.  If you're not seeing good effects from them, the odds are that you aren't doing them right.</p><p>Not that this is a big surprise, as few people do them well.</p><p>Get hold of some of the literature on Fagin reviews, and make sure you're following the guidelines:</p><p>(1) not too many people in the review: 3 minimum, 7 maximum.<br>(2) the programmer isn't allowed to speak, except potentially to explain something<br>(3) no one can suggest solutions: identify a potential problem and move on<br>(4) close the loop: make sure all solutions get documented and passed to review participants.<br>(5) a single review can last no longer than 1 hour.</p></htmltext>
<tokenext>Honestly , code reviews , historically , have proven to be about ten times as cost effective as other techniques .
If you 're not seeing good effects from them , the odds are that you are n't doing them right.Not that this is a big surprise , as few people do them well.Get hold of some of the literature on Fagin reviews , and make sure you 're following the guidelines : ( 1 ) not too many people in the review : 3 minimum , 7 maximum .
( 2 ) the programmer is n't allowed to speak , except potentially to explain something ( 3 ) no one can suggest solutions : identify a potential problem and move on ( 4 ) close the loop : make sure all solutions get documented and passed to review participants .
( 5 ) a single review can last no longer than 1 hour .</tokentext>
<sentencetext>Honestly, code reviews, historically, have proven to be about ten times as cost effective as other techniques.
If you're not seeing good effects from them, the odds are that you aren't doing them right.Not that this is a big surprise, as few people do them well.Get hold of some of the literature on Fagin reviews, and make sure you're following the guidelines:(1) not too many people in the review: 3 minimum, 7 maximum.
(2) the programmer isn't allowed to speak, except potentially to explain something(3) no one can suggest solutions: identify a potential problem and move on(4) close the loop: make sure all solutions get documented and passed to review participants.
(5) a single review can last no longer than 1 hour.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28333385</id>
	<title>Coding standards</title>
	<author>Anonymous</author>
	<datestamp>1245066240000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Having standards for coders and requiring compliance from ALL will speed things up a bit<nobr> <wbr></nobr>... it helps prevent the "coding style" harping from taking valuable time.</p><p>Our code reviews also take in account compiler efficiency/deficiency knowledge<nobr> <wbr></nobr>... this can help free up a lot of time (from later optimization efforts and repeat debugging of compiler issues) and help teach newer coders about such things.</p></htmltext>
<tokenext>Having standards for coders and requiring compliance from ALL will speed things up a bit ... it helps prevent the " coding style " harping from taking valuable time.Our code reviews also take in account compiler efficiency/deficiency knowledge ... this can help free up a lot of time ( from later optimization efforts and repeat debugging of compiler issues ) and help teach newer coders about such things .</tokentext>
<sentencetext>Having standards for coders and requiring compliance from ALL will speed things up a bit ... it helps prevent the "coding style" harping from taking valuable time.Our code reviews also take in account compiler efficiency/deficiency knowledge ... this can help free up a lot of time (from later optimization efforts and repeat debugging of compiler issues) and help teach newer coders about such things.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835</id>
	<title>Delusions of grandeur</title>
	<author>Anonymous</author>
	<datestamp>1244891280000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>My working life has been spent in projects developed by individuals or small teams (less than six programmers). I would describe my working environments as "CMM level 1 and damn proud of it." The teams I have been on have been consistently successful without having a consistent methodology. The success is the result of having a bunch of competent people who respect each other, and are motivated by the idea of producing something that customers will pay money for, because it works. And by the knowledge that they'll stick with the project for a while, and if they make any messes they'll be the same people who have to clean them up later.</p><p>I've suffered throughout my working life from inexperienced managers and programmers who suffer from what I call delusions of grandeur. 90\% of the stuff that people learn about project management seems to me to be intended for use in projects with fifty programmers or more. Projects where the manager can't get a grasp of the project by walking around and schmoozing with people. Projects that are big enough that there are constantly people leaving and joining them. I don't know about projects like that. I'm inclined to think that formal management processes may be useful, even essential there.</p><p>But on small-team projects, it just gets in the way.</p><p>The problem is that the books that explain the capital-M Methodologies and the code review process and so forth never say, in so many words, that these are management procedures for projects with more than fifty people. They just say, "this is how you do it." And people come out of courses believing that "doing it right" means applying all this stuff. And that anything else is unprofessional.</p><p>The hidden assumption is that everyone wants to follow a career path where they manage more and more and more people on bigger and bigger and bigger projects and make more and more and more money. When I worked at a Fortune 500 company, people were very frank about it. It was a waste of time proposing or working on small stuff. You had to "think big" or management would never take any interest in what you were doing.</p><p>Well, I'm here to say that if you want to think big and manage like the big boys do, fine. But don't try it on a small-team project where the team members have gelled into a coherent unit, and know each other and work well together, and plan to stick around for a while.</p><p>Code reviews? Gimme a break. In the natural course of events, other team members are going to have to work with my code. If I don't care about what they think about it \_when they're editing it to get their job done,\_ I'm sure not going to care what they think about it in some room with a whiteboard. And we're effectively eviewing each others' code in the natural course of getting our jobs done, then sealing ourselves into a room with a whiteboard and no debugger, isn't going to be any better than what we naturally do without any formal process.</p></htmltext>
<tokenext>My working life has been spent in projects developed by individuals or small teams ( less than six programmers ) .
I would describe my working environments as " CMM level 1 and damn proud of it .
" The teams I have been on have been consistently successful without having a consistent methodology .
The success is the result of having a bunch of competent people who respect each other , and are motivated by the idea of producing something that customers will pay money for , because it works .
And by the knowledge that they 'll stick with the project for a while , and if they make any messes they 'll be the same people who have to clean them up later.I 've suffered throughout my working life from inexperienced managers and programmers who suffer from what I call delusions of grandeur .
90 \ % of the stuff that people learn about project management seems to me to be intended for use in projects with fifty programmers or more .
Projects where the manager ca n't get a grasp of the project by walking around and schmoozing with people .
Projects that are big enough that there are constantly people leaving and joining them .
I do n't know about projects like that .
I 'm inclined to think that formal management processes may be useful , even essential there.But on small-team projects , it just gets in the way.The problem is that the books that explain the capital-M Methodologies and the code review process and so forth never say , in so many words , that these are management procedures for projects with more than fifty people .
They just say , " this is how you do it .
" And people come out of courses believing that " doing it right " means applying all this stuff .
And that anything else is unprofessional.The hidden assumption is that everyone wants to follow a career path where they manage more and more and more people on bigger and bigger and bigger projects and make more and more and more money .
When I worked at a Fortune 500 company , people were very frank about it .
It was a waste of time proposing or working on small stuff .
You had to " think big " or management would never take any interest in what you were doing.Well , I 'm here to say that if you want to think big and manage like the big boys do , fine .
But do n't try it on a small-team project where the team members have gelled into a coherent unit , and know each other and work well together , and plan to stick around for a while.Code reviews ?
Gim me a break .
In the natural course of events , other team members are going to have to work with my code .
If I do n't care about what they think about it \ _when they 're editing it to get their job done , \ _ I 'm sure not going to care what they think about it in some room with a whiteboard .
And we 're effectively eviewing each others ' code in the natural course of getting our jobs done , then sealing ourselves into a room with a whiteboard and no debugger , is n't going to be any better than what we naturally do without any formal process .</tokentext>
<sentencetext>My working life has been spent in projects developed by individuals or small teams (less than six programmers).
I would describe my working environments as "CMM level 1 and damn proud of it.
" The teams I have been on have been consistently successful without having a consistent methodology.
The success is the result of having a bunch of competent people who respect each other, and are motivated by the idea of producing something that customers will pay money for, because it works.
And by the knowledge that they'll stick with the project for a while, and if they make any messes they'll be the same people who have to clean them up later.I've suffered throughout my working life from inexperienced managers and programmers who suffer from what I call delusions of grandeur.
90\% of the stuff that people learn about project management seems to me to be intended for use in projects with fifty programmers or more.
Projects where the manager can't get a grasp of the project by walking around and schmoozing with people.
Projects that are big enough that there are constantly people leaving and joining them.
I don't know about projects like that.
I'm inclined to think that formal management processes may be useful, even essential there.But on small-team projects, it just gets in the way.The problem is that the books that explain the capital-M Methodologies and the code review process and so forth never say, in so many words, that these are management procedures for projects with more than fifty people.
They just say, "this is how you do it.
" And people come out of courses believing that "doing it right" means applying all this stuff.
And that anything else is unprofessional.The hidden assumption is that everyone wants to follow a career path where they manage more and more and more people on bigger and bigger and bigger projects and make more and more and more money.
When I worked at a Fortune 500 company, people were very frank about it.
It was a waste of time proposing or working on small stuff.
You had to "think big" or management would never take any interest in what you were doing.Well, I'm here to say that if you want to think big and manage like the big boys do, fine.
But don't try it on a small-team project where the team members have gelled into a coherent unit, and know each other and work well together, and plan to stick around for a while.Code reviews?
Gimme a break.
In the natural course of events, other team members are going to have to work with my code.
If I don't care about what they think about it \_when they're editing it to get their job done,\_ I'm sure not going to care what they think about it in some room with a whiteboard.
And we're effectively eviewing each others' code in the natural course of getting our jobs done, then sealing ourselves into a room with a whiteboard and no debugger, isn't going to be any better than what we naturally do without any formal process.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322743</id>
	<title>Coding standards</title>
	<author>readin</author>
	<datestamp>1244890260000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>The value of the code review depends on several factors, the most important being the coding standard against which the code is being reviewed.  If the coding standard has a lot of hard and fast rules about what goes into the comment block, where variables should be declared, whether brackets go at the end of a line or on their own line, and how many returns a method can have, then the code review will be mostly about religious issues and petty formatting.  On the other hand, a coding standard with many "should"s instead of "shall"s that allow the developer, combined with reviewers and especially review moderators who know what is important can what isn't, can make code reviews very useful, especially early in a project and especially with junior developers.
<br> <br>
A code review is unlikely to uncover many errors.  Most code is just too complex for another developer to spot errors. Unit testing is much better at that.  What a code review can do is
<ul>
<li>1. Coach new developers by helping them learn and/or remember best practices:  "Please use "literal".equals(variable) rather than variable.equals("literal"), just in case the variable is null." </li><li>2. Remind people to follow the important standards, or recognize that you're missing important standards and need to set one:  If your DAO "find" method doesn't find the expected record, do you return null or do you throw an exception?  Both have strengths, but everyone on the projct should be doing it the same way.  Code reviews will help uncover discrepancies.</li><li>3. Uncover future maintenance issues.  The code may be too complex for reviewers to find bugs during the review, but they should at least be able to follow what the code is doing.  If they can't, the code either needs restructuring or better commenting.</li></ul></htmltext>
<tokenext>The value of the code review depends on several factors , the most important being the coding standard against which the code is being reviewed .
If the coding standard has a lot of hard and fast rules about what goes into the comment block , where variables should be declared , whether brackets go at the end of a line or on their own line , and how many returns a method can have , then the code review will be mostly about religious issues and petty formatting .
On the other hand , a coding standard with many " should " s instead of " shall " s that allow the developer , combined with reviewers and especially review moderators who know what is important can what is n't , can make code reviews very useful , especially early in a project and especially with junior developers .
A code review is unlikely to uncover many errors .
Most code is just too complex for another developer to spot errors .
Unit testing is much better at that .
What a code review can do is 1 .
Coach new developers by helping them learn and/or remember best practices : " Please use " literal " .equals ( variable ) rather than variable.equals ( " literal " ) , just in case the variable is null .
" 2 .
Remind people to follow the important standards , or recognize that you 're missing important standards and need to set one : If your DAO " find " method does n't find the expected record , do you return null or do you throw an exception ?
Both have strengths , but everyone on the projct should be doing it the same way .
Code reviews will help uncover discrepancies.3 .
Uncover future maintenance issues .
The code may be too complex for reviewers to find bugs during the review , but they should at least be able to follow what the code is doing .
If they ca n't , the code either needs restructuring or better commenting .</tokentext>
<sentencetext>The value of the code review depends on several factors, the most important being the coding standard against which the code is being reviewed.
If the coding standard has a lot of hard and fast rules about what goes into the comment block, where variables should be declared, whether brackets go at the end of a line or on their own line, and how many returns a method can have, then the code review will be mostly about religious issues and petty formatting.
On the other hand, a coding standard with many "should"s instead of "shall"s that allow the developer, combined with reviewers and especially review moderators who know what is important can what isn't, can make code reviews very useful, especially early in a project and especially with junior developers.
A code review is unlikely to uncover many errors.
Most code is just too complex for another developer to spot errors.
Unit testing is much better at that.
What a code review can do is

1.
Coach new developers by helping them learn and/or remember best practices:  "Please use "literal".equals(variable) rather than variable.equals("literal"), just in case the variable is null.
" 2.
Remind people to follow the important standards, or recognize that you're missing important standards and need to set one:  If your DAO "find" method doesn't find the expected record, do you return null or do you throw an exception?
Both have strengths, but everyone on the projct should be doing it the same way.
Code reviews will help uncover discrepancies.3.
Uncover future maintenance issues.
The code may be too complex for reviewers to find bugs during the review, but they should at least be able to follow what the code is doing.
If they can't, the code either needs restructuring or better commenting.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324521</id>
	<title>How not to do a code review</title>
	<author>kybred</author>
	<datestamp>1244912700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Here's some rules to insure your code reviews go badly:<p>
1) You want the meeting to be the first time you've looked at the code. That way you can ask a lot of questions that could have been answered in two minutes of reading the code (and thus waste minutes of <i>everyone's</i> time).
</p><p>
2) Don't assign roles. That way everyone can look at the code from the same viewpoint.
</p><p>
3) Don't stay professional or objective. Ad hominem attacks always help in reviews.
</p><p>
4) Don't set a time limit. Everyone loves meetings that drag on and on.</p><p>
5) Be sure to review at least 5,000 lines of code in each review.</p></htmltext>
<tokenext>Here 's some rules to insure your code reviews go badly : 1 ) You want the meeting to be the first time you 've looked at the code .
That way you can ask a lot of questions that could have been answered in two minutes of reading the code ( and thus waste minutes of everyone 's time ) .
2 ) Do n't assign roles .
That way everyone can look at the code from the same viewpoint .
3 ) Do n't stay professional or objective .
Ad hominem attacks always help in reviews .
4 ) Do n't set a time limit .
Everyone loves meetings that drag on and on .
5 ) Be sure to review at least 5,000 lines of code in each review .</tokentext>
<sentencetext>Here's some rules to insure your code reviews go badly:
1) You want the meeting to be the first time you've looked at the code.
That way you can ask a lot of questions that could have been answered in two minutes of reading the code (and thus waste minutes of everyone's time).
2) Don't assign roles.
That way everyone can look at the code from the same viewpoint.
3) Don't stay professional or objective.
Ad hominem attacks always help in reviews.
4) Don't set a time limit.
Everyone loves meetings that drag on and on.
5) Be sure to review at least 5,000 lines of code in each review.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322605</id>
	<title>They sometimes find really difficult problems</title>
	<author>Anonymous</author>
	<datestamp>1244889360000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>When we did code reviews at DEC, they were done with several people generally familiar with the code, required considerable advance prep by the reviewers, and went over code basically line by line. This was not done for all code; nobody had time or resources. However, when a piece of code was doing something weird, it was a pretty effective way to figure out what might be wrong, where the programmer had been having trouble finding a problem. The one area where it tended not to work well was where the software was a driver that talked to some piece of hardware, and the programmer was the only one who really knew what the hardware was doing. The fact that the reviewers didn't know that hardware made finding bugs most difficult...</p></htmltext>
<tokenext>When we did code reviews at DEC , they were done with several people generally familiar with the code , required considerable advance prep by the reviewers , and went over code basically line by line .
This was not done for all code ; nobody had time or resources .
However , when a piece of code was doing something weird , it was a pretty effective way to figure out what might be wrong , where the programmer had been having trouble finding a problem .
The one area where it tended not to work well was where the software was a driver that talked to some piece of hardware , and the programmer was the only one who really knew what the hardware was doing .
The fact that the reviewers did n't know that hardware made finding bugs most difficult.. .</tokentext>
<sentencetext>When we did code reviews at DEC, they were done with several people generally familiar with the code, required considerable advance prep by the reviewers, and went over code basically line by line.
This was not done for all code; nobody had time or resources.
However, when a piece of code was doing something weird, it was a pretty effective way to figure out what might be wrong, where the programmer had been having trouble finding a problem.
The one area where it tended not to work well was where the software was a driver that talked to some piece of hardware, and the programmer was the only one who really knew what the hardware was doing.
The fact that the reviewers didn't know that hardware made finding bugs most difficult...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323623</id>
	<title>I think they can be good</title>
	<author>jonwil</author>
	<datestamp>1244899500000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>As a programmer, having someone else look at my code is good since there will always be mistakes I just cant see from looking at it. Someone else looking at it might pick them up when I cant, especially if they have more knowledge of bits of the codebase than I do.</p></htmltext>
<tokenext>As a programmer , having someone else look at my code is good since there will always be mistakes I just cant see from looking at it .
Someone else looking at it might pick them up when I cant , especially if they have more knowledge of bits of the codebase than I do .</tokentext>
<sentencetext>As a programmer, having someone else look at my code is good since there will always be mistakes I just cant see from looking at it.
Someone else looking at it might pick them up when I cant, especially if they have more knowledge of bits of the codebase than I do.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323747</id>
	<title>I want ALL my code reviewed...</title>
	<author>MadShark</author>
	<datestamp>1244901120000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>My company has a pretty rigid set of processes and we find that we catch approximately 25\% of our defects in code reviews.  This doesn't count minor things like not following the coding conventions or bad comments, those are logged separately.  We have reviews where we hand them off to just one other engineer as well as the Fagan style of reviews, depending on what we feel is appropriate for the particular piece of code.  In our industry(embedded software), it isn't exactly easy to push out a patch once the code is released so that plays into how/why we do it the way we do.  I wouldn't say the review process is cheap, but neither are warranty campaigns.  Pay it now or pay it later I guess...</p><p>Even the best people occasionally typo, put in a bad/wrong comment or just flat out make a mistake during coding.  Personally, I'd love it if we had the resources to review every single line of code I write.</p></htmltext>
<tokenext>My company has a pretty rigid set of processes and we find that we catch approximately 25 \ % of our defects in code reviews .
This does n't count minor things like not following the coding conventions or bad comments , those are logged separately .
We have reviews where we hand them off to just one other engineer as well as the Fagan style of reviews , depending on what we feel is appropriate for the particular piece of code .
In our industry ( embedded software ) , it is n't exactly easy to push out a patch once the code is released so that plays into how/why we do it the way we do .
I would n't say the review process is cheap , but neither are warranty campaigns .
Pay it now or pay it later I guess...Even the best people occasionally typo , put in a bad/wrong comment or just flat out make a mistake during coding .
Personally , I 'd love it if we had the resources to review every single line of code I write .</tokentext>
<sentencetext>My company has a pretty rigid set of processes and we find that we catch approximately 25\% of our defects in code reviews.
This doesn't count minor things like not following the coding conventions or bad comments, those are logged separately.
We have reviews where we hand them off to just one other engineer as well as the Fagan style of reviews, depending on what we feel is appropriate for the particular piece of code.
In our industry(embedded software), it isn't exactly easy to push out a patch once the code is released so that plays into how/why we do it the way we do.
I wouldn't say the review process is cheap, but neither are warranty campaigns.
Pay it now or pay it later I guess...Even the best people occasionally typo, put in a bad/wrong comment or just flat out make a mistake during coding.
Personally, I'd love it if we had the resources to review every single line of code I write.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322949</id>
	<title>Yes and no.</title>
	<author>ThePhilips</author>
	<datestamp>1244892360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p> In my experience, code reviews are generally useless. Main problem is that very few software projects have decent documentation which can be used as base for code review. Without documentation, reviews generally end up being a R&amp;D-wide (or worse) squabble.

</p><p> As development manager, one should try to make the reviews an integral part of development process. Keyword is "integral." Results of review are hard to quantify, thus something should be done to make them useful to the other phases of development process. IOW, results of reviews shouldn't be something on their own, they should be used somewhere too.

</p><p> One major use for code reviews is when their results are fed back into testing effort. There are companies which test software based solely on high level list of features. I witnessed at least once quite huge mess, caused by bogus design done by R&amp;D: essentially trivial global option was switching code in several programs to alternative code paths. R&amp;D on tight schedule to implement the option simply copy-pasted with minor modifications piles of code. Test department obviously had no idea about that and the option wasn't even properly documented. Code review might have discovered that sooner (e.g. before we actually had several customers attempting to deploy the feature), pushing R&amp;D to do proper design w/o code duplication (unrealistic for commercially developed software) or at least feeding the finding to test department so that they could have tested the whole system twice (option is on, options is off).</p><p><div class="quote"><p> Our code is intended for desktop, non-critical use, so I asked my boss to consider whether it was worth spending so much time on examining built code, given our experience not getting much out of it.</p> </div><p> No results from core review is a positive result.

</p><p> But there is a gotcha: if all your developers have similar/save background, then efficiency of code review would be extremely low as such developers  tend to do same mistakes. For effective code review, you need people who view the software differently: e.g. developers of one component review another component. Best of all if they would also have different education and background.

</p><p> But obviously developers themselves should be willing to participate in code reviews. Code review is quite exhausting (e.g. I can review only about 3.5K LOC per day - more my brains do not manage) and poorly motivated developers would do very sloppy job at that. If you can show developers with some graphs from issue tracking system that code review improves quality, then they might be more interested in the process. Yet, still, do not expect any miracles.

</p><p> Honestly though code review was always my dream. As developer I do quite a number of trivial coding mistakes. When possible I adjust my coding style so that compilers can detect such errors, but commercial compilers I have to use are quite moronic (compared to GCC) when it comes to warnings. And not on one project I had seen people disabling compiler warnings altogether because<nobr> <wbr></nobr>... because<nobr> <wbr></nobr>... like hell I know what goes in heads of generic developers on pay roll.</p></div>
	</htmltext>
<tokenext>In my experience , code reviews are generally useless .
Main problem is that very few software projects have decent documentation which can be used as base for code review .
Without documentation , reviews generally end up being a R&amp;D-wide ( or worse ) squabble .
As development manager , one should try to make the reviews an integral part of development process .
Keyword is " integral .
" Results of review are hard to quantify , thus something should be done to make them useful to the other phases of development process .
IOW , results of reviews should n't be something on their own , they should be used somewhere too .
One major use for code reviews is when their results are fed back into testing effort .
There are companies which test software based solely on high level list of features .
I witnessed at least once quite huge mess , caused by bogus design done by R&amp;D : essentially trivial global option was switching code in several programs to alternative code paths .
R&amp;D on tight schedule to implement the option simply copy-pasted with minor modifications piles of code .
Test department obviously had no idea about that and the option was n't even properly documented .
Code review might have discovered that sooner ( e.g .
before we actually had several customers attempting to deploy the feature ) , pushing R&amp;D to do proper design w/o code duplication ( unrealistic for commercially developed software ) or at least feeding the finding to test department so that they could have tested the whole system twice ( option is on , options is off ) .
Our code is intended for desktop , non-critical use , so I asked my boss to consider whether it was worth spending so much time on examining built code , given our experience not getting much out of it .
No results from core review is a positive result .
But there is a gotcha : if all your developers have similar/save background , then efficiency of code review would be extremely low as such developers tend to do same mistakes .
For effective code review , you need people who view the software differently : e.g .
developers of one component review another component .
Best of all if they would also have different education and background .
But obviously developers themselves should be willing to participate in code reviews .
Code review is quite exhausting ( e.g .
I can review only about 3.5K LOC per day - more my brains do not manage ) and poorly motivated developers would do very sloppy job at that .
If you can show developers with some graphs from issue tracking system that code review improves quality , then they might be more interested in the process .
Yet , still , do not expect any miracles .
Honestly though code review was always my dream .
As developer I do quite a number of trivial coding mistakes .
When possible I adjust my coding style so that compilers can detect such errors , but commercial compilers I have to use are quite moronic ( compared to GCC ) when it comes to warnings .
And not on one project I had seen people disabling compiler warnings altogether because ... because ... like hell I know what goes in heads of generic developers on pay roll .</tokentext>
<sentencetext> In my experience, code reviews are generally useless.
Main problem is that very few software projects have decent documentation which can be used as base for code review.
Without documentation, reviews generally end up being a R&amp;D-wide (or worse) squabble.
As development manager, one should try to make the reviews an integral part of development process.
Keyword is "integral.
" Results of review are hard to quantify, thus something should be done to make them useful to the other phases of development process.
IOW, results of reviews shouldn't be something on their own, they should be used somewhere too.
One major use for code reviews is when their results are fed back into testing effort.
There are companies which test software based solely on high level list of features.
I witnessed at least once quite huge mess, caused by bogus design done by R&amp;D: essentially trivial global option was switching code in several programs to alternative code paths.
R&amp;D on tight schedule to implement the option simply copy-pasted with minor modifications piles of code.
Test department obviously had no idea about that and the option wasn't even properly documented.
Code review might have discovered that sooner (e.g.
before we actually had several customers attempting to deploy the feature), pushing R&amp;D to do proper design w/o code duplication (unrealistic for commercially developed software) or at least feeding the finding to test department so that they could have tested the whole system twice (option is on, options is off).
Our code is intended for desktop, non-critical use, so I asked my boss to consider whether it was worth spending so much time on examining built code, given our experience not getting much out of it.
No results from core review is a positive result.
But there is a gotcha: if all your developers have similar/save background, then efficiency of code review would be extremely low as such developers  tend to do same mistakes.
For effective code review, you need people who view the software differently: e.g.
developers of one component review another component.
Best of all if they would also have different education and background.
But obviously developers themselves should be willing to participate in code reviews.
Code review is quite exhausting (e.g.
I can review only about 3.5K LOC per day - more my brains do not manage) and poorly motivated developers would do very sloppy job at that.
If you can show developers with some graphs from issue tracking system that code review improves quality, then they might be more interested in the process.
Yet, still, do not expect any miracles.
Honestly though code review was always my dream.
As developer I do quite a number of trivial coding mistakes.
When possible I adjust my coding style so that compilers can detect such errors, but commercial compilers I have to use are quite moronic (compared to GCC) when it comes to warnings.
And not on one project I had seen people disabling compiler warnings altogether because ... because ... like hell I know what goes in heads of generic developers on pay roll.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28328961</id>
	<title>Re:Depends what you are reviewing</title>
	<author>Anonymous</author>
	<datestamp>1244972160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Except that development costs are only 10\% of the costs of that code.  The other 90\% is maintenance.  Code that's been reviewed has had other developers look at it and agree that the implementation is not only correct, but it's understandable and maintainable.</p></htmltext>
<tokenext>Except that development costs are only 10 \ % of the costs of that code .
The other 90 \ % is maintenance .
Code that 's been reviewed has had other developers look at it and agree that the implementation is not only correct , but it 's understandable and maintainable .</tokentext>
<sentencetext>Except that development costs are only 10\% of the costs of that code.
The other 90\% is maintenance.
Code that's been reviewed has had other developers look at it and agree that the implementation is not only correct, but it's understandable and maintainable.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323647</id>
	<title>Re:If you did test-driven development</title>
	<author>Blakey Rat</author>
	<datestamp>1244899980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not to mention that TDD is utterly useless for finding UI issues, assuming your code has a UI. There's no testing suite on earth that'll be able to tell you "the terminology on this button label is misleading."</p><p>Now if you don't have a UI, maybe you don't care. But a significant amount of software does.</p></htmltext>
<tokenext>Not to mention that TDD is utterly useless for finding UI issues , assuming your code has a UI .
There 's no testing suite on earth that 'll be able to tell you " the terminology on this button label is misleading .
" Now if you do n't have a UI , maybe you do n't care .
But a significant amount of software does .</tokentext>
<sentencetext>Not to mention that TDD is utterly useless for finding UI issues, assuming your code has a UI.
There's no testing suite on earth that'll be able to tell you "the terminology on this button label is misleading.
"Now if you don't have a UI, maybe you don't care.
But a significant amount of software does.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322771</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28330347</id>
	<title>Re:If you did test-driven development</title>
	<author>Anonymous</author>
	<datestamp>1244985060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>But the tests you think of doing in a test-first/test-driven environment are different to those you think of afterwards.  Before you code, you are thinking about what the code should do.  Afterwards, you are thinking about what the code does.</p><p>Can you provide a reference to/summary of the story you mentioned?</p></htmltext>
<tokenext>But the tests you think of doing in a test-first/test-driven environment are different to those you think of afterwards .
Before you code , you are thinking about what the code should do .
Afterwards , you are thinking about what the code does.Can you provide a reference to/summary of the story you mentioned ?</tokentext>
<sentencetext>But the tests you think of doing in a test-first/test-driven environment are different to those you think of afterwards.
Before you code, you are thinking about what the code should do.
Afterwards, you are thinking about what the code does.Can you provide a reference to/summary of the story you mentioned?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322849</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323089</id>
	<title>depends</title>
	<author>oee</author>
	<datestamp>1244893980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Code reviews</p><p>if an expert:<br>
&nbsp; &nbsp; &nbsp; if humble: definitely worth it.<br>
&nbsp; &nbsp; &nbsp; if arrogant: a pain, but probably worth it<br>else if your boss (but not an expert)<br>
&nbsp; &nbsp; &nbsp; if nice: alright.<br>
&nbsp; &nbsp; &nbsp; if a jerk: a nightmare (lobby against reviews)<br>else<br>
&nbsp; &nbsp; &nbsp; not worth it (lobby against reviews)<br>end</p></htmltext>
<tokenext>Code reviewsif an expert :       if humble : definitely worth it .
      if arrogant : a pain , but probably worth itelse if your boss ( but not an expert )       if nice : alright .
      if a jerk : a nightmare ( lobby against reviews ) else       not worth it ( lobby against reviews ) end</tokentext>
<sentencetext>Code reviewsif an expert:
      if humble: definitely worth it.
      if arrogant: a pain, but probably worth itelse if your boss (but not an expert)
      if nice: alright.
      if a jerk: a nightmare (lobby against reviews)else
      not worth it (lobby against reviews)end</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28332383</id>
	<title>Mythical Man Month, Anyone?</title>
	<author>mikehoskins</author>
	<datestamp>1245007380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Then there's the powers of ten cost of fixing problems...<br>
&nbsp; &nbsp; Design = $1<br>
&nbsp; &nbsp; Development = $10<br>
&nbsp; &nbsp; Debugging = $100<br>
&nbsp; &nbsp; Deployment = $1000<br>
&nbsp; &nbsp; - Frederick P. Brooks<br>
&nbsp; &nbsp; The Mythical Man-Month: Essays on Software<br>
&nbsp; &nbsp; Engineering, Anniversary Edition (2nd Edition)</p><p>Think of it this way....</p><p>So, anything you catch in design costs you a "buck" for your effort.  If you catch it during development, it *still* only costs you "10 bucks."</p><p>If you wait until debugging ("100 bucks") or deployment ("1000 bucks"), you're hosed.</p><p>You can be more or less effective during a code review, but as long as it catches stuff, it's still far easier, cheaper, faster, better to catch it there, than later...  Yes, it may be 10x harder to catch during a code review than a design review.  Well, you're just proving the Mythical Man Month to be true.  Your boss knows it, too, and he's trying to stop the vicious debug -&gt; deploy problem.</p><p>Do you want screaming customers at 4:00a, calling you about some obscure error in a program you wrote, when it might be avoidable?  Does your boss want to earn blame for a team of "bad coders?"</p><p>I'd say that it's good that your boss wants this bit of extra discipline -- for your sake, his, the customers', and the company's....</p></htmltext>
<tokenext>Then there 's the powers of ten cost of fixing problems.. .     Design = $ 1     Development = $ 10     Debugging = $ 100     Deployment = $ 1000     - Frederick P. Brooks     The Mythical Man-Month : Essays on Software     Engineering , Anniversary Edition ( 2nd Edition ) Think of it this way....So , anything you catch in design costs you a " buck " for your effort .
If you catch it during development , it * still * only costs you " 10 bucks .
" If you wait until debugging ( " 100 bucks " ) or deployment ( " 1000 bucks " ) , you 're hosed.You can be more or less effective during a code review , but as long as it catches stuff , it 's still far easier , cheaper , faster , better to catch it there , than later... Yes , it may be 10x harder to catch during a code review than a design review .
Well , you 're just proving the Mythical Man Month to be true .
Your boss knows it , too , and he 's trying to stop the vicious debug - &gt; deploy problem.Do you want screaming customers at 4 : 00a , calling you about some obscure error in a program you wrote , when it might be avoidable ?
Does your boss want to earn blame for a team of " bad coders ?
" I 'd say that it 's good that your boss wants this bit of extra discipline -- for your sake , his , the customers ' , and the company 's... .</tokentext>
<sentencetext>Then there's the powers of ten cost of fixing problems...
    Design = $1
    Development = $10
    Debugging = $100
    Deployment = $1000
    - Frederick P. Brooks
    The Mythical Man-Month: Essays on Software
    Engineering, Anniversary Edition (2nd Edition)Think of it this way....So, anything you catch in design costs you a "buck" for your effort.
If you catch it during development, it *still* only costs you "10 bucks.
"If you wait until debugging ("100 bucks") or deployment ("1000 bucks"), you're hosed.You can be more or less effective during a code review, but as long as it catches stuff, it's still far easier, cheaper, faster, better to catch it there, than later...  Yes, it may be 10x harder to catch during a code review than a design review.
Well, you're just proving the Mythical Man Month to be true.
Your boss knows it, too, and he's trying to stop the vicious debug -&gt; deploy problem.Do you want screaming customers at 4:00a, calling you about some obscure error in a program you wrote, when it might be avoidable?
Does your boss want to earn blame for a team of "bad coders?
"I'd say that it's good that your boss wants this bit of extra discipline -- for your sake, his, the customers', and the company's....</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323995</id>
	<title>The only valid measurement of code quality</title>
	<author>arkarumba</author>
	<datestamp>1244904420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The only valid measurement of code quality<br><a href="http://www.osnews.com/story/19266/WTFs\_m" title="osnews.com" rel="nofollow">http://www.osnews.com/story/19266/WTFs\_m</a> [osnews.com]</p></htmltext>
<tokenext>The only valid measurement of code qualityhttp : //www.osnews.com/story/19266/WTFs \ _m [ osnews.com ]</tokentext>
<sentencetext>The only valid measurement of code qualityhttp://www.osnews.com/story/19266/WTFs\_m [osnews.com]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324027</id>
	<title>Re:a fucktonne?</title>
	<author>Anonymous</author>
	<datestamp>1244904720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Actually it is a little more universal than that.  The imperial system is in the minority now.</p></htmltext>
<tokenext>Actually it is a little more universal than that .
The imperial system is in the minority now .</tokentext>
<sentencetext>Actually it is a little more universal than that.
The imperial system is in the minority now.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323911</id>
	<title>Re:Delusions of grandeur</title>
	<author>Anonymous</author>
	<datestamp>1244903220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>My working life has been spent in projects developed by individuals or small teams (less than six programmers). I would describe my working environments as "CMM level 1 and damn proud of it." The teams I have been on have been consistently successful without having a consistent methodology. The success is the result of having a bunch of competent people who respect each other, and are motivated by the idea of producing something that customers will pay money for, because it works. And by the knowledge that they'll stick with the project for a while, and if they make any messes they'll be the same people who have to clean them up later.</p><p>I've suffered throughout my working life from inexperienced managers and programmers who suffer from what I call delusions of grandeur. 90\% of the stuff that people learn about project management seems to me to be intended for use in projects with fifty programmers or more. Projects where the manager can't get a grasp of the project by walking around and schmoozing with people. Projects that are big enough that there are constantly people leaving and joining them. I don't know about projects like that. I'm inclined to think that formal management processes may be useful, even essential there.</p><p>But on small-team projects, it just gets in the way.</p><p>The problem is that the books that explain the capital-M Methodologies and the code review process and so forth never say, in so many words, that these are management procedures for projects with more than fifty people. They just say, "this is how you do it." And people come out of courses believing that "doing it right" means applying all this stuff. And that anything else is unprofessional.</p><p>The hidden assumption is that everyone wants to follow a career path where they manage more and more and more people on bigger and bigger and bigger projects and make more and more and more money. When I worked at a Fortune 500 company, people were very frank about it. It was a waste of time proposing or working on small stuff. You had to "think big" or management would never take any interest in what you were doing.</p><p>Well, I'm here to say that if you want to think big and manage like the big boys do, fine. But don't try it on a small-team project where the team members have gelled into a coherent unit, and know each other and work well together, and plan to stick around for a while.</p><p>Code reviews? Gimme a break. In the natural course of events, other team members are going to have to work with my code. If I don't care about what they think about it \_when they're editing it to get their job done,\_ I'm sure not going to care what they think about it in some room with a whiteboard. And we're effectively eviewing each others' code in the natural course of getting our jobs done, then sealing ourselves into a room with a whiteboard and no debugger, isn't going to be any better than what we naturally do without any formal process.</p></div><p>It's been my experience that delusions of grandeur occur far more frequently at CMM level 1 (Ad hoc (Chaotic)). It is generally found in individual projects or small teams where 1 (or a very few developers) have had some level of success and this has lead them to believe that they can "wing it" through just about any project. That works fine, until they are wrong.</p><p>By definition (CCM 1), their processes aren't repeatable, they aren't defined and documented, and they don't adapt well to other projects and processes without tremendous effort. So when one of them gets hit by a bus, decides to let his ego halt a project, or encounters projects requiring outside expertise, the projects fail catastrophically. Almost invariably, CMM level 1 folks will blame managers that 'just don't understand', customers that are 'idiots', and other coders that are 'incompetent'. The truth is, there are very small projects and/or short term projects where CMM level 1 works great. But if you NEED your project to stick around (longevity), to be able to be picked up by others (turnover), and able to interact well with many other projects (scope changes/adaptability), you NEED more than CMM level 1.</p><p>I've seen SMALL teams (3-10 coders) operating at CMM level 3 and 4. But if you want that kind of effort, be prepared to pay for it in terms of cost and schedule and personnel. Either pay the level 3-4 to get the job right, or pay the level 1 guys to fail, succeed but be unmaintainable, or succeed and be a stovepipe.</p><p>There is a HUGE difference between a few (1-3) really sharp level 1 coders and a small team (3-10) of level 3-4 coders. It's been my experience that the latter is worth every penny unless the project(s) are under $500k/year of effort.</p></div>
	</htmltext>
<tokenext>My working life has been spent in projects developed by individuals or small teams ( less than six programmers ) .
I would describe my working environments as " CMM level 1 and damn proud of it .
" The teams I have been on have been consistently successful without having a consistent methodology .
The success is the result of having a bunch of competent people who respect each other , and are motivated by the idea of producing something that customers will pay money for , because it works .
And by the knowledge that they 'll stick with the project for a while , and if they make any messes they 'll be the same people who have to clean them up later.I 've suffered throughout my working life from inexperienced managers and programmers who suffer from what I call delusions of grandeur .
90 \ % of the stuff that people learn about project management seems to me to be intended for use in projects with fifty programmers or more .
Projects where the manager ca n't get a grasp of the project by walking around and schmoozing with people .
Projects that are big enough that there are constantly people leaving and joining them .
I do n't know about projects like that .
I 'm inclined to think that formal management processes may be useful , even essential there.But on small-team projects , it just gets in the way.The problem is that the books that explain the capital-M Methodologies and the code review process and so forth never say , in so many words , that these are management procedures for projects with more than fifty people .
They just say , " this is how you do it .
" And people come out of courses believing that " doing it right " means applying all this stuff .
And that anything else is unprofessional.The hidden assumption is that everyone wants to follow a career path where they manage more and more and more people on bigger and bigger and bigger projects and make more and more and more money .
When I worked at a Fortune 500 company , people were very frank about it .
It was a waste of time proposing or working on small stuff .
You had to " think big " or management would never take any interest in what you were doing.Well , I 'm here to say that if you want to think big and manage like the big boys do , fine .
But do n't try it on a small-team project where the team members have gelled into a coherent unit , and know each other and work well together , and plan to stick around for a while.Code reviews ?
Gim me a break .
In the natural course of events , other team members are going to have to work with my code .
If I do n't care about what they think about it \ _when they 're editing it to get their job done , \ _ I 'm sure not going to care what they think about it in some room with a whiteboard .
And we 're effectively eviewing each others ' code in the natural course of getting our jobs done , then sealing ourselves into a room with a whiteboard and no debugger , is n't going to be any better than what we naturally do without any formal process.It 's been my experience that delusions of grandeur occur far more frequently at CMM level 1 ( Ad hoc ( Chaotic ) ) .
It is generally found in individual projects or small teams where 1 ( or a very few developers ) have had some level of success and this has lead them to believe that they can " wing it " through just about any project .
That works fine , until they are wrong.By definition ( CCM 1 ) , their processes are n't repeatable , they are n't defined and documented , and they do n't adapt well to other projects and processes without tremendous effort .
So when one of them gets hit by a bus , decides to let his ego halt a project , or encounters projects requiring outside expertise , the projects fail catastrophically .
Almost invariably , CMM level 1 folks will blame managers that 'just do n't understand ' , customers that are 'idiots ' , and other coders that are 'incompetent' .
The truth is , there are very small projects and/or short term projects where CMM level 1 works great .
But if you NEED your project to stick around ( longevity ) , to be able to be picked up by others ( turnover ) , and able to interact well with many other projects ( scope changes/adaptability ) , you NEED more than CMM level 1.I 've seen SMALL teams ( 3-10 coders ) operating at CMM level 3 and 4 .
But if you want that kind of effort , be prepared to pay for it in terms of cost and schedule and personnel .
Either pay the level 3-4 to get the job right , or pay the level 1 guys to fail , succeed but be unmaintainable , or succeed and be a stovepipe.There is a HUGE difference between a few ( 1-3 ) really sharp level 1 coders and a small team ( 3-10 ) of level 3-4 coders .
It 's been my experience that the latter is worth every penny unless the project ( s ) are under $ 500k/year of effort .</tokentext>
<sentencetext>My working life has been spent in projects developed by individuals or small teams (less than six programmers).
I would describe my working environments as "CMM level 1 and damn proud of it.
" The teams I have been on have been consistently successful without having a consistent methodology.
The success is the result of having a bunch of competent people who respect each other, and are motivated by the idea of producing something that customers will pay money for, because it works.
And by the knowledge that they'll stick with the project for a while, and if they make any messes they'll be the same people who have to clean them up later.I've suffered throughout my working life from inexperienced managers and programmers who suffer from what I call delusions of grandeur.
90\% of the stuff that people learn about project management seems to me to be intended for use in projects with fifty programmers or more.
Projects where the manager can't get a grasp of the project by walking around and schmoozing with people.
Projects that are big enough that there are constantly people leaving and joining them.
I don't know about projects like that.
I'm inclined to think that formal management processes may be useful, even essential there.But on small-team projects, it just gets in the way.The problem is that the books that explain the capital-M Methodologies and the code review process and so forth never say, in so many words, that these are management procedures for projects with more than fifty people.
They just say, "this is how you do it.
" And people come out of courses believing that "doing it right" means applying all this stuff.
And that anything else is unprofessional.The hidden assumption is that everyone wants to follow a career path where they manage more and more and more people on bigger and bigger and bigger projects and make more and more and more money.
When I worked at a Fortune 500 company, people were very frank about it.
It was a waste of time proposing or working on small stuff.
You had to "think big" or management would never take any interest in what you were doing.Well, I'm here to say that if you want to think big and manage like the big boys do, fine.
But don't try it on a small-team project where the team members have gelled into a coherent unit, and know each other and work well together, and plan to stick around for a while.Code reviews?
Gimme a break.
In the natural course of events, other team members are going to have to work with my code.
If I don't care about what they think about it \_when they're editing it to get their job done,\_ I'm sure not going to care what they think about it in some room with a whiteboard.
And we're effectively eviewing each others' code in the natural course of getting our jobs done, then sealing ourselves into a room with a whiteboard and no debugger, isn't going to be any better than what we naturally do without any formal process.It's been my experience that delusions of grandeur occur far more frequently at CMM level 1 (Ad hoc (Chaotic)).
It is generally found in individual projects or small teams where 1 (or a very few developers) have had some level of success and this has lead them to believe that they can "wing it" through just about any project.
That works fine, until they are wrong.By definition (CCM 1), their processes aren't repeatable, they aren't defined and documented, and they don't adapt well to other projects and processes without tremendous effort.
So when one of them gets hit by a bus, decides to let his ego halt a project, or encounters projects requiring outside expertise, the projects fail catastrophically.
Almost invariably, CMM level 1 folks will blame managers that 'just don't understand', customers that are 'idiots', and other coders that are 'incompetent'.
The truth is, there are very small projects and/or short term projects where CMM level 1 works great.
But if you NEED your project to stick around (longevity), to be able to be picked up by others (turnover), and able to interact well with many other projects (scope changes/adaptability), you NEED more than CMM level 1.I've seen SMALL teams (3-10 coders) operating at CMM level 3 and 4.
But if you want that kind of effort, be prepared to pay for it in terms of cost and schedule and personnel.
Either pay the level 3-4 to get the job right, or pay the level 1 guys to fail, succeed but be unmaintainable, or succeed and be a stovepipe.There is a HUGE difference between a few (1-3) really sharp level 1 coders and a small team (3-10) of level 3-4 coders.
It's been my experience that the latter is worth every penny unless the project(s) are under $500k/year of effort.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325255</id>
	<title>Code reviewes can be good or bad</title>
	<author>Anonymous</author>
	<datestamp>1244970660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I work in a large programming shop. I've participated in both worthwhile and worthless code reviews.</p><p>The worthwhile ones require preparation. During that preparation you read the code, dividing issues into two categories: minor and major. Minor issues go direct to the programmer and aren't open for discussion during the meeting. So programming style issues don't make to the the table. The convenor collates the major issues, and these are addressed in order during the walkthrough meeting.</p><p>Of course, not all major issues are bugs. Sometimes issues are unclear code which must be tidied to make maintenance cheaper. Sometimes issues show a lack of understanding about the customer's industry -- for example, tying down a attribute of the problem in code which we know is open to change and thus should be configurable. Sometimes the issue is a misuse of a API, and this class of error can lead to a system-wide review (the classic error here being strcpy()).</p><p>The reason programmers don't like code review is because they show what the abilities and limitations of the programmer and the reviewers are. They all like to dream that they are coding heroes, and reviews bring them back to earth. But as the technical lead I prefer that to encountering problems post-shipment. Also, I don't want heroes on my team; I want people who are self-aware, who know what they are good and bad at, who working to make the bad better, and know when to ask for help rather than shipping deficient code.</p><p>The most important step to achieving good code reviews is to aim to do good code reviews. This means designing the review process so that it is effective. A three hour meeting which reads code which has not been viewed before, which criticises style over substance, which offends rather than teaches, and drags on missing the forest for the trees is a a failure.</p><p>The other really important purpose of code reviews is to examine that 1\% of existing code which is causing 30\% of the fault reports. Don't allocate that issue to a programmer to work on alone. Allocate it to a programmer, and review the old code as if that programmer wrote it. Then the full force of the team's intellect and experience will be bought to bear on that troublesome issue. The effect on the programmer is also good -- they don't feel as though they've been handed the troublesome child to work on alone and unassisted.</p></htmltext>
<tokenext>I work in a large programming shop .
I 've participated in both worthwhile and worthless code reviews.The worthwhile ones require preparation .
During that preparation you read the code , dividing issues into two categories : minor and major .
Minor issues go direct to the programmer and are n't open for discussion during the meeting .
So programming style issues do n't make to the the table .
The convenor collates the major issues , and these are addressed in order during the walkthrough meeting.Of course , not all major issues are bugs .
Sometimes issues are unclear code which must be tidied to make maintenance cheaper .
Sometimes issues show a lack of understanding about the customer 's industry -- for example , tying down a attribute of the problem in code which we know is open to change and thus should be configurable .
Sometimes the issue is a misuse of a API , and this class of error can lead to a system-wide review ( the classic error here being strcpy ( ) ) .The reason programmers do n't like code review is because they show what the abilities and limitations of the programmer and the reviewers are .
They all like to dream that they are coding heroes , and reviews bring them back to earth .
But as the technical lead I prefer that to encountering problems post-shipment .
Also , I do n't want heroes on my team ; I want people who are self-aware , who know what they are good and bad at , who working to make the bad better , and know when to ask for help rather than shipping deficient code.The most important step to achieving good code reviews is to aim to do good code reviews .
This means designing the review process so that it is effective .
A three hour meeting which reads code which has not been viewed before , which criticises style over substance , which offends rather than teaches , and drags on missing the forest for the trees is a a failure.The other really important purpose of code reviews is to examine that 1 \ % of existing code which is causing 30 \ % of the fault reports .
Do n't allocate that issue to a programmer to work on alone .
Allocate it to a programmer , and review the old code as if that programmer wrote it .
Then the full force of the team 's intellect and experience will be bought to bear on that troublesome issue .
The effect on the programmer is also good -- they do n't feel as though they 've been handed the troublesome child to work on alone and unassisted .</tokentext>
<sentencetext>I work in a large programming shop.
I've participated in both worthwhile and worthless code reviews.The worthwhile ones require preparation.
During that preparation you read the code, dividing issues into two categories: minor and major.
Minor issues go direct to the programmer and aren't open for discussion during the meeting.
So programming style issues don't make to the the table.
The convenor collates the major issues, and these are addressed in order during the walkthrough meeting.Of course, not all major issues are bugs.
Sometimes issues are unclear code which must be tidied to make maintenance cheaper.
Sometimes issues show a lack of understanding about the customer's industry -- for example, tying down a attribute of the problem in code which we know is open to change and thus should be configurable.
Sometimes the issue is a misuse of a API, and this class of error can lead to a system-wide review (the classic error here being strcpy()).The reason programmers don't like code review is because they show what the abilities and limitations of the programmer and the reviewers are.
They all like to dream that they are coding heroes, and reviews bring them back to earth.
But as the technical lead I prefer that to encountering problems post-shipment.
Also, I don't want heroes on my team; I want people who are self-aware, who know what they are good and bad at, who working to make the bad better, and know when to ask for help rather than shipping deficient code.The most important step to achieving good code reviews is to aim to do good code reviews.
This means designing the review process so that it is effective.
A three hour meeting which reads code which has not been viewed before, which criticises style over substance, which offends rather than teaches, and drags on missing the forest for the trees is a a failure.The other really important purpose of code reviews is to examine that 1\% of existing code which is causing 30\% of the fault reports.
Don't allocate that issue to a programmer to work on alone.
Allocate it to a programmer, and review the old code as if that programmer wrote it.
Then the full force of the team's intellect and experience will be bought to bear on that troublesome issue.
The effect on the programmer is also good -- they don't feel as though they've been handed the troublesome child to work on alone and unassisted.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323483</id>
	<title>Well, if we go by industry practices</title>
	<author>93 Escort Wagon</author>
	<datestamp>1244898180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's pretty obvious Electronic Arts did away with code reviews many years ago.</p></htmltext>
<tokenext>It 's pretty obvious Electronic Arts did away with code reviews many years ago .</tokentext>
<sentencetext>It's pretty obvious Electronic Arts did away with code reviews many years ago.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325515</id>
	<title>What's more expensive?</title>
	<author>Chris Snook</author>
	<datestamp>1244976840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Fixing a bug, or fixing a design flaw?  If your customers aren't going to ditch you for the occasional glitch, and it sounds like yours won't, it's much more important to focus your resources on making sure that they have a good overall experience.</p></htmltext>
<tokenext>Fixing a bug , or fixing a design flaw ?
If your customers are n't going to ditch you for the occasional glitch , and it sounds like yours wo n't , it 's much more important to focus your resources on making sure that they have a good overall experience .</tokentext>
<sentencetext>Fixing a bug, or fixing a design flaw?
If your customers aren't going to ditch you for the occasional glitch, and it sounds like yours won't, it's much more important to focus your resources on making sure that they have a good overall experience.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531</id>
	<title>Are they worth it?</title>
	<author>Anonymous</author>
	<datestamp>1244888760000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><p>No.</p><p>Discussion over, everyone go home.</p></htmltext>
<tokenext>No.Discussion over , everyone go home .</tokentext>
<sentencetext>No.Discussion over, everyone go home.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323391</id>
	<title>Cardboard cutout dog</title>
	<author>Anonymous</author>
	<datestamp>1244897100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><a href="http://www.sjbaker.org/humor/cardboard\_dog.html" title="sjbaker.org" rel="nofollow">Cardboard Cutout Dog</a> [sjbaker.org]</p><p>Possibly the finest essay on the subject.</p><p>Jokes aside, it basically posits that the value of the code review is not in the listening, but in not letting your ideas stay in your head as a ball of fuzz, and force you to make them concrete by talking to someone/something.  Tends to be true about code, and many other things.</p></htmltext>
<tokenext>Cardboard Cutout Dog [ sjbaker.org ] Possibly the finest essay on the subject.Jokes aside , it basically posits that the value of the code review is not in the listening , but in not letting your ideas stay in your head as a ball of fuzz , and force you to make them concrete by talking to someone/something .
Tends to be true about code , and many other things .</tokentext>
<sentencetext>Cardboard Cutout Dog [sjbaker.org]Possibly the finest essay on the subject.Jokes aside, it basically posits that the value of the code review is not in the listening, but in not letting your ideas stay in your head as a ball of fuzz, and force you to make them concrete by talking to someone/something.
Tends to be true about code, and many other things.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323439</id>
	<title>Statistical evidence that code review is worth it.</title>
	<author>kfogel</author>
	<datestamp>1244897580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>For some statistical evidence (built on a <em>very</em> small sample size) that code review is worth it, see this section of a chapter from O'Reilly Media's book <em>Beautiful Teams</em>:</p><p>
&nbsp; &nbsp; <a href="http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html#gumption-sink" title="red-bean.com">http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html#gumption-sink</a> [red-bean.com]</p><p>That section is not about code review per se (it's about how a seemingly trivial interface decision affected code review), but it includes some code review stats from two projects, and discusses how frequently one project's code review catches mistake from previous changes.</p><p>(Disclaimer: I wrote the chapter, but it seems pertinent enough to this discussion to be worth posting.)</p><p>--Karl Fogel</p></htmltext>
<tokenext>For some statistical evidence ( built on a very small sample size ) that code review is worth it , see this section of a chapter from O'Reilly Media 's book Beautiful Teams :     http : //www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html # gumption-sink [ red-bean.com ] That section is not about code review per se ( it 's about how a seemingly trivial interface decision affected code review ) , but it includes some code review stats from two projects , and discusses how frequently one project 's code review catches mistake from previous changes .
( Disclaimer : I wrote the chapter , but it seems pertinent enough to this discussion to be worth posting .
) --Karl Fogel</tokentext>
<sentencetext>For some statistical evidence (built on a very small sample size) that code review is worth it, see this section of a chapter from O'Reilly Media's book Beautiful Teams:
    http://www.red-bean.com/kfogel/beautiful-teams/bt-chapter-21.html#gumption-sink [red-bean.com]That section is not about code review per se (it's about how a seemingly trivial interface decision affected code review), but it includes some code review stats from two projects, and discusses how frequently one project's code review catches mistake from previous changes.
(Disclaimer: I wrote the chapter, but it seems pertinent enough to this discussion to be worth posting.
)--Karl Fogel</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324793</id>
	<title>Core Reviews.</title>
	<author>Z00L00K</author>
	<datestamp>1244916840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Some code reviewing is validated but much of the tiresome review work can be resolved by automatic tools these days. Tools like Lint and FindBugs.</p><p>But a review to make sure that the code is easy to understand and maintain is a different issue that can't be addressed by automatic tools. At least not until you get a tool that can semantically understand comments.</p></htmltext>
<tokenext>Some code reviewing is validated but much of the tiresome review work can be resolved by automatic tools these days .
Tools like Lint and FindBugs.But a review to make sure that the code is easy to understand and maintain is a different issue that ca n't be addressed by automatic tools .
At least not until you get a tool that can semantically understand comments .</tokentext>
<sentencetext>Some code reviewing is validated but much of the tiresome review work can be resolved by automatic tools these days.
Tools like Lint and FindBugs.But a review to make sure that the code is easy to understand and maintain is a different issue that can't be addressed by automatic tools.
At least not until you get a tool that can semantically understand comments.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323253</id>
	<title>Code Reviews - Waste of Time</title>
	<author>Anonymous</author>
	<datestamp>1244895840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The sooner people realize that specialized Programmers are a thing of the past and that System Designers with DBA and Programming understanding will be the future the better. Microsoft already has an application creator based on your DB and the full ability to customize your template for the app creator so you can fix bugs in the root and deploy that template out for any web application you have. This is the future and debugging and documenting the logic and syntax of the code is a waste of time. Document out the flows and build the DB first and then the program 2nd and rely on the database instead of the actual program will save companies millions in the long run. Local Windows applications and Web Applications are going to merge soon into 1 platform that is universal and the sooner you prepare for this the better. Check your design and database that follows that design, you will get a whole heck of a lot more than you would from checking the code.</p></htmltext>
<tokenext>The sooner people realize that specialized Programmers are a thing of the past and that System Designers with DBA and Programming understanding will be the future the better .
Microsoft already has an application creator based on your DB and the full ability to customize your template for the app creator so you can fix bugs in the root and deploy that template out for any web application you have .
This is the future and debugging and documenting the logic and syntax of the code is a waste of time .
Document out the flows and build the DB first and then the program 2nd and rely on the database instead of the actual program will save companies millions in the long run .
Local Windows applications and Web Applications are going to merge soon into 1 platform that is universal and the sooner you prepare for this the better .
Check your design and database that follows that design , you will get a whole heck of a lot more than you would from checking the code .</tokentext>
<sentencetext>The sooner people realize that specialized Programmers are a thing of the past and that System Designers with DBA and Programming understanding will be the future the better.
Microsoft already has an application creator based on your DB and the full ability to customize your template for the app creator so you can fix bugs in the root and deploy that template out for any web application you have.
This is the future and debugging and documenting the logic and syntax of the code is a waste of time.
Document out the flows and build the DB first and then the program 2nd and rely on the database instead of the actual program will save companies millions in the long run.
Local Windows applications and Web Applications are going to merge soon into 1 platform that is universal and the sooner you prepare for this the better.
Check your design and database that follows that design, you will get a whole heck of a lot more than you would from checking the code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325137</id>
	<title>Productivity</title>
	<author>Tim12s</author>
	<datestamp>1245010740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The biggest problem with today's code is yesterday's code.</p><p>If you want to be productive you must have good code to begin with.</p><p>Its very difficult to start doing things correctly when you're working with code that is a ball of mud.</p></htmltext>
<tokenext>The biggest problem with today 's code is yesterday 's code.If you want to be productive you must have good code to begin with.Its very difficult to start doing things correctly when you 're working with code that is a ball of mud .</tokentext>
<sentencetext>The biggest problem with today's code is yesterday's code.If you want to be productive you must have good code to begin with.Its very difficult to start doing things correctly when you're working with code that is a ball of mud.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28333895</id>
	<title>Re:Delusions of grandeur</title>
	<author>alephnull42</author>
	<datestamp>1245072600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The problems you describe under "capital-M Methodologies" sound similar to "Cargo Cult Software Engineering" <a href="http://stevemcconnell.com/ieeesoftware/eic10.htm" title="stevemcconnell.com" rel="nofollow">http://stevemcconnell.com/ieeesoftware/eic10.htm</a> [stevemcconnell.com]</htmltext>
<tokenext>The problems you describe under " capital-M Methodologies " sound similar to " Cargo Cult Software Engineering " http : //stevemcconnell.com/ieeesoftware/eic10.htm [ stevemcconnell.com ]</tokentext>
<sentencetext>The problems you describe under "capital-M Methodologies" sound similar to "Cargo Cult Software Engineering" http://stevemcconnell.com/ieeesoftware/eic10.htm [stevemcconnell.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28337949</id>
	<title>Re:Yes!</title>
	<author>Anonymous</author>
	<datestamp>1245092880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>This is especially true if you have a wide mix of skill levels in your development staff.  It is a must if you have new programmers right out of college or contractors.</p></htmltext>
<tokenext>This is especially true if you have a wide mix of skill levels in your development staff .
It is a must if you have new programmers right out of college or contractors .</tokentext>
<sentencetext>This is especially true if you have a wide mix of skill levels in your development staff.
It is a must if you have new programmers right out of college or contractors.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28330761</id>
	<title>Re:Depends what you are reviewing</title>
	<author>Anonymous</author>
	<datestamp>1244988960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>no, that's not ok! As is not ok to buy a car with wheels falling off or having a surgery and the surgeon forgetting something inside you. So why should it be ok to have software full of bugs? I don't understand...</p><p>Use code reviews or whatever works for you. For me is TDD and pairing but we have to start raising the bar of the software quality of our industry.</p></htmltext>
<tokenext>no , that 's not ok !
As is not ok to buy a car with wheels falling off or having a surgery and the surgeon forgetting something inside you .
So why should it be ok to have software full of bugs ?
I do n't understand...Use code reviews or whatever works for you .
For me is TDD and pairing but we have to start raising the bar of the software quality of our industry .</tokentext>
<sentencetext>no, that's not ok!
As is not ok to buy a car with wheels falling off or having a surgery and the surgeon forgetting something inside you.
So why should it be ok to have software full of bugs?
I don't understand...Use code reviews or whatever works for you.
For me is TDD and pairing but we have to start raising the bar of the software quality of our industry.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327227</id>
	<title>Are code reviews a panacea?</title>
	<author>lsatenstein</author>
	<datestamp>1245001740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>When I did code reviews, I first had to understand the problem being solved. Then, I did a walk through for a) function descriptions being documented, either by being apparent, or with explanation.  I would verify that all return codes were being verified, and that an error return code was posted to a log, as well as being displayed.

The result of that practice was 1) programmer had one or two bug reports on his desk the first week, and half the amount in the second, and by the third week, the program was considered clean. Month end programs were expected to be clean after 3 or 4 uses.

yes, they are worth it.</htmltext>
<tokenext>When I did code reviews , I first had to understand the problem being solved .
Then , I did a walk through for a ) function descriptions being documented , either by being apparent , or with explanation .
I would verify that all return codes were being verified , and that an error return code was posted to a log , as well as being displayed .
The result of that practice was 1 ) programmer had one or two bug reports on his desk the first week , and half the amount in the second , and by the third week , the program was considered clean .
Month end programs were expected to be clean after 3 or 4 uses .
yes , they are worth it .</tokentext>
<sentencetext>When I did code reviews, I first had to understand the problem being solved.
Then, I did a walk through for a) function descriptions being documented, either by being apparent, or with explanation.
I would verify that all return codes were being verified, and that an error return code was posted to a log, as well as being displayed.
The result of that practice was 1) programmer had one or two bug reports on his desk the first week, and half the amount in the second, and by the third week, the program was considered clean.
Month end programs were expected to be clean after 3 or 4 uses.
yes, they are worth it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323035</id>
	<title>Definitely yes</title>
	<author>oblivious</author>
	<datestamp>1244893320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Code reviews are worth it, you just need to figure out how to do them so they aren't a pain and are useful.  Keep in mind that pair programming is continuous code review, and is a good thing if at least one of the pair is a senior developer.  The formal, get in a room, and review all the code since X is a waste of time.  My team is fairly small, I have two scrum teams of 5 developers each.  For code review, we have version control set up to mail all commit summaries to everyone on the team.  One of the duties of the scrum master is to review all commit summaries from both teams, and bring up any problems with the team member.  This is generally just a forward of the commit summary to the appropriate developer with comments in the email, and cc to the team.  I found this works extremely well and does not interrupt the work flow at all.</p></htmltext>
<tokenext>Code reviews are worth it , you just need to figure out how to do them so they are n't a pain and are useful .
Keep in mind that pair programming is continuous code review , and is a good thing if at least one of the pair is a senior developer .
The formal , get in a room , and review all the code since X is a waste of time .
My team is fairly small , I have two scrum teams of 5 developers each .
For code review , we have version control set up to mail all commit summaries to everyone on the team .
One of the duties of the scrum master is to review all commit summaries from both teams , and bring up any problems with the team member .
This is generally just a forward of the commit summary to the appropriate developer with comments in the email , and cc to the team .
I found this works extremely well and does not interrupt the work flow at all .</tokentext>
<sentencetext>Code reviews are worth it, you just need to figure out how to do them so they aren't a pain and are useful.
Keep in mind that pair programming is continuous code review, and is a good thing if at least one of the pair is a senior developer.
The formal, get in a room, and review all the code since X is a waste of time.
My team is fairly small, I have two scrum teams of 5 developers each.
For code review, we have version control set up to mail all commit summaries to everyone on the team.
One of the duties of the scrum master is to review all commit summaries from both teams, and bring up any problems with the team member.
This is generally just a forward of the commit summary to the appropriate developer with comments in the email, and cc to the team.
I found this works extremely well and does not interrupt the work flow at all.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325893</id>
	<title>You get what you pay for</title>
	<author>ohmiccurmudgeon</author>
	<datestamp>1244986200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Over dozens of projects I've seen 2/3 of code reviews fail to yield tangible benefit, but the other  1/3 of the code reviews were wildly successful in finding defects.  Primary difference between the successful and failed reviews was homework.  In the effective reviews multiple reviewers spent about an hour before meeting to review the code in respect to a checklist of items to watch for.  Those checklists did not address formatting issues that can be corrected with a code beautifier.  At the review meeting each person presented their found defects, which led others to find other defects in a synergistic  effect.  The checklist itself was subject to review.  Because everyone, including the programmer whose code is under review are trained in the technique, there wasn't the usual defensiveness or the feeling everyone is ganging up on one person.   The expectation is that defects will be found.</p><p>The reviews that failed, failed for lack of preparation, lack of formal standards expressed in a easily digestible checklist, and a lack of training so the sessions degraded into carping sessions about one person not liking another's variable names.</p><p>A multiple person code review is an expensive proposition.  I'd use it only on critical code and on public facing documentation.</p></htmltext>
<tokenext>Over dozens of projects I 've seen 2/3 of code reviews fail to yield tangible benefit , but the other 1/3 of the code reviews were wildly successful in finding defects .
Primary difference between the successful and failed reviews was homework .
In the effective reviews multiple reviewers spent about an hour before meeting to review the code in respect to a checklist of items to watch for .
Those checklists did not address formatting issues that can be corrected with a code beautifier .
At the review meeting each person presented their found defects , which led others to find other defects in a synergistic effect .
The checklist itself was subject to review .
Because everyone , including the programmer whose code is under review are trained in the technique , there was n't the usual defensiveness or the feeling everyone is ganging up on one person .
The expectation is that defects will be found.The reviews that failed , failed for lack of preparation , lack of formal standards expressed in a easily digestible checklist , and a lack of training so the sessions degraded into carping sessions about one person not liking another 's variable names.A multiple person code review is an expensive proposition .
I 'd use it only on critical code and on public facing documentation .</tokentext>
<sentencetext>Over dozens of projects I've seen 2/3 of code reviews fail to yield tangible benefit, but the other  1/3 of the code reviews were wildly successful in finding defects.
Primary difference between the successful and failed reviews was homework.
In the effective reviews multiple reviewers spent about an hour before meeting to review the code in respect to a checklist of items to watch for.
Those checklists did not address formatting issues that can be corrected with a code beautifier.
At the review meeting each person presented their found defects, which led others to find other defects in a synergistic  effect.
The checklist itself was subject to review.
Because everyone, including the programmer whose code is under review are trained in the technique, there wasn't the usual defensiveness or the feeling everyone is ganging up on one person.
The expectation is that defects will be found.The reviews that failed, failed for lack of preparation, lack of formal standards expressed in a easily digestible checklist, and a lack of training so the sessions degraded into carping sessions about one person not liking another's variable names.A multiple person code review is an expensive proposition.
I'd use it only on critical code and on public facing documentation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322643</id>
	<title>Yes, yes, and then some</title>
	<author>QuoteMstr</author>
	<datestamp>1244889600000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Even the best programmers make mistakes. Having another set of eyes is <i>invaluable</i> for detecting bugs before they become problems. Having to explain in <i>words</i> the rationale for a design decision often helps you better understand your own design, and to see potential problems with it. Sometimes you come up with something better on the spot. Also, if you get hit by a bus, your fellow programmers can take over without having to reverse-engineer your thoughts. Please, more code reviews.</p></htmltext>
<tokenext>Even the best programmers make mistakes .
Having another set of eyes is invaluable for detecting bugs before they become problems .
Having to explain in words the rationale for a design decision often helps you better understand your own design , and to see potential problems with it .
Sometimes you come up with something better on the spot .
Also , if you get hit by a bus , your fellow programmers can take over without having to reverse-engineer your thoughts .
Please , more code reviews .</tokentext>
<sentencetext>Even the best programmers make mistakes.
Having another set of eyes is invaluable for detecting bugs before they become problems.
Having to explain in words the rationale for a design decision often helps you better understand your own design, and to see potential problems with it.
Sometimes you come up with something better on the spot.
Also, if you get hit by a bus, your fellow programmers can take over without having to reverse-engineer your thoughts.
Please, more code reviews.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324191</id>
	<title>Sure they're useful if done right</title>
	<author>NotSoHeavyD3</author>
	<datestamp>1244907720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Especially if the reviewer can force changes in other people's code as the result of it. I mean I had one where I had some logic that looked absolutely insane. This happened because I was using functions from another programmer and he had nonsensical return values which pretty much forced my hand. (I pointed this out to him but he refused to change it, claiming it was intentional.) The code reviewer asked why is it that way, I told him and he pretty much pulled rank and told the idiot to fix his code. (Unfortunately the idiot then had it in for me for the rest of the project and would go and whine and cry about every last little thing which didn't make things very good.)</htmltext>
<tokenext>Especially if the reviewer can force changes in other people 's code as the result of it .
I mean I had one where I had some logic that looked absolutely insane .
This happened because I was using functions from another programmer and he had nonsensical return values which pretty much forced my hand .
( I pointed this out to him but he refused to change it , claiming it was intentional .
) The code reviewer asked why is it that way , I told him and he pretty much pulled rank and told the idiot to fix his code .
( Unfortunately the idiot then had it in for me for the rest of the project and would go and whine and cry about every last little thing which did n't make things very good .
)</tokentext>
<sentencetext>Especially if the reviewer can force changes in other people's code as the result of it.
I mean I had one where I had some logic that looked absolutely insane.
This happened because I was using functions from another programmer and he had nonsensical return values which pretty much forced my hand.
(I pointed this out to him but he refused to change it, claiming it was intentional.
) The code reviewer asked why is it that way, I told him and he pretty much pulled rank and told the idiot to fix his code.
(Unfortunately the idiot then had it in for me for the rest of the project and would go and whine and cry about every last little thing which didn't make things very good.
)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323693</id>
	<title>Not for bug catching</title>
	<author>hardcode57</author>
	<datestamp>1244900400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You won't catch many bugs code-reading, but you will keep up the quality and maintainability of your code.</htmltext>
<tokenext>You wo n't catch many bugs code-reading , but you will keep up the quality and maintainability of your code .</tokentext>
<sentencetext>You won't catch many bugs code-reading, but you will keep up the quality and maintainability of your code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324995</id>
	<title>Re:Coding standards</title>
	<author>aug24</author>
	<datestamp>1244921580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'm curious (and don't want to start a war on something so trivial) but what strengths are there for return null?</htmltext>
<tokenext>I 'm curious ( and do n't want to start a war on something so trivial ) but what strengths are there for return null ?</tokentext>
<sentencetext>I'm curious (and don't want to start a war on something so trivial) but what strengths are there for return null?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322743</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323629</id>
	<title>Code reviews are for more than just finding bugs</title>
	<author>davebaum</author>
	<datestamp>1244899560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yes, code reviews are nominally about finding problems with the code, but they can also be used to...</p><p>* Share knowledge.  You can learn a lot of new things by looking at someone else's code.  Perhaps they use a library class you aren't familiar with, or have used a language feature in an elegant way.  Just as an artist will look at other artist's work as part of their growth, programmers shouldn't be working in complete isolation.  And even if you are the amazing guru that knows everything, then at least your teammates will be able to benefit from your vast knowledge.</p><p>* Ensure that every line of code has been seen by at least two people.  Code that has only been worked on and looked at by a single person is a liability.  If they leave the company (or project or whatever) you suddenly have this huge morass of code that nobody is familiar with, and you probably only start to realize this when there's a nasty bug that needs to be quickly fixed in that code.</p><p>* Tests can help with correctness, but do not necessarily make the code maintainable.  Even if your code is correct, if a question comes up in code review, then that's an indication that you need to write clearer code and/or better comments if you expect anyone else to be able to work on the code in your absence.</p><p>That being said, a bad code review is probably not worth it.  Keep the amount of code being reviewed at a single time relatively small.  Don't involve too many people - just one other person looking at the code will provide a lot of value at minimal cost.  If you start inviting managers and "process czars", then you're on the wrong track.  Review code promptly: one-on-one reviewer led discussion works well (they read your code and ask you questions as they go).  Code review tools can help, especially if the programmers are in different time zones.  Everyone needs to make reviews a priority - aim for 24 hour max turn-around on a review otherwise you'll find everyone always being blocked.  I think letting the author pick the reviewer(s) is important.  That way if someone is a complete jerk about code reviews, nobody will ever include them in the reviews and you have minimized the damage that person can cause.</p></htmltext>
<tokenext>Yes , code reviews are nominally about finding problems with the code , but they can also be used to... * Share knowledge .
You can learn a lot of new things by looking at someone else 's code .
Perhaps they use a library class you are n't familiar with , or have used a language feature in an elegant way .
Just as an artist will look at other artist 's work as part of their growth , programmers should n't be working in complete isolation .
And even if you are the amazing guru that knows everything , then at least your teammates will be able to benefit from your vast knowledge .
* Ensure that every line of code has been seen by at least two people .
Code that has only been worked on and looked at by a single person is a liability .
If they leave the company ( or project or whatever ) you suddenly have this huge morass of code that nobody is familiar with , and you probably only start to realize this when there 's a nasty bug that needs to be quickly fixed in that code .
* Tests can help with correctness , but do not necessarily make the code maintainable .
Even if your code is correct , if a question comes up in code review , then that 's an indication that you need to write clearer code and/or better comments if you expect anyone else to be able to work on the code in your absence.That being said , a bad code review is probably not worth it .
Keep the amount of code being reviewed at a single time relatively small .
Do n't involve too many people - just one other person looking at the code will provide a lot of value at minimal cost .
If you start inviting managers and " process czars " , then you 're on the wrong track .
Review code promptly : one-on-one reviewer led discussion works well ( they read your code and ask you questions as they go ) .
Code review tools can help , especially if the programmers are in different time zones .
Everyone needs to make reviews a priority - aim for 24 hour max turn-around on a review otherwise you 'll find everyone always being blocked .
I think letting the author pick the reviewer ( s ) is important .
That way if someone is a complete jerk about code reviews , nobody will ever include them in the reviews and you have minimized the damage that person can cause .</tokentext>
<sentencetext>Yes, code reviews are nominally about finding problems with the code, but they can also be used to...* Share knowledge.
You can learn a lot of new things by looking at someone else's code.
Perhaps they use a library class you aren't familiar with, or have used a language feature in an elegant way.
Just as an artist will look at other artist's work as part of their growth, programmers shouldn't be working in complete isolation.
And even if you are the amazing guru that knows everything, then at least your teammates will be able to benefit from your vast knowledge.
* Ensure that every line of code has been seen by at least two people.
Code that has only been worked on and looked at by a single person is a liability.
If they leave the company (or project or whatever) you suddenly have this huge morass of code that nobody is familiar with, and you probably only start to realize this when there's a nasty bug that needs to be quickly fixed in that code.
* Tests can help with correctness, but do not necessarily make the code maintainable.
Even if your code is correct, if a question comes up in code review, then that's an indication that you need to write clearer code and/or better comments if you expect anyone else to be able to work on the code in your absence.That being said, a bad code review is probably not worth it.
Keep the amount of code being reviewed at a single time relatively small.
Don't involve too many people - just one other person looking at the code will provide a lot of value at minimal cost.
If you start inviting managers and "process czars", then you're on the wrong track.
Review code promptly: one-on-one reviewer led discussion works well (they read your code and ask you questions as they go).
Code review tools can help, especially if the programmers are in different time zones.
Everyone needs to make reviews a priority - aim for 24 hour max turn-around on a review otherwise you'll find everyone always being blocked.
I think letting the author pick the reviewer(s) is important.
That way if someone is a complete jerk about code reviews, nobody will ever include them in the reviews and you have minimized the damage that person can cause.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322897</id>
	<title>Yes</title>
	<author>phil\_at\_.</author>
	<datestamp>1244891820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You may not "see" it in the sense of fixing UI bugs, but in the long run it saves you TONS of time. It ensures people code to an internal coding style document (you have one, right??) which makes code more readable and maintainable in the long run. It also, of course, can catch subtle bugs that may be compounded in time with new features. Together these saves tons of money and time in the long run. Don't be short-sighted.</htmltext>
<tokenext>You may not " see " it in the sense of fixing UI bugs , but in the long run it saves you TONS of time .
It ensures people code to an internal coding style document ( you have one , right ? ?
) which makes code more readable and maintainable in the long run .
It also , of course , can catch subtle bugs that may be compounded in time with new features .
Together these saves tons of money and time in the long run .
Do n't be short-sighted .</tokentext>
<sentencetext>You may not "see" it in the sense of fixing UI bugs, but in the long run it saves you TONS of time.
It ensures people code to an internal coding style document (you have one, right??
) which makes code more readable and maintainable in the long run.
It also, of course, can catch subtle bugs that may be compounded in time with new features.
Together these saves tons of money and time in the long run.
Don't be short-sighted.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322883</id>
	<title>Re:If you're code review is taking forever...</title>
	<author>SixAndFiftyThree</author>
	<datestamp>1244891760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>If I'm code review is taking forever, it's because I haven't documented I'm code.  So in a culture of constant code reviews, I remember to document.  Adding comments no longer wastes time; it *saves* time in the pretty near future.  I also write fewer lazy hacks than I used to, because of the fear of having to explain them. And my code gets better for other reasons mentioned on this thread.</p><p>The OP didn't explicitly say that they were reviewing code months after it had been written, but no, archaeology and programming don't mix any too well.  OTOH in a company where Hitting The Release Date is all-important, there is certainly a temptation to postpone until after that Date everything that can possibly be postponed, and pointy-haired types do think code review (and documentation) can be postponed.</p><p>What would you say to a teenage boy who thought putting on the condom could be postponed until after the<nobr> <wbr></nobr>... release?</p></htmltext>
<tokenext>If I 'm code review is taking forever , it 's because I have n't documented I 'm code .
So in a culture of constant code reviews , I remember to document .
Adding comments no longer wastes time ; it * saves * time in the pretty near future .
I also write fewer lazy hacks than I used to , because of the fear of having to explain them .
And my code gets better for other reasons mentioned on this thread.The OP did n't explicitly say that they were reviewing code months after it had been written , but no , archaeology and programming do n't mix any too well .
OTOH in a company where Hitting The Release Date is all-important , there is certainly a temptation to postpone until after that Date everything that can possibly be postponed , and pointy-haired types do think code review ( and documentation ) can be postponed.What would you say to a teenage boy who thought putting on the condom could be postponed until after the ... release ?</tokentext>
<sentencetext>If I'm code review is taking forever, it's because I haven't documented I'm code.
So in a culture of constant code reviews, I remember to document.
Adding comments no longer wastes time; it *saves* time in the pretty near future.
I also write fewer lazy hacks than I used to, because of the fear of having to explain them.
And my code gets better for other reasons mentioned on this thread.The OP didn't explicitly say that they were reviewing code months after it had been written, but no, archaeology and programming don't mix any too well.
OTOH in a company where Hitting The Release Date is all-important, there is certainly a temptation to postpone until after that Date everything that can possibly be postponed, and pointy-haired types do think code review (and documentation) can be postponed.What would you say to a teenage boy who thought putting on the condom could be postponed until after the ... release?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322675</id>
	<title>If you did test-driven development</title>
	<author>Jane Q. Public</author>
	<datestamp>1244889780000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext>then code reviews would be redundant. Sure, testing first is expensive. But probably no more expensive than code reviews. If you have a QA person or team checking the final product, then your bases are covered.</htmltext>
<tokenext>then code reviews would be redundant .
Sure , testing first is expensive .
But probably no more expensive than code reviews .
If you have a QA person or team checking the final product , then your bases are covered .</tokentext>
<sentencetext>then code reviews would be redundant.
Sure, testing first is expensive.
But probably no more expensive than code reviews.
If you have a QA person or team checking the final product, then your bases are covered.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322993</id>
	<title>Science</title>
	<author>felix rayman</author>
	<datestamp>1244892900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This has been studied extensively. Peer review of code is much better at finding bugs than QA testing.</p><p>If you release code without QA testing and the process works for you, fine, you can consider releasing code without peer review.</p><p>If you wouldn't consider releasing code without testing, but currently release it without peer review, you are batshit insane. Sucks to be you. Sucks even more to be your support department.</p></htmltext>
<tokenext>This has been studied extensively .
Peer review of code is much better at finding bugs than QA testing.If you release code without QA testing and the process works for you , fine , you can consider releasing code without peer review.If you would n't consider releasing code without testing , but currently release it without peer review , you are batshit insane .
Sucks to be you .
Sucks even more to be your support department .</tokentext>
<sentencetext>This has been studied extensively.
Peer review of code is much better at finding bugs than QA testing.If you release code without QA testing and the process works for you, fine, you can consider releasing code without peer review.If you wouldn't consider releasing code without testing, but currently release it without peer review, you are batshit insane.
Sucks to be you.
Sucks even more to be your support department.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326487</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>gnasher719</author>
	<datestamp>1244994000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>I don't think defects are the only metric. Code reviews can result in a cleaner codebase that's easier to understand. Everyone occasionally writes bad code. A reviewer might say, "I see that it works, but I don't like it..." and mention an alternative solution. A reviewer might suggest that something is non-obvious and that a comment is warranted. Code reviews aren't just for bugs, they are to get better code.</p></div><p>Another important aspect is that code that is going to be reviewed will be better in the first place than code that isn't going to be reviewed. So it is quite possible that no bugs or code ugliness will be found in the code review, because the developer worked more carefully and removed the bugs \_before\_ the code review.</p></div>
	</htmltext>
<tokenext>I do n't think defects are the only metric .
Code reviews can result in a cleaner codebase that 's easier to understand .
Everyone occasionally writes bad code .
A reviewer might say , " I see that it works , but I do n't like it... " and mention an alternative solution .
A reviewer might suggest that something is non-obvious and that a comment is warranted .
Code reviews are n't just for bugs , they are to get better code.Another important aspect is that code that is going to be reviewed will be better in the first place than code that is n't going to be reviewed .
So it is quite possible that no bugs or code ugliness will be found in the code review , because the developer worked more carefully and removed the bugs \ _before \ _ the code review .</tokentext>
<sentencetext>I don't think defects are the only metric.
Code reviews can result in a cleaner codebase that's easier to understand.
Everyone occasionally writes bad code.
A reviewer might say, "I see that it works, but I don't like it..." and mention an alternative solution.
A reviewer might suggest that something is non-obvious and that a comment is warranted.
Code reviews aren't just for bugs, they are to get better code.Another important aspect is that code that is going to be reviewed will be better in the first place than code that isn't going to be reviewed.
So it is quite possible that no bugs or code ugliness will be found in the code review, because the developer worked more carefully and removed the bugs \_before\_ the code review.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322779</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322921</id>
	<title>I think it's worked well.</title>
	<author>dgcaste</author>
	<datestamp>1244892120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Our shareholders do our code reviews.
<br> <br>
Steve B.</htmltext>
<tokenext>Our shareholders do our code reviews .
Steve B .</tokentext>
<sentencetext>Our shareholders do our code reviews.
Steve B.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325325</id>
	<title>Re:Are they worth it?</title>
	<author>johannesg</author>
	<datestamp>1244972220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>No.</p><p>Discussion over, everyone go home.</p></div><p>And people wonder why geeks are reputed to have bad communication skills.</p><p>If you are also suffering from such a reputation, here's an idea on how to improve things: when someone asks a serious question don't just say "no" without stating any reasons or even looking up from your keyboard. Instead, look up from your keyboard (*and* stop typing!), look thoughtfully to the person asking the question, and begin with "that's a pretty interesting question. But in my opinion, that's not the case, because<nobr> <wbr></nobr>..." And then you provide a list of reasons.</p><p>Sure, you waste time when talking to "idiots" like this. But you will find that people will like you a lot more, and start to accept you as a human being as well. And who knows, maybe one day it will lead to an encounter with the opposite sex.</p><p>See? You really *can* learn useful things on slashdot!</p></div>
	</htmltext>
<tokenext>No.Discussion over , everyone go home.And people wonder why geeks are reputed to have bad communication skills.If you are also suffering from such a reputation , here 's an idea on how to improve things : when someone asks a serious question do n't just say " no " without stating any reasons or even looking up from your keyboard .
Instead , look up from your keyboard ( * and * stop typing !
) , look thoughtfully to the person asking the question , and begin with " that 's a pretty interesting question .
But in my opinion , that 's not the case , because ... " And then you provide a list of reasons.Sure , you waste time when talking to " idiots " like this .
But you will find that people will like you a lot more , and start to accept you as a human being as well .
And who knows , maybe one day it will lead to an encounter with the opposite sex.See ?
You really * can * learn useful things on slashdot !</tokentext>
<sentencetext>No.Discussion over, everyone go home.And people wonder why geeks are reputed to have bad communication skills.If you are also suffering from such a reputation, here's an idea on how to improve things: when someone asks a serious question don't just say "no" without stating any reasons or even looking up from your keyboard.
Instead, look up from your keyboard (*and* stop typing!
), look thoughtfully to the person asking the question, and begin with "that's a pretty interesting question.
But in my opinion, that's not the case, because ..." And then you provide a list of reasons.Sure, you waste time when talking to "idiots" like this.
But you will find that people will like you a lot more, and start to accept you as a human being as well.
And who knows, maybe one day it will lead to an encounter with the opposite sex.See?
You really *can* learn useful things on slashdot!
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322685</id>
	<title>accountability</title>
	<author>dawilcox</author>
	<datestamp>1244889840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Even if bugs are not found during code reviews, code reviews help the developers know that they are accountable for their code.</htmltext>
<tokenext>Even if bugs are not found during code reviews , code reviews help the developers know that they are accountable for their code .</tokentext>
<sentencetext>Even if bugs are not found during code reviews, code reviews help the developers know that they are accountable for their code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323291</id>
	<title>Absolutely</title>
	<author>dFaust</author>
	<datestamp>1244896200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I've actually been going through the process of getting code reviews as a standard process on my own team.  We've done them now and again in the past - often on other team's code that was being integrated into our platform - and it was typically a pain.
</p><p>
Enter A Good Tool(TM).  We've been demoing some code review software lately and after settling on a particular tool that we find to work well with our workflow, the team has unanimously agreed that they find reviews beneficial.  We don't have strict policies on how/when reviews are done, so it's encouraging when you see people are creating new reviews for their code of their own volition.
</p><p>
While we haven't found a lot of critical bugs, we have found lots of minor things, problems/shortcomings in unit tests, documentation problems (especially important because we provide libraries to other teams, we're not the sole users of the code), and even pre-existing bugs while doing maintenance.  I think the biggest benefits, though, have been getting more eyes on the code to increase familiarity with it so it's easier for other people to do maintenance and bug fixes on when the original author is unable to as well as just generally opening up broader communication about various elements of style, consistency, improving code readability, etc.
</p><p>
The software says we've logged about 16 hours in the past month, across 7 developers.  That's a pretty minimal investment.  There was mention of good functional testing being all you really need, but if you're working on libraries and such it's easy to have bugs that don't show themselves in all usage scenarios.  If well after a release another team manages to find a previously unnoticed bug in a library, the cost for them to track it down to our code, for us to fix it, put through QA, do a new release, pass off to the other team who then has to put their component through QA and deploy.... we've just burnt through a lot of time and money.
</p><p>
Will code reviews lead to perfect code?  No.  But I would undoubtedly say that there are plenty of benefits that make them well worth it if they're done in an effective fashion.
</p><p>
By the way, the software we settled on is <a href="http://smartbear.com/codecollab.php" title="smartbear.com">Smart Bear's Code Collaborator</a> [smartbear.com], having also tried <a href="http://www.atlassian.com/software/crucible/" title="atlassian.com">Crucible</a> [atlassian.com] and <a href="http://review-board.org/" title="review-board.org">Review Board</a> [review-board.org] as well as talking to other divisions about their experiences with code review software. It may not be the right tool for you, but we found it lets us bust through both initial reviews of the code as well as follow-up reviews to ensure any issues are being resolved appropriately. It's not the cheapest, but if it's the difference between a tool people will willingly use or a tool/process that people will bemoan, it's worth it.</p></htmltext>
<tokenext>I 've actually been going through the process of getting code reviews as a standard process on my own team .
We 've done them now and again in the past - often on other team 's code that was being integrated into our platform - and it was typically a pain .
Enter A Good Tool ( TM ) .
We 've been demoing some code review software lately and after settling on a particular tool that we find to work well with our workflow , the team has unanimously agreed that they find reviews beneficial .
We do n't have strict policies on how/when reviews are done , so it 's encouraging when you see people are creating new reviews for their code of their own volition .
While we have n't found a lot of critical bugs , we have found lots of minor things , problems/shortcomings in unit tests , documentation problems ( especially important because we provide libraries to other teams , we 're not the sole users of the code ) , and even pre-existing bugs while doing maintenance .
I think the biggest benefits , though , have been getting more eyes on the code to increase familiarity with it so it 's easier for other people to do maintenance and bug fixes on when the original author is unable to as well as just generally opening up broader communication about various elements of style , consistency , improving code readability , etc .
The software says we 've logged about 16 hours in the past month , across 7 developers .
That 's a pretty minimal investment .
There was mention of good functional testing being all you really need , but if you 're working on libraries and such it 's easy to have bugs that do n't show themselves in all usage scenarios .
If well after a release another team manages to find a previously unnoticed bug in a library , the cost for them to track it down to our code , for us to fix it , put through QA , do a new release , pass off to the other team who then has to put their component through QA and deploy.... we 've just burnt through a lot of time and money .
Will code reviews lead to perfect code ?
No. But I would undoubtedly say that there are plenty of benefits that make them well worth it if they 're done in an effective fashion .
By the way , the software we settled on is Smart Bear 's Code Collaborator [ smartbear.com ] , having also tried Crucible [ atlassian.com ] and Review Board [ review-board.org ] as well as talking to other divisions about their experiences with code review software .
It may not be the right tool for you , but we found it lets us bust through both initial reviews of the code as well as follow-up reviews to ensure any issues are being resolved appropriately .
It 's not the cheapest , but if it 's the difference between a tool people will willingly use or a tool/process that people will bemoan , it 's worth it .</tokentext>
<sentencetext>I've actually been going through the process of getting code reviews as a standard process on my own team.
We've done them now and again in the past - often on other team's code that was being integrated into our platform - and it was typically a pain.
Enter A Good Tool(TM).
We've been demoing some code review software lately and after settling on a particular tool that we find to work well with our workflow, the team has unanimously agreed that they find reviews beneficial.
We don't have strict policies on how/when reviews are done, so it's encouraging when you see people are creating new reviews for their code of their own volition.
While we haven't found a lot of critical bugs, we have found lots of minor things, problems/shortcomings in unit tests, documentation problems (especially important because we provide libraries to other teams, we're not the sole users of the code), and even pre-existing bugs while doing maintenance.
I think the biggest benefits, though, have been getting more eyes on the code to increase familiarity with it so it's easier for other people to do maintenance and bug fixes on when the original author is unable to as well as just generally opening up broader communication about various elements of style, consistency, improving code readability, etc.
The software says we've logged about 16 hours in the past month, across 7 developers.
That's a pretty minimal investment.
There was mention of good functional testing being all you really need, but if you're working on libraries and such it's easy to have bugs that don't show themselves in all usage scenarios.
If well after a release another team manages to find a previously unnoticed bug in a library, the cost for them to track it down to our code, for us to fix it, put through QA, do a new release, pass off to the other team who then has to put their component through QA and deploy.... we've just burnt through a lot of time and money.
Will code reviews lead to perfect code?
No.  But I would undoubtedly say that there are plenty of benefits that make them well worth it if they're done in an effective fashion.
By the way, the software we settled on is Smart Bear's Code Collaborator [smartbear.com], having also tried Crucible [atlassian.com] and Review Board [review-board.org] as well as talking to other divisions about their experiences with code review software.
It may not be the right tool for you, but we found it lets us bust through both initial reviews of the code as well as follow-up reviews to ensure any issues are being resolved appropriately.
It's not the cheapest, but if it's the difference between a tool people will willingly use or a tool/process that people will bemoan, it's worth it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325085</id>
	<title>Re:Dijkstra's troll</title>
	<author>Omnifarious</author>
	<datestamp>1245009660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In my opinion that's the result of people substituting arbitrary rules and stupid policy for human judgement.  That's not how good code is written.  Code is a craft, not wholly an art or an engineering discipline but something of both.</p><p>And simply completely avoiding the use of <tt>?:</tt> or (in C++) the <tt>struct</tt> keyword is, again, substituting arbitrary rules for judgement.  They are both useful constructs that are perfectly valid in certain situations.</p></htmltext>
<tokenext>In my opinion that 's the result of people substituting arbitrary rules and stupid policy for human judgement .
That 's not how good code is written .
Code is a craft , not wholly an art or an engineering discipline but something of both.And simply completely avoiding the use of ?
: or ( in C + + ) the struct keyword is , again , substituting arbitrary rules for judgement .
They are both useful constructs that are perfectly valid in certain situations .</tokentext>
<sentencetext>In my opinion that's the result of people substituting arbitrary rules and stupid policy for human judgement.
That's not how good code is written.
Code is a craft, not wholly an art or an engineering discipline but something of both.And simply completely avoiding the use of ?
: or (in C++) the struct keyword is, again, substituting arbitrary rules for judgement.
They are both useful constructs that are perfectly valid in certain situations.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323199</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322601</id>
	<title>When done right</title>
	<author>El\_Muerte\_TDS</author>
	<datestamp>1244889360000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>Code Reviews are useful when they are done right. But before you start using code reviews you should introduce automated static analysis of the code during the builds. A lot of crap can be discovered by static analysis. This saves you a lot of effort on the tedious parts of code reviews.</p></htmltext>
<tokenext>Code Reviews are useful when they are done right .
But before you start using code reviews you should introduce automated static analysis of the code during the builds .
A lot of crap can be discovered by static analysis .
This saves you a lot of effort on the tedious parts of code reviews .</tokentext>
<sentencetext>Code Reviews are useful when they are done right.
But before you start using code reviews you should introduce automated static analysis of the code during the builds.
A lot of crap can be discovered by static analysis.
This saves you a lot of effort on the tedious parts of code reviews.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325105</id>
	<title>Re:Are they worth it?</title>
	<author>uncqual</author>
	<datestamp>1245009900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Huh?
<br> <br>
It completely depends on the impact of a software failure...
<br> <br>
Critical Space Shuttle software and Medical Radiotherapy software which can kill people and politically poison useful programs  - yes.
<br> <br>
DBMS core which can corrupt data and/or return wrong results resulting in millions of dollars of cost to a customer - yes.
<br> <br>
A GUI component which at worst will leave a few pixels of GUI Poo on an in-house application or require backing down to the prior release - not so much (well, probably not at all).</htmltext>
<tokenext>Huh ?
It completely depends on the impact of a software failure.. . Critical Space Shuttle software and Medical Radiotherapy software which can kill people and politically poison useful programs - yes .
DBMS core which can corrupt data and/or return wrong results resulting in millions of dollars of cost to a customer - yes .
A GUI component which at worst will leave a few pixels of GUI Poo on an in-house application or require backing down to the prior release - not so much ( well , probably not at all ) .</tokentext>
<sentencetext>Huh?
It completely depends on the impact of a software failure...
 
Critical Space Shuttle software and Medical Radiotherapy software which can kill people and politically poison useful programs  - yes.
DBMS core which can corrupt data and/or return wrong results resulting in millions of dollars of cost to a customer - yes.
A GUI component which at worst will leave a few pixels of GUI Poo on an in-house application or require backing down to the prior release - not so much (well, probably not at all).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324201</id>
	<title>Code Reviews via the web</title>
	<author>787style</author>
	<datestamp>1244907900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>We have recently started doing code reviews using an online tools that ties very nicely into our SCM tool.  All code changes have an associated defect or enhancement ID, are developed on a private branch, and prior to being integrated into the trunk have to be review by a member of a pool of subject matter experts.  Since the team is world wide, having a web system to communicate between the various sites allows for faster response time, and helps ensure consistency in standards throughout the regions.</p><p>The product is by a company named Smartbear, called CodeCollaborator.  Very pleased so far, <a href="http://smartbear.com/" title="smartbear.com">http://smartbear.com/</a> [smartbear.com].</p></htmltext>
<tokenext>We have recently started doing code reviews using an online tools that ties very nicely into our SCM tool .
All code changes have an associated defect or enhancement ID , are developed on a private branch , and prior to being integrated into the trunk have to be review by a member of a pool of subject matter experts .
Since the team is world wide , having a web system to communicate between the various sites allows for faster response time , and helps ensure consistency in standards throughout the regions.The product is by a company named Smartbear , called CodeCollaborator .
Very pleased so far , http : //smartbear.com/ [ smartbear.com ] .</tokentext>
<sentencetext>We have recently started doing code reviews using an online tools that ties very nicely into our SCM tool.
All code changes have an associated defect or enhancement ID, are developed on a private branch, and prior to being integrated into the trunk have to be review by a member of a pool of subject matter experts.
Since the team is world wide, having a web system to communicate between the various sites allows for faster response time, and helps ensure consistency in standards throughout the regions.The product is by a company named Smartbear, called CodeCollaborator.
Very pleased so far, http://smartbear.com/ [smartbear.com].</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28331323</id>
	<title>Re:a fucktonne?</title>
	<author>TheSam</author>
	<datestamp>1244995200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Damn europeans and their metric system.</p><p>How many shitloads are in a fucktonne?</p></div><p>42, duh</p></div>
	</htmltext>
<tokenext>Damn europeans and their metric system.How many shitloads are in a fucktonne ? 42 , duh</tokentext>
<sentencetext>Damn europeans and their metric system.How many shitloads are in a fucktonne?42, duh
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322931</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>DrLang21</author>
	<datestamp>1244892240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I think this needs to be done with great care.  Suggestions can always be made, but if you halt progress to fix some code that works reliably for the sake of cleanliness, you can quickly get bogged down in word-smithing that adds little value.  Findings in code reviews need to be prioritized.  If it works but is written a bit ugly, make a note of it.  If it works but has unacceptable holes in it, put it on a moderate priority.  If it does not do what is intended at all, put it at the top of the list. And so on.</htmltext>
<tokenext>I think this needs to be done with great care .
Suggestions can always be made , but if you halt progress to fix some code that works reliably for the sake of cleanliness , you can quickly get bogged down in word-smithing that adds little value .
Findings in code reviews need to be prioritized .
If it works but is written a bit ugly , make a note of it .
If it works but has unacceptable holes in it , put it on a moderate priority .
If it does not do what is intended at all , put it at the top of the list .
And so on .</tokentext>
<sentencetext>I think this needs to be done with great care.
Suggestions can always be made, but if you halt progress to fix some code that works reliably for the sake of cleanliness, you can quickly get bogged down in word-smithing that adds little value.
Findings in code reviews need to be prioritized.
If it works but is written a bit ugly, make a note of it.
If it works but has unacceptable holes in it, put it on a moderate priority.
If it does not do what is intended at all, put it at the top of the list.
And so on.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322779</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322639</id>
	<title>Why is this not under Ask Slashdot?</title>
	<author>Anonymous</author>
	<datestamp>1244889600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just wondering</p></htmltext>
<tokenext>Just wondering</tokentext>
<sentencetext>Just wondering</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322625</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>Skuld-Chan</author>
	<datestamp>1244889480000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Sadly every security vulnerability on the products I've worked on were found after shipping in code that was reviewed (and not only that - sometimes very obvious bugs - like treating strings as fixed values, and not checking or sanitizing inputs).</p><p>So I guess they either have to be done right, or they aren't all that useful.</p></htmltext>
<tokenext>Sadly every security vulnerability on the products I 've worked on were found after shipping in code that was reviewed ( and not only that - sometimes very obvious bugs - like treating strings as fixed values , and not checking or sanitizing inputs ) .So I guess they either have to be done right , or they are n't all that useful .</tokentext>
<sentencetext>Sadly every security vulnerability on the products I've worked on were found after shipping in code that was reviewed (and not only that - sometimes very obvious bugs - like treating strings as fixed values, and not checking or sanitizing inputs).So I guess they either have to be done right, or they aren't all that useful.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323643</id>
	<title>I like having my code reviewed</title>
	<author>HomerJ</author>
	<datestamp>1244899920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Which goes against the thinking for a lot of developers. They seem to take reviews of code personally, and believe everything they did is correct.</p><p>I go the other way. If my code is good, it will stand the test of a review. If one or a group of my colleagues looks at my code and doesn't find a fault then I KNOW it's good. I don't have to just THINK it because I believe so. If I can't explain why I did something in a review, it shouldn't get into production code.</p><p>Sometimes it's even simple stuff. I Do X, and someone goes "oh, we had to do it too, and wrote this bunch of code for it. Maybe we could combine the code into one usable module for both". It's stuff like that you can only really do in a good code review. It shouldn't JUST be done at a commit. It's something that should be part of the development process.</p></htmltext>
<tokenext>Which goes against the thinking for a lot of developers .
They seem to take reviews of code personally , and believe everything they did is correct.I go the other way .
If my code is good , it will stand the test of a review .
If one or a group of my colleagues looks at my code and does n't find a fault then I KNOW it 's good .
I do n't have to just THINK it because I believe so .
If I ca n't explain why I did something in a review , it should n't get into production code.Sometimes it 's even simple stuff .
I Do X , and someone goes " oh , we had to do it too , and wrote this bunch of code for it .
Maybe we could combine the code into one usable module for both " .
It 's stuff like that you can only really do in a good code review .
It should n't JUST be done at a commit .
It 's something that should be part of the development process .</tokentext>
<sentencetext>Which goes against the thinking for a lot of developers.
They seem to take reviews of code personally, and believe everything they did is correct.I go the other way.
If my code is good, it will stand the test of a review.
If one or a group of my colleagues looks at my code and doesn't find a fault then I KNOW it's good.
I don't have to just THINK it because I believe so.
If I can't explain why I did something in a review, it shouldn't get into production code.Sometimes it's even simple stuff.
I Do X, and someone goes "oh, we had to do it too, and wrote this bunch of code for it.
Maybe we could combine the code into one usable module for both".
It's stuff like that you can only really do in a good code review.
It shouldn't JUST be done at a commit.
It's something that should be part of the development process.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325129</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>piojo</author>
	<datestamp>1245010620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><nobr> <wbr></nobr></p><div class="quote"><p>...if you halt progress to fix some code that works reliably for the sake of cleanliness, you can quickly get bogged down in word-smithing that adds little value.</p></div><p>I agree--this happened to me, in fact, when I wrote a minor feature for an open source project. Several times there was always a reply to my patch saying, "you should fix this", or "yeah, but it would be nice if you did this, too..." It was kind of disheartening... but I still like code reviews, in general.</p></div>
	</htmltext>
<tokenext>...if you halt progress to fix some code that works reliably for the sake of cleanliness , you can quickly get bogged down in word-smithing that adds little value.I agree--this happened to me , in fact , when I wrote a minor feature for an open source project .
Several times there was always a reply to my patch saying , " you should fix this " , or " yeah , but it would be nice if you did this , too... " It was kind of disheartening... but I still like code reviews , in general .</tokentext>
<sentencetext> ...if you halt progress to fix some code that works reliably for the sake of cleanliness, you can quickly get bogged down in word-smithing that adds little value.I agree--this happened to me, in fact, when I wrote a minor feature for an open source project.
Several times there was always a reply to my patch saying, "you should fix this", or "yeah, but it would be nice if you did this, too..." It was kind of disheartening... but I still like code reviews, in general.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322931</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322955</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>Anonymous</author>
	<datestamp>1244892540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>And as much as we \_hate\_ the word... I have to say it...</p><p>METRICS!</p></div><p>Here in the U.S. we still use the &quot;Imperial&quot; system- The person with the most power makes the decision.</p></div>
	</htmltext>
<tokenext>And as much as we \ _hate \ _ the word... I have to say it...METRICS ! Here in the U.S. we still use the " Imperial " system- The person with the most power makes the decision .</tokentext>
<sentencetext>And as much as we \_hate\_ the word... I have to say it...METRICS!Here in the U.S. we still use the "Imperial" system- The person with the most power makes the decision.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323107</id>
	<title>Re:If you're code review is taking forever...</title>
	<author>Anonymous</author>
	<datestamp>1244894160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>ABSOLUTELY RIGHT!</p></htmltext>
<tokenext>ABSOLUTELY RIGHT !</tokentext>
<sentencetext>ABSOLUTELY RIGHT!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323505</id>
	<title>Ask your developers</title>
	<author>wrook</author>
	<datestamp>1244898420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Lots of good replies here, so I won't touch on whether or not code reviews are beneficial.  But one thing jumps out at me from the question:</p><p>"I'm a development manager... I asked my boss to consider whether it was worth spending so much time on examining built code..."</p><p>I hate to say it, but you are the wrong people to be considering this question.  Code reviews are for programmers.  It's good to hear that your reviews are developer led, but you've got some serious problems if you are trying to make this decision on your own.  In fact, I'd go so far as to say that you have serious problems if you are attempting to make this decision at all.</p><p>Certainly, a development manager's role will involve some coaching (unless you hire a senior developer whose job is specifically geared to coaching the developers -- something I highly recommend).  In that coaching role, you could of course guide inexperienced developers towards practices that work well for the team.  But at some point practices should be self-selected.  The developers can see much better than you can what is worth doing and what isn't.</p><p>It's appropriate to gather metrics and ask question about what is effective and what isn't.  It can be a launching point for good discussion.  But if your opinion of your developers is so low that you think you should make this decision, then you've got problems.  Either you need to replace your developers or (more likely) get an attitude adjustment.</p></htmltext>
<tokenext>Lots of good replies here , so I wo n't touch on whether or not code reviews are beneficial .
But one thing jumps out at me from the question : " I 'm a development manager... I asked my boss to consider whether it was worth spending so much time on examining built code... " I hate to say it , but you are the wrong people to be considering this question .
Code reviews are for programmers .
It 's good to hear that your reviews are developer led , but you 've got some serious problems if you are trying to make this decision on your own .
In fact , I 'd go so far as to say that you have serious problems if you are attempting to make this decision at all.Certainly , a development manager 's role will involve some coaching ( unless you hire a senior developer whose job is specifically geared to coaching the developers -- something I highly recommend ) .
In that coaching role , you could of course guide inexperienced developers towards practices that work well for the team .
But at some point practices should be self-selected .
The developers can see much better than you can what is worth doing and what is n't.It 's appropriate to gather metrics and ask question about what is effective and what is n't .
It can be a launching point for good discussion .
But if your opinion of your developers is so low that you think you should make this decision , then you 've got problems .
Either you need to replace your developers or ( more likely ) get an attitude adjustment .</tokentext>
<sentencetext>Lots of good replies here, so I won't touch on whether or not code reviews are beneficial.
But one thing jumps out at me from the question:"I'm a development manager... I asked my boss to consider whether it was worth spending so much time on examining built code..."I hate to say it, but you are the wrong people to be considering this question.
Code reviews are for programmers.
It's good to hear that your reviews are developer led, but you've got some serious problems if you are trying to make this decision on your own.
In fact, I'd go so far as to say that you have serious problems if you are attempting to make this decision at all.Certainly, a development manager's role will involve some coaching (unless you hire a senior developer whose job is specifically geared to coaching the developers -- something I highly recommend).
In that coaching role, you could of course guide inexperienced developers towards practices that work well for the team.
But at some point practices should be self-selected.
The developers can see much better than you can what is worth doing and what isn't.It's appropriate to gather metrics and ask question about what is effective and what isn't.
It can be a launching point for good discussion.
But if your opinion of your developers is so low that you think you should make this decision, then you've got problems.
Either you need to replace your developers or (more likely) get an attitude adjustment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324873</id>
	<title>Security Camera Effect</title>
	<author>zuperduperman</author>
	<datestamp>1244918820000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>The primary effect of code reviews has nothing to do with finding problems during the review itself.  It improves quality before the code ever gets to review, because people care far more about what they do in the first place if they know there is even a chance others will see and criticize them later for doing it wrong.</p><p>This is why stores put up fake security cameras.  The notion that they have someone sitting there watching the camera continuously is ridiculous, yet a camera has a huge effect on people's tendency to commit crimes nonetheless.</p></htmltext>
<tokenext>The primary effect of code reviews has nothing to do with finding problems during the review itself .
It improves quality before the code ever gets to review , because people care far more about what they do in the first place if they know there is even a chance others will see and criticize them later for doing it wrong.This is why stores put up fake security cameras .
The notion that they have someone sitting there watching the camera continuously is ridiculous , yet a camera has a huge effect on people 's tendency to commit crimes nonetheless .</tokentext>
<sentencetext>The primary effect of code reviews has nothing to do with finding problems during the review itself.
It improves quality before the code ever gets to review, because people care far more about what they do in the first place if they know there is even a chance others will see and criticize them later for doing it wrong.This is why stores put up fake security cameras.
The notion that they have someone sitting there watching the camera continuously is ridiculous, yet a camera has a huge effect on people's tendency to commit crimes nonetheless.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324197</id>
	<title>code reviews are too late</title>
	<author>Alban</author>
	<datestamp>1244907840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
Code reviews are somewhat useful for small changes.  But I find that for large changes, they are TOO LATE.  If someone has gone forward and made non significant changes to your software, and you happen to catch his misconceptions during the code review (dependencies he shouldn't have pulled in, improper encapsulation, volatile and frequent usage of memory, etc), he won't be able to just "address" your concerns with a few changes.  He basically has to scratch most of his work.  And unfortunately, few managers will see the benefit of "implementing something" better since that requires more time, and the feature as implemented "works".
</p><p>
Likewise, when the software design is done too long before the actual task gets to the implementation phase, the design may be out of touch by the time you get there because new constraints and problems have been discovered since the design phase.
</p><p>
That's why I like to have quick whiteboard sessions before someone starts implementing something.  I like to know the dependencies their module will pull in, the services it will require, I want to make sure the module is kept as ignorant as possible in terms of what it knows about the rest of the system, etc.  When those things are caught early on, is it almost free to correct them.  But later, there is a cost.  If the task is long, I like to see multiple snapshots along the way to again course correct anything before it gets too far down the road.
</p><p>
I work at a large video game company.  I don't believe things always were the way they are now, but right now everything is tasked against "features" and it is hard for most managers to understand the necessity of infrastructure work, of unit tests, of proper module encapuslation and definition of dependencies (otherwise you find your unit tests impossible to write using your module's public interface).  Every sees the short term.  It is easy for them to understand that something is done when they see it in the game.  But it is harder for them to understand that you want to make the process of software development more predictable, you don't want half the features in the game to be broken half the time and the shipping product to just be an instant snapshot of working features that will break as soon as the next cycle starts.
</p><p>
So, code reviews are useful, but they really aren't the most useful thing since they occur TOO LATE.</p></htmltext>
<tokenext>Code reviews are somewhat useful for small changes .
But I find that for large changes , they are TOO LATE .
If someone has gone forward and made non significant changes to your software , and you happen to catch his misconceptions during the code review ( dependencies he should n't have pulled in , improper encapsulation , volatile and frequent usage of memory , etc ) , he wo n't be able to just " address " your concerns with a few changes .
He basically has to scratch most of his work .
And unfortunately , few managers will see the benefit of " implementing something " better since that requires more time , and the feature as implemented " works " .
Likewise , when the software design is done too long before the actual task gets to the implementation phase , the design may be out of touch by the time you get there because new constraints and problems have been discovered since the design phase .
That 's why I like to have quick whiteboard sessions before someone starts implementing something .
I like to know the dependencies their module will pull in , the services it will require , I want to make sure the module is kept as ignorant as possible in terms of what it knows about the rest of the system , etc .
When those things are caught early on , is it almost free to correct them .
But later , there is a cost .
If the task is long , I like to see multiple snapshots along the way to again course correct anything before it gets too far down the road .
I work at a large video game company .
I do n't believe things always were the way they are now , but right now everything is tasked against " features " and it is hard for most managers to understand the necessity of infrastructure work , of unit tests , of proper module encapuslation and definition of dependencies ( otherwise you find your unit tests impossible to write using your module 's public interface ) .
Every sees the short term .
It is easy for them to understand that something is done when they see it in the game .
But it is harder for them to understand that you want to make the process of software development more predictable , you do n't want half the features in the game to be broken half the time and the shipping product to just be an instant snapshot of working features that will break as soon as the next cycle starts .
So , code reviews are useful , but they really are n't the most useful thing since they occur TOO LATE .</tokentext>
<sentencetext>
Code reviews are somewhat useful for small changes.
But I find that for large changes, they are TOO LATE.
If someone has gone forward and made non significant changes to your software, and you happen to catch his misconceptions during the code review (dependencies he shouldn't have pulled in, improper encapsulation, volatile and frequent usage of memory, etc), he won't be able to just "address" your concerns with a few changes.
He basically has to scratch most of his work.
And unfortunately, few managers will see the benefit of "implementing something" better since that requires more time, and the feature as implemented "works".
Likewise, when the software design is done too long before the actual task gets to the implementation phase, the design may be out of touch by the time you get there because new constraints and problems have been discovered since the design phase.
That's why I like to have quick whiteboard sessions before someone starts implementing something.
I like to know the dependencies their module will pull in, the services it will require, I want to make sure the module is kept as ignorant as possible in terms of what it knows about the rest of the system, etc.
When those things are caught early on, is it almost free to correct them.
But later, there is a cost.
If the task is long, I like to see multiple snapshots along the way to again course correct anything before it gets too far down the road.
I work at a large video game company.
I don't believe things always were the way they are now, but right now everything is tasked against "features" and it is hard for most managers to understand the necessity of infrastructure work, of unit tests, of proper module encapuslation and definition of dependencies (otherwise you find your unit tests impossible to write using your module's public interface).
Every sees the short term.
It is easy for them to understand that something is done when they see it in the game.
But it is harder for them to understand that you want to make the process of software development more predictable, you don't want half the features in the game to be broken half the time and the shipping product to just be an instant snapshot of working features that will break as soon as the next cycle starts.
So, code reviews are useful, but they really aren't the most useful thing since they occur TOO LATE.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323831</id>
	<title>Re:Delusions of grandeur</title>
	<author>Anonymous</author>
	<datestamp>1244902260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I'm with you, low ceremony, one reviewer usually chosen by the programmer (but has to be someone who is technically qualified).  I've seen that work in a cost effective way.  If a programmer/reviewer team makes a habit of checking in buggy code, then the manager should step in and assign a reviewer for that guy's code, at the minimum.</p><p>This tends to avoid a lot of the politics and grandstanding that often creep up in these situations, which can be an incredible waste of time.  When there are multiple reviewers and/or code reviews are posted online, some team members (new and old) will be hankering to show off and will raise picayune objections.</p></htmltext>
<tokenext>I 'm with you , low ceremony , one reviewer usually chosen by the programmer ( but has to be someone who is technically qualified ) .
I 've seen that work in a cost effective way .
If a programmer/reviewer team makes a habit of checking in buggy code , then the manager should step in and assign a reviewer for that guy 's code , at the minimum.This tends to avoid a lot of the politics and grandstanding that often creep up in these situations , which can be an incredible waste of time .
When there are multiple reviewers and/or code reviews are posted online , some team members ( new and old ) will be hankering to show off and will raise picayune objections .</tokentext>
<sentencetext>I'm with you, low ceremony, one reviewer usually chosen by the programmer (but has to be someone who is technically qualified).
I've seen that work in a cost effective way.
If a programmer/reviewer team makes a habit of checking in buggy code, then the manager should step in and assign a reviewer for that guy's code, at the minimum.This tends to avoid a lot of the politics and grandstanding that often creep up in these situations, which can be an incredible waste of time.
When there are multiple reviewers and/or code reviews are posted online, some team members (new and old) will be hankering to show off and will raise picayune objections.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322691</id>
	<title>What is your historical programmer turnover rate?</title>
	<author>G3ckoG33k</author>
	<datestamp>1244889900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How many per cent of your programmers change, i.e. move to other companies, every year? The higher rate, the more need for well written, easy-to-read code.</p></htmltext>
<tokenext>How many per cent of your programmers change , i.e .
move to other companies , every year ?
The higher rate , the more need for well written , easy-to-read code .</tokentext>
<sentencetext>How many per cent of your programmers change, i.e.
move to other companies, every year?
The higher rate, the more need for well written, easy-to-read code.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323095</id>
	<title>If you're asking, then you're doing it wrong.</title>
	<author>asmdsr</author>
	<datestamp>1244894100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There's two aspects to make it work:</p><p>- Tools.  You should put some effort into your tools.  The features to aspire to are:<br>
&nbsp; &nbsp; - tight VCS integration<br>
&nbsp; &nbsp; - email integration<br>
&nbsp; &nbsp; - visual diff viewer<br>
&nbsp; &nbsp; - inline comment annotations<br>
&nbsp; &nbsp; - web interface is preferable</p><p>- Policy.<br>
&nbsp; &nbsp; - Every change should be individually reviewed, before it is committed (reviewer(s) give the final OK).<br>
&nbsp; &nbsp; - Smaller changes should be encouraged.  The smaller the better, but more than 1000 lines is too big.  Reviewers should request large changes to be broken up if necessary.<br>
&nbsp; &nbsp; - A single reviewer per change is adequate, on average.  2-3 is also common.<br>
&nbsp; &nbsp; - Reviews should also be cc'd to team and other stakeholders; unsolicited reviews/comments should be encouraged.<br>
&nbsp; &nbsp; - A consistent code style should be enforced in reviews.</p><p>The attitude of the engineers is important, but difficult to enact.  It's particularly hard when you're bootstrapping a new policy like this into your engineering culture.  Although the reviewer has the final say, in reality they don't have any real power over their colleagues' actions.  So they should focus on constructive, concrete issues and back off once a reasonable debate has occurred.  Design reviews are important because if design issues come up in code reviews it can get ugly.</p></htmltext>
<tokenext>There 's two aspects to make it work : - Tools .
You should put some effort into your tools .
The features to aspire to are :     - tight VCS integration     - email integration     - visual diff viewer     - inline comment annotations     - web interface is preferable- Policy .
    - Every change should be individually reviewed , before it is committed ( reviewer ( s ) give the final OK ) .
    - Smaller changes should be encouraged .
The smaller the better , but more than 1000 lines is too big .
Reviewers should request large changes to be broken up if necessary .
    - A single reviewer per change is adequate , on average .
2-3 is also common .
    - Reviews should also be cc 'd to team and other stakeholders ; unsolicited reviews/comments should be encouraged .
    - A consistent code style should be enforced in reviews.The attitude of the engineers is important , but difficult to enact .
It 's particularly hard when you 're bootstrapping a new policy like this into your engineering culture .
Although the reviewer has the final say , in reality they do n't have any real power over their colleagues ' actions .
So they should focus on constructive , concrete issues and back off once a reasonable debate has occurred .
Design reviews are important because if design issues come up in code reviews it can get ugly .</tokentext>
<sentencetext>There's two aspects to make it work:- Tools.
You should put some effort into your tools.
The features to aspire to are:
    - tight VCS integration
    - email integration
    - visual diff viewer
    - inline comment annotations
    - web interface is preferable- Policy.
    - Every change should be individually reviewed, before it is committed (reviewer(s) give the final OK).
    - Smaller changes should be encouraged.
The smaller the better, but more than 1000 lines is too big.
Reviewers should request large changes to be broken up if necessary.
    - A single reviewer per change is adequate, on average.
2-3 is also common.
    - Reviews should also be cc'd to team and other stakeholders; unsolicited reviews/comments should be encouraged.
    - A consistent code style should be enforced in reviews.The attitude of the engineers is important, but difficult to enact.
It's particularly hard when you're bootstrapping a new policy like this into your engineering culture.
Although the reviewer has the final say, in reality they don't have any real power over their colleagues' actions.
So they should focus on constructive, concrete issues and back off once a reasonable debate has occurred.
Design reviews are important because if design issues come up in code reviews it can get ugly.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323243</id>
	<title>Re:Yes!</title>
	<author>ers81239</author>
	<datestamp>1244895720000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I just want to highlight your second point.  I believe that THE most important thing gained from code reviews is the spreading knowledge and gaining understanding.  New development is always great, but most programming is maintaining/fixing/improving existing projects.  A code review is a great way to really learn about code readability.  You actually get to see other people read your code and you get to read other people's code.  All of this code is fresh in someone's mind so it can be explained, and how to make it more readable can be discussed.  I learned a ton about writing maintainable code at my first job where we did regular code reviews.</p><p>On the more technical side, often once the code is discussed much simpler ways to solve the problem is discovered.  It isn't about the individual bug fixes/improvements that can come from a code review.  Its really a way to improve your programmers.</p></htmltext>
<tokenext>I just want to highlight your second point .
I believe that THE most important thing gained from code reviews is the spreading knowledge and gaining understanding .
New development is always great , but most programming is maintaining/fixing/improving existing projects .
A code review is a great way to really learn about code readability .
You actually get to see other people read your code and you get to read other people 's code .
All of this code is fresh in someone 's mind so it can be explained , and how to make it more readable can be discussed .
I learned a ton about writing maintainable code at my first job where we did regular code reviews.On the more technical side , often once the code is discussed much simpler ways to solve the problem is discovered .
It is n't about the individual bug fixes/improvements that can come from a code review .
Its really a way to improve your programmers .</tokentext>
<sentencetext>I just want to highlight your second point.
I believe that THE most important thing gained from code reviews is the spreading knowledge and gaining understanding.
New development is always great, but most programming is maintaining/fixing/improving existing projects.
A code review is a great way to really learn about code readability.
You actually get to see other people read your code and you get to read other people's code.
All of this code is fresh in someone's mind so it can be explained, and how to make it more readable can be discussed.
I learned a ton about writing maintainable code at my first job where we did regular code reviews.On the more technical side, often once the code is discussed much simpler ways to solve the problem is discovered.
It isn't about the individual bug fixes/improvements that can come from a code review.
Its really a way to improve your programmers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324495</id>
	<title>Respect for the upcoming review improves code</title>
	<author>freshfromthevat</author>
	<datestamp>1244912400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Many programmers will improve their neatness and attention to coding standards if they know the code review is in the future.</p></htmltext>
<tokenext>Many programmers will improve their neatness and attention to coding standards if they know the code review is in the future .</tokentext>
<sentencetext>Many programmers will improve their neatness and attention to coding standards if they know the code review is in the future.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28360171</id>
	<title>scrum</title>
	<author>luxifr</author>
	<datestamp>1245245580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>have you tried to use scrum as a style for running those development projects? i had positive experiences with that. but it's very different from the "classical" project style and it is important to follow it's rule completely - not only to take the parts you want of it  - the scrum leader should have some training in his role before taking that position (there are courses you can take and even certifications to get<nobr> <wbr></nobr>;)) and the product owner (mostly the customer - whoever it is) also has to comply with that as he has a quite different roll, too, compared to the classical project style....

see here <a href="http://en.wikipedia.org/wiki/Scrum\_(development)" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/Scrum\_(development)</a> [wikipedia.org]</htmltext>
<tokenext>have you tried to use scrum as a style for running those development projects ?
i had positive experiences with that .
but it 's very different from the " classical " project style and it is important to follow it 's rule completely - not only to take the parts you want of it - the scrum leader should have some training in his role before taking that position ( there are courses you can take and even certifications to get ; ) ) and the product owner ( mostly the customer - whoever it is ) also has to comply with that as he has a quite different roll , too , compared to the classical project style... . see here http : //en.wikipedia.org/wiki/Scrum \ _ ( development ) [ wikipedia.org ]</tokentext>
<sentencetext>have you tried to use scrum as a style for running those development projects?
i had positive experiences with that.
but it's very different from the "classical" project style and it is important to follow it's rule completely - not only to take the parts you want of it  - the scrum leader should have some training in his role before taking that position (there are courses you can take and even certifications to get ;)) and the product owner (mostly the customer - whoever it is) also has to comply with that as he has a quite different roll, too, compared to the classical project style....

see here http://en.wikipedia.org/wiki/Scrum\_(development) [wikipedia.org]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323263</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>cetialphav</author>
	<datestamp>1244895960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p><div class="quote"><p>you need to know:<br>- how much does it cost to conduct the reviews<br>- how many defects are discovered in the review versus how many make it out the door (in other words, how good are you at it)<br>- how how much more does it cost you when a bug gets discovered after deployment?</p></div><p>The great thing is that none of these metrics are that hard to collect.  You should already know the cost of production bugs because that is just a basic component of your business.</p><p>To collect the cost to conduct reviews, you just need to ask everyone who does a review how long it took them.  You can store this on paper or in a simple little database.  Reviewers just need to remember to look at the clock when they do the review.  Some computerized review systems can collect this for you automatically.</p><p>To track the defects, you just need to track when someone says "You need to change this because<nobr> <wbr></nobr>...".  Assigning someone as a secretary in a meeting works well (assuming you have a meeting).  Or you can just collect this in the emails or other online system that you use.  The harder thing is to estimate the value of these found defects, but it isn't too hard to come up with some simple heuristics that serve as a reasonable approximation.</p><p>Clearly, many organizations collect this in a way that is painful and intrusive and that gives these metrics a bad name.  But it doesn't have to be that way.  I have seen this done in simple ways that flow easily with the rest of the development process.  Having this information is extremely powerful because without it everyone is just guessing and you become subject to the hunches of middle management because their guesses have more weight since they are the boss.</p></div>
	</htmltext>
<tokenext>you need to know : - how much does it cost to conduct the reviews- how many defects are discovered in the review versus how many make it out the door ( in other words , how good are you at it ) - how how much more does it cost you when a bug gets discovered after deployment ? The great thing is that none of these metrics are that hard to collect .
You should already know the cost of production bugs because that is just a basic component of your business.To collect the cost to conduct reviews , you just need to ask everyone who does a review how long it took them .
You can store this on paper or in a simple little database .
Reviewers just need to remember to look at the clock when they do the review .
Some computerized review systems can collect this for you automatically.To track the defects , you just need to track when someone says " You need to change this because ... " .
Assigning someone as a secretary in a meeting works well ( assuming you have a meeting ) .
Or you can just collect this in the emails or other online system that you use .
The harder thing is to estimate the value of these found defects , but it is n't too hard to come up with some simple heuristics that serve as a reasonable approximation.Clearly , many organizations collect this in a way that is painful and intrusive and that gives these metrics a bad name .
But it does n't have to be that way .
I have seen this done in simple ways that flow easily with the rest of the development process .
Having this information is extremely powerful because without it everyone is just guessing and you become subject to the hunches of middle management because their guesses have more weight since they are the boss .</tokentext>
<sentencetext>you need to know:- how much does it cost to conduct the reviews- how many defects are discovered in the review versus how many make it out the door (in other words, how good are you at it)- how how much more does it cost you when a bug gets discovered after deployment?The great thing is that none of these metrics are that hard to collect.
You should already know the cost of production bugs because that is just a basic component of your business.To collect the cost to conduct reviews, you just need to ask everyone who does a review how long it took them.
You can store this on paper or in a simple little database.
Reviewers just need to remember to look at the clock when they do the review.
Some computerized review systems can collect this for you automatically.To track the defects, you just need to track when someone says "You need to change this because ...".
Assigning someone as a secretary in a meeting works well (assuming you have a meeting).
Or you can just collect this in the emails or other online system that you use.
The harder thing is to estimate the value of these found defects, but it isn't too hard to come up with some simple heuristics that serve as a reasonable approximation.Clearly, many organizations collect this in a way that is painful and intrusive and that gives these metrics a bad name.
But it doesn't have to be that way.
I have seen this done in simple ways that flow easily with the rest of the development process.
Having this information is extremely powerful because without it everyone is just guessing and you become subject to the hunches of middle management because their guesses have more weight since they are the boss.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322551</id>
	<title>In a word, yes</title>
	<author>iamdjsamba</author>
	<datestamp>1244889000000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext>Where I work we have code reviews at various degrees.  I find someone else just reading over my code and emailing suggestions helps tons; It spots obvious errors, ways code could be done better, and just a ton of other things.  It helps improves my own coding style too.</htmltext>
<tokenext>Where I work we have code reviews at various degrees .
I find someone else just reading over my code and emailing suggestions helps tons ; It spots obvious errors , ways code could be done better , and just a ton of other things .
It helps improves my own coding style too .</tokentext>
<sentencetext>Where I work we have code reviews at various degrees.
I find someone else just reading over my code and emailing suggestions helps tons; It spots obvious errors, ways code could be done better, and just a ton of other things.
It helps improves my own coding style too.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326431</id>
	<title>What about the frequency of code changes</title>
	<author>heironymous</author>
	<datestamp>1244993100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I haven't seen anyone comment yet on how frequently the code under review will change.  If you are writing a library or something that's going to be pretty stable, then the cost of a formal review is easier to justify.</p><p>But if the code is unstable, and going to be modified over and over, then the benefit of a formal review depreciates very rapidly.  For some industries and products, this doesn't matter.  But for others, the cost of the formal review can be too high.</p></htmltext>
<tokenext>I have n't seen anyone comment yet on how frequently the code under review will change .
If you are writing a library or something that 's going to be pretty stable , then the cost of a formal review is easier to justify.But if the code is unstable , and going to be modified over and over , then the benefit of a formal review depreciates very rapidly .
For some industries and products , this does n't matter .
But for others , the cost of the formal review can be too high .</tokentext>
<sentencetext>I haven't seen anyone comment yet on how frequently the code under review will change.
If you are writing a library or something that's going to be pretty stable, then the cost of a formal review is easier to justify.But if the code is unstable, and going to be modified over and over, then the benefit of a formal review depreciates very rapidly.
For some industries and products, this doesn't matter.
But for others, the cost of the formal review can be too high.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322917</id>
	<title>Code Reviews for the lulz</title>
	<author>Anonymous</author>
	<datestamp>1244892060000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext>When I was working as a trainee, I was invited to the code review of a mediocre programmer. A bunch of people were there including a senior A/P who was my boss. My boss started ripping into it and I quickly realized the mediocre programmer - who couldn't code his way out of a wet paper bag - had taken one of my programs and tried changing it (including my name). It didn't work and the senior A/P was asking him 'WTF does this do?'<br>
<br>
Oh the dilemma. Do I take ownership and defend "my" code, or say nothing and enjoy watching him squirm? I did the latter watching him go "ummmmm ummmmm ummmmm". Finally medicore programmer admitted he copied it and it was really mine. I said "Well it was working when you copied it off me."<br>
<br>
Needless to say he ended up being promoted to manager. Not even a PHB which requires a bit of cunning, he was just a flat out idiot. I keep in touch with some of my coworkers to this day and whenever we want to describe a certain type of idiot we use his name. Duuuuuuuuuuuuuuh.</htmltext>
<tokenext>When I was working as a trainee , I was invited to the code review of a mediocre programmer .
A bunch of people were there including a senior A/P who was my boss .
My boss started ripping into it and I quickly realized the mediocre programmer - who could n't code his way out of a wet paper bag - had taken one of my programs and tried changing it ( including my name ) .
It did n't work and the senior A/P was asking him 'WTF does this do ?
' Oh the dilemma .
Do I take ownership and defend " my " code , or say nothing and enjoy watching him squirm ?
I did the latter watching him go " ummmmm ummmmm ummmmm " .
Finally medicore programmer admitted he copied it and it was really mine .
I said " Well it was working when you copied it off me .
" Needless to say he ended up being promoted to manager .
Not even a PHB which requires a bit of cunning , he was just a flat out idiot .
I keep in touch with some of my coworkers to this day and whenever we want to describe a certain type of idiot we use his name .
Duuuuuuuuuuuuuuh .</tokentext>
<sentencetext>When I was working as a trainee, I was invited to the code review of a mediocre programmer.
A bunch of people were there including a senior A/P who was my boss.
My boss started ripping into it and I quickly realized the mediocre programmer - who couldn't code his way out of a wet paper bag - had taken one of my programs and tried changing it (including my name).
It didn't work and the senior A/P was asking him 'WTF does this do?
'

Oh the dilemma.
Do I take ownership and defend "my" code, or say nothing and enjoy watching him squirm?
I did the latter watching him go "ummmmm ummmmm ummmmm".
Finally medicore programmer admitted he copied it and it was really mine.
I said "Well it was working when you copied it off me.
"

Needless to say he ended up being promoted to manager.
Not even a PHB which requires a bit of cunning, he was just a flat out idiot.
I keep in touch with some of my coworkers to this day and whenever we want to describe a certain type of idiot we use his name.
Duuuuuuuuuuuuuuh.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324935</id>
	<title>Re:Yes!</title>
	<author>crispytwo</author>
	<datestamp>1244920680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Code reviews have a lot of value in two ways completely independent of how good they are at catching errors.  First, they are a way to enforce various stylistic guidelines on code that make future maintenance much easier.  Secondly, they are a tool for spreading knowledge about the code around to other members of your development team.</p><p>They can also catch some errors that are very hard to catch in any other way.</p></div><p>I agree, however, what I have implemented in my shop is before a commit to the repository is made, two programmers sit together and go through every line of code being committed (and of course the surrounding code). What that does is a minimal code review (i.e. only two people involved). However, it does allow the transmission of knowledge, improves style, catches all sorts of interesting bugs and all for minimal cost. It doesn't catch everything, but neither does a grand code review.</p><p>Everyone that does this type of thing actually appreciates it and is willing to do it. Specifically, no one complains about how much extra time it takes and what better things they could be doing. I recommend this as something that can be added to your development cycle and do grand code reviews too, when budget permits.</p></div>
	</htmltext>
<tokenext>Code reviews have a lot of value in two ways completely independent of how good they are at catching errors .
First , they are a way to enforce various stylistic guidelines on code that make future maintenance much easier .
Secondly , they are a tool for spreading knowledge about the code around to other members of your development team.They can also catch some errors that are very hard to catch in any other way.I agree , however , what I have implemented in my shop is before a commit to the repository is made , two programmers sit together and go through every line of code being committed ( and of course the surrounding code ) .
What that does is a minimal code review ( i.e .
only two people involved ) .
However , it does allow the transmission of knowledge , improves style , catches all sorts of interesting bugs and all for minimal cost .
It does n't catch everything , but neither does a grand code review.Everyone that does this type of thing actually appreciates it and is willing to do it .
Specifically , no one complains about how much extra time it takes and what better things they could be doing .
I recommend this as something that can be added to your development cycle and do grand code reviews too , when budget permits .</tokentext>
<sentencetext>Code reviews have a lot of value in two ways completely independent of how good they are at catching errors.
First, they are a way to enforce various stylistic guidelines on code that make future maintenance much easier.
Secondly, they are a tool for spreading knowledge about the code around to other members of your development team.They can also catch some errors that are very hard to catch in any other way.I agree, however, what I have implemented in my shop is before a commit to the repository is made, two programmers sit together and go through every line of code being committed (and of course the surrounding code).
What that does is a minimal code review (i.e.
only two people involved).
However, it does allow the transmission of knowledge, improves style, catches all sorts of interesting bugs and all for minimal cost.
It doesn't catch everything, but neither does a grand code review.Everyone that does this type of thing actually appreciates it and is willing to do it.
Specifically, no one complains about how much extra time it takes and what better things they could be doing.
I recommend this as something that can be added to your development cycle and do grand code reviews too, when budget permits.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326855</id>
	<title>Gods yes!</title>
	<author>Fastolfe</author>
	<datestamp>1244998620000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Just do them right:<br>1. Each commit should have an explanation of what the change does, and should be small enough that the reviewer can do it quickly.<br>2. Your organization should prioritize code reviews over other work; in many cases the review is blocking something.</p><p>If your reviews are kept small, and are a high priority, they add enormous value and shouldn't negatively impact your work.</p><p>Code reviews have the following perhaps non-obvious benefits:<br>- They ensure the implementation does justice to the design<br>- They help pass institutional knowledge to the developer ("This function has an existing implementation over here...")<br>- They ensure code readability (especially when used with a formal style guide)<br>- They help keep the developer honest, when he or she might take shortcuts or be lazy with a certain function.<br>- By mandating code reviews, you have a pressure from the reviewers to keep each commit small, which encourages incremental development, which discovers design flaws early rather than after 10,000 lines are written.</p><p>Code reviews aren't really a great place to FIND bugs.  Yes, obvious bugs will stand out to an experienced developer, but the reviewer is another human, and he or she can easily miss the same bugs the developer missed.  Really, unit tests are where you catch bugs, and a reviewer is usually in a better position to identify incomplete unit testing.</p></htmltext>
<tokenext>Just do them right : 1 .
Each commit should have an explanation of what the change does , and should be small enough that the reviewer can do it quickly.2 .
Your organization should prioritize code reviews over other work ; in many cases the review is blocking something.If your reviews are kept small , and are a high priority , they add enormous value and should n't negatively impact your work.Code reviews have the following perhaps non-obvious benefits : - They ensure the implementation does justice to the design- They help pass institutional knowledge to the developer ( " This function has an existing implementation over here... " ) - They ensure code readability ( especially when used with a formal style guide ) - They help keep the developer honest , when he or she might take shortcuts or be lazy with a certain function.- By mandating code reviews , you have a pressure from the reviewers to keep each commit small , which encourages incremental development , which discovers design flaws early rather than after 10,000 lines are written.Code reviews are n't really a great place to FIND bugs .
Yes , obvious bugs will stand out to an experienced developer , but the reviewer is another human , and he or she can easily miss the same bugs the developer missed .
Really , unit tests are where you catch bugs , and a reviewer is usually in a better position to identify incomplete unit testing .</tokentext>
<sentencetext>Just do them right:1.
Each commit should have an explanation of what the change does, and should be small enough that the reviewer can do it quickly.2.
Your organization should prioritize code reviews over other work; in many cases the review is blocking something.If your reviews are kept small, and are a high priority, they add enormous value and shouldn't negatively impact your work.Code reviews have the following perhaps non-obvious benefits:- They ensure the implementation does justice to the design- They help pass institutional knowledge to the developer ("This function has an existing implementation over here...")- They ensure code readability (especially when used with a formal style guide)- They help keep the developer honest, when he or she might take shortcuts or be lazy with a certain function.- By mandating code reviews, you have a pressure from the reviewers to keep each commit small, which encourages incremental development, which discovers design flaws early rather than after 10,000 lines are written.Code reviews aren't really a great place to FIND bugs.
Yes, obvious bugs will stand out to an experienced developer, but the reviewer is another human, and he or she can easily miss the same bugs the developer missed.
Really, unit tests are where you catch bugs, and a reviewer is usually in a better position to identify incomplete unit testing.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323559</id>
	<title>Not much, it doesn't</title>
	<author>Anonymous</author>
	<datestamp>1244898960000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>If it's ever not more economic to do code reviews, then I respectfully submit that You're Doing Them Wrong(TM).</p><p>The improvements in the general standard of code, and consequently its maintainability, should easily outweigh the modest time spent on reviews. Likewise, the efficiency benefits just from sharing basic awareness of how various systems work and useful coding techniques around a development group should be enough to justify the time spent. And those are both without allowing for any actual bugs that would have been observed by your customers but got fixed much earlier and cheaper because the review caught them.</p><p>Incidentally, if you don't think it's worth getting even a quick glance from a second pair of eyes on even a small bug fix, you should look up the research on how many bugs originate from a one- or two-line change to the code. It's a staggeringly high proportion.</p><p>Now, a lot of places have tried full, Fagan-style, heavyweight reviews, and yeah, those pretty much suck for most software development groups. But that doesn't mean you can't employ a lighter process with the same goals. With the kinds of tools available to co-ordinate reviews and annotate code these days, your overheads should be near zero and you can do a lot of the work on-line rather than shoving everyone into a room for a few relatively unproductive hours.</p></htmltext>
<tokenext>If it 's ever not more economic to do code reviews , then I respectfully submit that You 're Doing Them Wrong ( TM ) .The improvements in the general standard of code , and consequently its maintainability , should easily outweigh the modest time spent on reviews .
Likewise , the efficiency benefits just from sharing basic awareness of how various systems work and useful coding techniques around a development group should be enough to justify the time spent .
And those are both without allowing for any actual bugs that would have been observed by your customers but got fixed much earlier and cheaper because the review caught them.Incidentally , if you do n't think it 's worth getting even a quick glance from a second pair of eyes on even a small bug fix , you should look up the research on how many bugs originate from a one- or two-line change to the code .
It 's a staggeringly high proportion.Now , a lot of places have tried full , Fagan-style , heavyweight reviews , and yeah , those pretty much suck for most software development groups .
But that does n't mean you ca n't employ a lighter process with the same goals .
With the kinds of tools available to co-ordinate reviews and annotate code these days , your overheads should be near zero and you can do a lot of the work on-line rather than shoving everyone into a room for a few relatively unproductive hours .</tokentext>
<sentencetext>If it's ever not more economic to do code reviews, then I respectfully submit that You're Doing Them Wrong(TM).The improvements in the general standard of code, and consequently its maintainability, should easily outweigh the modest time spent on reviews.
Likewise, the efficiency benefits just from sharing basic awareness of how various systems work and useful coding techniques around a development group should be enough to justify the time spent.
And those are both without allowing for any actual bugs that would have been observed by your customers but got fixed much earlier and cheaper because the review caught them.Incidentally, if you don't think it's worth getting even a quick glance from a second pair of eyes on even a small bug fix, you should look up the research on how many bugs originate from a one- or two-line change to the code.
It's a staggeringly high proportion.Now, a lot of places have tried full, Fagan-style, heavyweight reviews, and yeah, those pretty much suck for most software development groups.
But that doesn't mean you can't employ a lighter process with the same goals.
With the kinds of tools available to co-ordinate reviews and annotate code these days, your overheads should be near zero and you can do a lot of the work on-line rather than shoving everyone into a room for a few relatively unproductive hours.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837</id>
	<title>Depends what you are reviewing</title>
	<author>grahamsz</author>
	<datestamp>1244891280000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>Quite simply, code reviews cost money and production bugs cost money.</p><p>We do code reviews for anything where it'll either be devastating expensive if we encounter a failure or if it'll be very hard to detect a failure. Otherwise, in my particular line of work, it's more economical to accept a lower cost and faster pace of development at the expense of dealing with a few bugs that are discovered in production.</p></htmltext>
<tokenext>Quite simply , code reviews cost money and production bugs cost money.We do code reviews for anything where it 'll either be devastating expensive if we encounter a failure or if it 'll be very hard to detect a failure .
Otherwise , in my particular line of work , it 's more economical to accept a lower cost and faster pace of development at the expense of dealing with a few bugs that are discovered in production .</tokentext>
<sentencetext>Quite simply, code reviews cost money and production bugs cost money.We do code reviews for anything where it'll either be devastating expensive if we encounter a failure or if it'll be very hard to detect a failure.
Otherwise, in my particular line of work, it's more economical to accept a lower cost and faster pace of development at the expense of dealing with a few bugs that are discovered in production.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322745</id>
	<title>Yes they are worth it</title>
	<author>DrXym</author>
	<datestamp>1244890260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've led large teams of developers and I guarantee that even if you write coding standards, or have a common coding style for the project that somebody in your team will either ignore it, or do their own thing. The guidelines might say don't use hungarian but somebody still will. Code reviews are an excellent way to enforce standards and ensure a base level of code quality across the board. Aside from general style, reviews mean you catch people not programming defensively, not catching exceptions, not writing readable code, not logging, using weird notation, weird indentation and so on. After getting drubbed a few times in reviews most programmers are a lot more conscious of the way they write code and the overall standard is raised. After that reviews are still a useful practice because I've lost count of the number of potential bugs they've caught.
<p>
Now maybe there are reasons that reviews should be conducted in one way or another. My preference is formal group reviews for brand new code pr new team developers and over-the-shoulder reviews for substantial checkins thereafter. Between the two I guarantee you save more time than if the bugs went in and were only uncovered later in QA or worse, in production.</p></htmltext>
<tokenext>I 've led large teams of developers and I guarantee that even if you write coding standards , or have a common coding style for the project that somebody in your team will either ignore it , or do their own thing .
The guidelines might say do n't use hungarian but somebody still will .
Code reviews are an excellent way to enforce standards and ensure a base level of code quality across the board .
Aside from general style , reviews mean you catch people not programming defensively , not catching exceptions , not writing readable code , not logging , using weird notation , weird indentation and so on .
After getting drubbed a few times in reviews most programmers are a lot more conscious of the way they write code and the overall standard is raised .
After that reviews are still a useful practice because I 've lost count of the number of potential bugs they 've caught .
Now maybe there are reasons that reviews should be conducted in one way or another .
My preference is formal group reviews for brand new code pr new team developers and over-the-shoulder reviews for substantial checkins thereafter .
Between the two I guarantee you save more time than if the bugs went in and were only uncovered later in QA or worse , in production .</tokentext>
<sentencetext>I've led large teams of developers and I guarantee that even if you write coding standards, or have a common coding style for the project that somebody in your team will either ignore it, or do their own thing.
The guidelines might say don't use hungarian but somebody still will.
Code reviews are an excellent way to enforce standards and ensure a base level of code quality across the board.
Aside from general style, reviews mean you catch people not programming defensively, not catching exceptions, not writing readable code, not logging, using weird notation, weird indentation and so on.
After getting drubbed a few times in reviews most programmers are a lot more conscious of the way they write code and the overall standard is raised.
After that reviews are still a useful practice because I've lost count of the number of potential bugs they've caught.
Now maybe there are reasons that reviews should be conducted in one way or another.
My preference is formal group reviews for brand new code pr new team developers and over-the-shoulder reviews for substantial checkins thereafter.
Between the two I guarantee you save more time than if the bugs went in and were only uncovered later in QA or worse, in production.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323135</id>
	<title>An Argument?</title>
	<author>Swanktastic</author>
	<datestamp>1244894520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>If you actually got into an argument with your boss, then I'm guessing you went about things all wrong in trying to make your point.  Some tips of advice for advocating a change of procedure:</p><p>1) Don't make this case in front of other people.  This has to be behind closed doors.  If you bring up something in front of others, it simply looks like you're trying to make the boss look like a bad guy to everyone else, and he/she will get defensive.</p><p>2) The easiest job in the world is to be a critic.  If you come up with a well reasoned plan, with statistics, etc. that prove your point and propose a new methodology, you're well on your way to getting your way.  Half the time subordinates pose a problem to me, they're simply dumping more work on my lap.  I try to be reasonable, but it's a heck of a lot easier to approve something if there's a reasonable proposal to work with.  Especially if the proposal looks to have a low risk and substantial gain.  Not everyone wants to stake their reputation on certain projects.</p><p>3) The problem may/may not lie with your boss.  He/she may have had this exact discussion with his/her boss and already been shot down.</p><p>4) You have to be genuinely motivated to improve your work product.  The motivation cannot be "code reviews are a waste of time."  If you pose something that way, you're essentially calling your boss an idiot for asking you to do them.  Also, your boss is immediately going to be suspicious you're simply trying to reduce your responsibilities.</p><p>5) If that fails, you may as well embrace the reviews and dedicate your time to improving the way they are conducted.  Spend some time researching what works and what doesn't.  Then go to your boss and ask permission to implement some of the best practices.  Managers get irritated when people expect them to solve all their problems.  Do your best to institutionalize good practices and demonstrate that you're doing things for the good of the company, rather than to free up some time in your day.  Do it in the name of "continuous improvement," and you'll be a hero.</p><p>6) You usually get two shots to make a pitch for a change.  After that, you need to do your best to implement things the way your boss wants them.  Anything more, and you're simply challenging his/her authority.</p></htmltext>
<tokenext>If you actually got into an argument with your boss , then I 'm guessing you went about things all wrong in trying to make your point .
Some tips of advice for advocating a change of procedure : 1 ) Do n't make this case in front of other people .
This has to be behind closed doors .
If you bring up something in front of others , it simply looks like you 're trying to make the boss look like a bad guy to everyone else , and he/she will get defensive.2 ) The easiest job in the world is to be a critic .
If you come up with a well reasoned plan , with statistics , etc .
that prove your point and propose a new methodology , you 're well on your way to getting your way .
Half the time subordinates pose a problem to me , they 're simply dumping more work on my lap .
I try to be reasonable , but it 's a heck of a lot easier to approve something if there 's a reasonable proposal to work with .
Especially if the proposal looks to have a low risk and substantial gain .
Not everyone wants to stake their reputation on certain projects.3 ) The problem may/may not lie with your boss .
He/she may have had this exact discussion with his/her boss and already been shot down.4 ) You have to be genuinely motivated to improve your work product .
The motivation can not be " code reviews are a waste of time .
" If you pose something that way , you 're essentially calling your boss an idiot for asking you to do them .
Also , your boss is immediately going to be suspicious you 're simply trying to reduce your responsibilities.5 ) If that fails , you may as well embrace the reviews and dedicate your time to improving the way they are conducted .
Spend some time researching what works and what does n't .
Then go to your boss and ask permission to implement some of the best practices .
Managers get irritated when people expect them to solve all their problems .
Do your best to institutionalize good practices and demonstrate that you 're doing things for the good of the company , rather than to free up some time in your day .
Do it in the name of " continuous improvement , " and you 'll be a hero.6 ) You usually get two shots to make a pitch for a change .
After that , you need to do your best to implement things the way your boss wants them .
Anything more , and you 're simply challenging his/her authority .</tokentext>
<sentencetext>If you actually got into an argument with your boss, then I'm guessing you went about things all wrong in trying to make your point.
Some tips of advice for advocating a change of procedure:1) Don't make this case in front of other people.
This has to be behind closed doors.
If you bring up something in front of others, it simply looks like you're trying to make the boss look like a bad guy to everyone else, and he/she will get defensive.2) The easiest job in the world is to be a critic.
If you come up with a well reasoned plan, with statistics, etc.
that prove your point and propose a new methodology, you're well on your way to getting your way.
Half the time subordinates pose a problem to me, they're simply dumping more work on my lap.
I try to be reasonable, but it's a heck of a lot easier to approve something if there's a reasonable proposal to work with.
Especially if the proposal looks to have a low risk and substantial gain.
Not everyone wants to stake their reputation on certain projects.3) The problem may/may not lie with your boss.
He/she may have had this exact discussion with his/her boss and already been shot down.4) You have to be genuinely motivated to improve your work product.
The motivation cannot be "code reviews are a waste of time.
"  If you pose something that way, you're essentially calling your boss an idiot for asking you to do them.
Also, your boss is immediately going to be suspicious you're simply trying to reduce your responsibilities.5) If that fails, you may as well embrace the reviews and dedicate your time to improving the way they are conducted.
Spend some time researching what works and what doesn't.
Then go to your boss and ask permission to implement some of the best practices.
Managers get irritated when people expect them to solve all their problems.
Do your best to institutionalize good practices and demonstrate that you're doing things for the good of the company, rather than to free up some time in your day.
Do it in the name of "continuous improvement," and you'll be a hero.6) You usually get two shots to make a pitch for a change.
After that, you need to do your best to implement things the way your boss wants them.
Anything more, and you're simply challenging his/her authority.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325607</id>
	<title>Re:a fucktonne?</title>
	<author>Anonymous</author>
	<datestamp>1244978640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>1000</p></htmltext>
<tokenext>1000</tokentext>
<sentencetext>1000</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323545</id>
	<title>Re:If you're code review is taking forever...</title>
	<author>Keybounce</author>
	<datestamp>1244898840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>&gt; Review and document inline with your coding, and you'll find you'll never need a "Full Stop" review.
<br> <br>
My best experiences with "code review" is working in a team of two programmers to one terminal. If you have to go over every decision with someone else, and there's always someone else familiar with every section of code, then that's great.
<br> <br>
Double the programmer cost of development may seem high, but that's only something like 1/6th the total cost, and it lowers the bug fixing cost.</htmltext>
<tokenext>&gt; Review and document inline with your coding , and you 'll find you 'll never need a " Full Stop " review .
My best experiences with " code review " is working in a team of two programmers to one terminal .
If you have to go over every decision with someone else , and there 's always someone else familiar with every section of code , then that 's great .
Double the programmer cost of development may seem high , but that 's only something like 1/6th the total cost , and it lowers the bug fixing cost .</tokentext>
<sentencetext>&gt; Review and document inline with your coding, and you'll find you'll never need a "Full Stop" review.
My best experiences with "code review" is working in a team of two programmers to one terminal.
If you have to go over every decision with someone else, and there's always someone else familiar with every section of code, then that's great.
Double the programmer cost of development may seem high, but that's only something like 1/6th the total cost, and it lowers the bug fixing cost.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323611</id>
	<title>TDD vs. code reviews: "untestable" properties?</title>
	<author>jonaskoelker</author>
	<datestamp>1244899380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>If you did test-driven development then code reviews would be redundant.</p></div><p>No, not for everything.</p><p>I'm currently fitting a wiimote-shaped peg into an XTest-shaped hole.  I find that I can point the nunchuk upwards by a larger angle than I can point it downwards.  The code that reads nunchuk data should compensate for this fact somehow.</p><p>I'm not really sure how you write a test method for "Wiimote should be pleasant for human hands to hold and operate".  Nor am I convinced that I would have found out my discovery without exploratory coding, something which TDD forbids or at least discourages and frowns upon ("write tests first").</p><p>At least, if I get what TDD is all about.</p></div>
	</htmltext>
<tokenext>If you did test-driven development then code reviews would be redundant.No , not for everything.I 'm currently fitting a wiimote-shaped peg into an XTest-shaped hole .
I find that I can point the nunchuk upwards by a larger angle than I can point it downwards .
The code that reads nunchuk data should compensate for this fact somehow.I 'm not really sure how you write a test method for " Wiimote should be pleasant for human hands to hold and operate " .
Nor am I convinced that I would have found out my discovery without exploratory coding , something which TDD forbids or at least discourages and frowns upon ( " write tests first " ) .At least , if I get what TDD is all about .</tokentext>
<sentencetext>If you did test-driven development then code reviews would be redundant.No, not for everything.I'm currently fitting a wiimote-shaped peg into an XTest-shaped hole.
I find that I can point the nunchuk upwards by a larger angle than I can point it downwards.
The code that reads nunchuk data should compensate for this fact somehow.I'm not really sure how you write a test method for "Wiimote should be pleasant for human hands to hold and operate".
Nor am I convinced that I would have found out my discovery without exploratory coding, something which TDD forbids or at least discourages and frowns upon ("write tests first").At least, if I get what TDD is all about.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322675</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324009</id>
	<title>code reviews suck</title>
	<author>Anonymous</author>
	<datestamp>1244904600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>software <i>is</i> bugs.  a code review may find a few, but it will miss many others, because most bugs are a missed/misunderstood/unknown requirement.</p><p>and as for them being "a way to enforce various stylistic guidelines on code", that's simply a nice way of saying, "they provide a forum for pedantic programmers to pummel one another about stylistic ridiculousness.</p></htmltext>
<tokenext>software is bugs .
a code review may find a few , but it will miss many others , because most bugs are a missed/misunderstood/unknown requirement.and as for them being " a way to enforce various stylistic guidelines on code " , that 's simply a nice way of saying , " they provide a forum for pedantic programmers to pummel one another about stylistic ridiculousness .</tokentext>
<sentencetext>software is bugs.
a code review may find a few, but it will miss many others, because most bugs are a missed/misunderstood/unknown requirement.and as for them being "a way to enforce various stylistic guidelines on code", that's simply a nice way of saying, "they provide a forum for pedantic programmers to pummel one another about stylistic ridiculousness.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28333429</id>
	<title>Re:a fucktonne?</title>
	<author>alephnull42</author>
	<datestamp>1245066840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt;&gt;How many shitloads are in a fucktonne?<br>It depends:<br>- British or American shitload?<br>- Land or nautical fucktonne?</p></htmltext>
<tokenext>&gt; &gt; How many shitloads are in a fucktonne ? It depends : - British or American shitload ? - Land or nautical fucktonne ?</tokentext>
<sentencetext>&gt;&gt;How many shitloads are in a fucktonne?It depends:- British or American shitload?- Land or nautical fucktonne?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28334611</id>
	<title>Self-Fulfilling Prophecy</title>
	<author>theghost</author>
	<datestamp>1245077940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Cancel the code reviews and you'll end up with more errors even though the code reviews themselves don't find that many errors. The very act of having code reviews prevents a lot of the problems that would be found in a code review because people are more careful when they know someone else is going to dig deeply into their work.</p></htmltext>
<tokenext>Cancel the code reviews and you 'll end up with more errors even though the code reviews themselves do n't find that many errors .
The very act of having code reviews prevents a lot of the problems that would be found in a code review because people are more careful when they know someone else is going to dig deeply into their work .</tokentext>
<sentencetext>Cancel the code reviews and you'll end up with more errors even though the code reviews themselves don't find that many errors.
The very act of having code reviews prevents a lot of the problems that would be found in a code review because people are more careful when they know someone else is going to dig deeply into their work.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323635</id>
	<title>Simplify them</title>
	<author>ergun coruh</author>
	<datestamp>1244899680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I am an experienced principal software engineer and team lead in a software house. Code reviews are essential part of our development process. Having said that we avoid lengthy reviews. We don't have review meetings, forms, sign off procedures, the stuff that put people off. Code reviews are a conducted entirely online via Jira forms, using a simple set of workflow rules. It is a non-intrusive, friendly process. I am considered to be one of the best coders, but I am not flawless. I find it hugely valuable for someone (at least as experienced as myself) to review my code. Even if I have the chance to slip it, I won't. It is for my own benefit. Most ideas are subjective and they pop up in human consciousness. I am not talking about detecting simple errors, but issues more of structural, the ways you structure code; i.e. efficiency vs maintainability, or generality vs usability. I don't believe there is a machine process out there that can successfully replace a human reviewer to find the optimum between these extremes, at least not for another 100 years. To sum up, "don't give up code reviews, but simplify them, make them developer friendly".</htmltext>
<tokenext>I am an experienced principal software engineer and team lead in a software house .
Code reviews are essential part of our development process .
Having said that we avoid lengthy reviews .
We do n't have review meetings , forms , sign off procedures , the stuff that put people off .
Code reviews are a conducted entirely online via Jira forms , using a simple set of workflow rules .
It is a non-intrusive , friendly process .
I am considered to be one of the best coders , but I am not flawless .
I find it hugely valuable for someone ( at least as experienced as myself ) to review my code .
Even if I have the chance to slip it , I wo n't .
It is for my own benefit .
Most ideas are subjective and they pop up in human consciousness .
I am not talking about detecting simple errors , but issues more of structural , the ways you structure code ; i.e .
efficiency vs maintainability , or generality vs usability .
I do n't believe there is a machine process out there that can successfully replace a human reviewer to find the optimum between these extremes , at least not for another 100 years .
To sum up , " do n't give up code reviews , but simplify them , make them developer friendly " .</tokentext>
<sentencetext>I am an experienced principal software engineer and team lead in a software house.
Code reviews are essential part of our development process.
Having said that we avoid lengthy reviews.
We don't have review meetings, forms, sign off procedures, the stuff that put people off.
Code reviews are a conducted entirely online via Jira forms, using a simple set of workflow rules.
It is a non-intrusive, friendly process.
I am considered to be one of the best coders, but I am not flawless.
I find it hugely valuable for someone (at least as experienced as myself) to review my code.
Even if I have the chance to slip it, I won't.
It is for my own benefit.
Most ideas are subjective and they pop up in human consciousness.
I am not talking about detecting simple errors, but issues more of structural, the ways you structure code; i.e.
efficiency vs maintainability, or generality vs usability.
I don't believe there is a machine process out there that can successfully replace a human reviewer to find the optimum between these extremes, at least not for another 100 years.
To sum up, "don't give up code reviews, but simplify them, make them developer friendly".</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325697</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>Anonymous</author>
	<datestamp>1244981460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Parent is correct.  METRICS on your review processes is key.  Spend at least a few months carefully gathering data. Also, it is possible that you aren't motivating the reviewers properly, so the reviews aren't doing all they should?</p><p>Key questions for any review process:<br>- What is the most efficient number of reviewers?  2 experts is generally the best answer for software<br>- At what stage of the delivery process are bugs found?  Usually, earlier is cheaper to correct than later.<br>- Does your process properly measure "what you really want?"  Be careful what you measure, because that is what you'll get.</p><p>I've worked in CMM-5 development and no process environments and somewhere in between.</p><p>In CMM-5 environments, you "knew" your code was extremely high quality and our multi-level testing teams were extremely frustrated. The team of 22 developers introduced 1 bug every 2 years. This was on the space shuttle GN&amp;C flight software. Very meaningful work with lives and expensive vehicles on the line.</p><p>For the other two environments, 1 team had zero process but each of the 9 developers was extremely skilled and conscientious. Any bug was considered a very personal thing and corrected immediately. Memory leaks were considered MAJOR bugs and corrected immediately. No reviews were performed after a design white board presentation. This was cross platform code used in every NASA mission control center and partner control centers world wide.  We didn't track any bug/issue statistics, but my feeling was we didn't need to. The software was extremely high quality. Very meaningful work with lives and expensive vehicles on the line.</p><p>The last place had normal skill level developers that used no process when I arrived. They were under so much pressure to add functions that bugs were introduced constantly. I introduced daily builds and build testing. We brought in QA and bug tracking software, which we needed very much. With only 7 developers, we had thousands of bugs. Most of the bugs were in the GUI, with just a few on the server side. There was little support from management for any process at all.  We started doing extreme programming and added project management to manage all the changes. We hired more developers and more and stole people from other teams.  The software got buggier and buggier the more average programmers that we added. In the end, 3 of the 15+ programmers were highly skilled guys. They could work on pacemakers or airplane code. The rest were just trying to get paid and laid.  Then the company was bought out and I left.  Not meaningful work. Nobody cared whether the code worked or not except the customers. Almost no motivation beside pay to do it right.</p><p>In each of the environments above, when the code had to be high quality because lives were on the line, that's what we got.</p></htmltext>
<tokenext>Parent is correct .
METRICS on your review processes is key .
Spend at least a few months carefully gathering data .
Also , it is possible that you are n't motivating the reviewers properly , so the reviews are n't doing all they should ? Key questions for any review process : - What is the most efficient number of reviewers ?
2 experts is generally the best answer for software- At what stage of the delivery process are bugs found ?
Usually , earlier is cheaper to correct than later.- Does your process properly measure " what you really want ?
" Be careful what you measure , because that is what you 'll get.I 've worked in CMM-5 development and no process environments and somewhere in between.In CMM-5 environments , you " knew " your code was extremely high quality and our multi-level testing teams were extremely frustrated .
The team of 22 developers introduced 1 bug every 2 years .
This was on the space shuttle GN&amp;C flight software .
Very meaningful work with lives and expensive vehicles on the line.For the other two environments , 1 team had zero process but each of the 9 developers was extremely skilled and conscientious .
Any bug was considered a very personal thing and corrected immediately .
Memory leaks were considered MAJOR bugs and corrected immediately .
No reviews were performed after a design white board presentation .
This was cross platform code used in every NASA mission control center and partner control centers world wide .
We did n't track any bug/issue statistics , but my feeling was we did n't need to .
The software was extremely high quality .
Very meaningful work with lives and expensive vehicles on the line.The last place had normal skill level developers that used no process when I arrived .
They were under so much pressure to add functions that bugs were introduced constantly .
I introduced daily builds and build testing .
We brought in QA and bug tracking software , which we needed very much .
With only 7 developers , we had thousands of bugs .
Most of the bugs were in the GUI , with just a few on the server side .
There was little support from management for any process at all .
We started doing extreme programming and added project management to manage all the changes .
We hired more developers and more and stole people from other teams .
The software got buggier and buggier the more average programmers that we added .
In the end , 3 of the 15 + programmers were highly skilled guys .
They could work on pacemakers or airplane code .
The rest were just trying to get paid and laid .
Then the company was bought out and I left .
Not meaningful work .
Nobody cared whether the code worked or not except the customers .
Almost no motivation beside pay to do it right.In each of the environments above , when the code had to be high quality because lives were on the line , that 's what we got .</tokentext>
<sentencetext>Parent is correct.
METRICS on your review processes is key.
Spend at least a few months carefully gathering data.
Also, it is possible that you aren't motivating the reviewers properly, so the reviews aren't doing all they should?Key questions for any review process:- What is the most efficient number of reviewers?
2 experts is generally the best answer for software- At what stage of the delivery process are bugs found?
Usually, earlier is cheaper to correct than later.- Does your process properly measure "what you really want?
"  Be careful what you measure, because that is what you'll get.I've worked in CMM-5 development and no process environments and somewhere in between.In CMM-5 environments, you "knew" your code was extremely high quality and our multi-level testing teams were extremely frustrated.
The team of 22 developers introduced 1 bug every 2 years.
This was on the space shuttle GN&amp;C flight software.
Very meaningful work with lives and expensive vehicles on the line.For the other two environments, 1 team had zero process but each of the 9 developers was extremely skilled and conscientious.
Any bug was considered a very personal thing and corrected immediately.
Memory leaks were considered MAJOR bugs and corrected immediately.
No reviews were performed after a design white board presentation.
This was cross platform code used in every NASA mission control center and partner control centers world wide.
We didn't track any bug/issue statistics, but my feeling was we didn't need to.
The software was extremely high quality.
Very meaningful work with lives and expensive vehicles on the line.The last place had normal skill level developers that used no process when I arrived.
They were under so much pressure to add functions that bugs were introduced constantly.
I introduced daily builds and build testing.
We brought in QA and bug tracking software, which we needed very much.
With only 7 developers, we had thousands of bugs.
Most of the bugs were in the GUI, with just a few on the server side.
There was little support from management for any process at all.
We started doing extreme programming and added project management to manage all the changes.
We hired more developers and more and stole people from other teams.
The software got buggier and buggier the more average programmers that we added.
In the end, 3 of the 15+ programmers were highly skilled guys.
They could work on pacemakers or airplane code.
The rest were just trying to get paid and laid.
Then the company was bought out and I left.
Not meaningful work.
Nobody cared whether the code worked or not except the customers.
Almost no motivation beside pay to do it right.In each of the environments above, when the code had to be high quality because lives were on the line, that's what we got.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324705</id>
	<title>It's a good start that a code review is an option</title>
	<author>Scroatzilla</author>
	<datestamp>1244915220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I remember when I first started my current job, in a web developer position. We were using "templates" for developing custom products. The templates had about 90\% of what was needed at any given time, but when I was first given a task that was essentially a new feature, I asked naively, "How do we handle this? I see that we're using templates, but this is new. I'd like to code this so that everyone could use it."</p><p>That was met with bafflement. As it turns out, every single developer-- when faced with the same situation-- had simply added to his/her own stash of code that was never shared. Therefore, a lot of time was (and probably still is, I'm not a developer anymore) wasted re-coding stuff that already existed. That is because the notion of delving into code, with the intent to share knowledge in a meeting, was a foreign concept.</p><p>Somewhere in between "zero" code reviews like the situation that I was in, and spending zillions of hours on tedious code reviews which may or may not be useful, there exists the right balance. Like anything other situation, you should avoid useless meetings. But if you have a particular project that would benefit from it in some way-- either from a re-usability or a time-saving or a code maintenance perspective-- I think it's worth it.</p><p>As always, the obstacle is finding someone in management who understands these concepts. I haven't figured out how to effectively explain the "obvious" to PHBs. You would do well to consider communication as a key necessity when wrestling with your question...</p></htmltext>
<tokenext>I remember when I first started my current job , in a web developer position .
We were using " templates " for developing custom products .
The templates had about 90 \ % of what was needed at any given time , but when I was first given a task that was essentially a new feature , I asked naively , " How do we handle this ?
I see that we 're using templates , but this is new .
I 'd like to code this so that everyone could use it .
" That was met with bafflement .
As it turns out , every single developer-- when faced with the same situation-- had simply added to his/her own stash of code that was never shared .
Therefore , a lot of time was ( and probably still is , I 'm not a developer anymore ) wasted re-coding stuff that already existed .
That is because the notion of delving into code , with the intent to share knowledge in a meeting , was a foreign concept.Somewhere in between " zero " code reviews like the situation that I was in , and spending zillions of hours on tedious code reviews which may or may not be useful , there exists the right balance .
Like anything other situation , you should avoid useless meetings .
But if you have a particular project that would benefit from it in some way-- either from a re-usability or a time-saving or a code maintenance perspective-- I think it 's worth it.As always , the obstacle is finding someone in management who understands these concepts .
I have n't figured out how to effectively explain the " obvious " to PHBs .
You would do well to consider communication as a key necessity when wrestling with your question.. .</tokentext>
<sentencetext>I remember when I first started my current job, in a web developer position.
We were using "templates" for developing custom products.
The templates had about 90\% of what was needed at any given time, but when I was first given a task that was essentially a new feature, I asked naively, "How do we handle this?
I see that we're using templates, but this is new.
I'd like to code this so that everyone could use it.
"That was met with bafflement.
As it turns out, every single developer-- when faced with the same situation-- had simply added to his/her own stash of code that was never shared.
Therefore, a lot of time was (and probably still is, I'm not a developer anymore) wasted re-coding stuff that already existed.
That is because the notion of delving into code, with the intent to share knowledge in a meeting, was a foreign concept.Somewhere in between "zero" code reviews like the situation that I was in, and spending zillions of hours on tedious code reviews which may or may not be useful, there exists the right balance.
Like anything other situation, you should avoid useless meetings.
But if you have a particular project that would benefit from it in some way-- either from a re-usability or a time-saving or a code maintenance perspective-- I think it's worth it.As always, the obstacle is finding someone in management who understands these concepts.
I haven't figured out how to effectively explain the "obvious" to PHBs.
You would do well to consider communication as a key necessity when wrestling with your question...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28332489</id>
	<title>Code Reviews ...</title>
	<author>Churam</author>
	<datestamp>1245008940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The importance of code reviews depends of where you work and about how serious people making it are.</p><p>As I see from where I am, code reviews at least tends to bring the code to be easily readable by anybody as it is made to enforce the programmer follow the rules set by the company.<br>As for the cost of code reviews, you can manage them. Some part of it can be made with some script (parsing through files, check for unused variable, compute comment / code ratio by function,<nobr> <wbr></nobr>...) to gives some hints to the reviewer to speed up is process and perhaps find something.</p><p>As for now, you are working on non critical PC software but when you are on some low memory, old crap machines, you like to check if there is any memory leak, or at least memory fragmentation. those can be found with a code review before being found by a user (but yeah, the programmer should find it and fix it before he commits his code).</p></htmltext>
<tokenext>The importance of code reviews depends of where you work and about how serious people making it are.As I see from where I am , code reviews at least tends to bring the code to be easily readable by anybody as it is made to enforce the programmer follow the rules set by the company.As for the cost of code reviews , you can manage them .
Some part of it can be made with some script ( parsing through files , check for unused variable , compute comment / code ratio by function , ... ) to gives some hints to the reviewer to speed up is process and perhaps find something.As for now , you are working on non critical PC software but when you are on some low memory , old crap machines , you like to check if there is any memory leak , or at least memory fragmentation .
those can be found with a code review before being found by a user ( but yeah , the programmer should find it and fix it before he commits his code ) .</tokentext>
<sentencetext>The importance of code reviews depends of where you work and about how serious people making it are.As I see from where I am, code reviews at least tends to bring the code to be easily readable by anybody as it is made to enforce the programmer follow the rules set by the company.As for the cost of code reviews, you can manage them.
Some part of it can be made with some script (parsing through files, check for unused variable, compute comment / code ratio by function, ...) to gives some hints to the reviewer to speed up is process and perhaps find something.As for now, you are working on non critical PC software but when you are on some low memory, old crap machines, you like to check if there is any memory leak, or at least memory fragmentation.
those can be found with a code review before being found by a user (but yeah, the programmer should find it and fix it before he commits his code).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322779</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>piojo</author>
	<datestamp>1244890620000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>how many defects are discovered in the review versus how many make it out the door?</p></div><p>I don't think defects are the only metric. Code reviews can result in a cleaner codebase that's easier to understand. Everyone occasionally writes bad code. A reviewer might say, "I see that it works, but I don't like it..." and mention an alternative solution. A reviewer might suggest that something is non-obvious and that a comment is warranted. Code reviews aren't just for bugs, they are to get better code.</p></div>
	</htmltext>
<tokenext>how many defects are discovered in the review versus how many make it out the door ? I do n't think defects are the only metric .
Code reviews can result in a cleaner codebase that 's easier to understand .
Everyone occasionally writes bad code .
A reviewer might say , " I see that it works , but I do n't like it... " and mention an alternative solution .
A reviewer might suggest that something is non-obvious and that a comment is warranted .
Code reviews are n't just for bugs , they are to get better code .</tokentext>
<sentencetext>how many defects are discovered in the review versus how many make it out the door?I don't think defects are the only metric.
Code reviews can result in a cleaner codebase that's easier to understand.
Everyone occasionally writes bad code.
A reviewer might say, "I see that it works, but I don't like it..." and mention an alternative solution.
A reviewer might suggest that something is non-obvious and that a comment is warranted.
Code reviews aren't just for bugs, they are to get better code.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28388699</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>Anonymous</author>
	<datestamp>1245421080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Sadly every security vulnerability on the products I've worked on were found after shipping in code that was reviewed (and not only that - sometimes very obvious bugs - like treating strings as fixed values, and not checking or sanitizing inputs).</p><p>So I guess they either have to be done right, or they aren't all that useful.</p></div><p>These kinds of bugs should be caught in testing, even if your code review missed it.  Depending on your way of developing code for delivery, test can sometimes be cheaper than code reviews.  Maybe you need to make your testing process a little more rigorous ($$$).<br>Herb</p></div>
	</htmltext>
<tokenext>Sadly every security vulnerability on the products I 've worked on were found after shipping in code that was reviewed ( and not only that - sometimes very obvious bugs - like treating strings as fixed values , and not checking or sanitizing inputs ) .So I guess they either have to be done right , or they are n't all that useful.These kinds of bugs should be caught in testing , even if your code review missed it .
Depending on your way of developing code for delivery , test can sometimes be cheaper than code reviews .
Maybe you need to make your testing process a little more rigorous ( $ $ $ ) .Herb</tokentext>
<sentencetext>Sadly every security vulnerability on the products I've worked on were found after shipping in code that was reviewed (and not only that - sometimes very obvious bugs - like treating strings as fixed values, and not checking or sanitizing inputs).So I guess they either have to be done right, or they aren't all that useful.These kinds of bugs should be caught in testing, even if your code review missed it.
Depending on your way of developing code for delivery, test can sometimes be cheaper than code reviews.
Maybe you need to make your testing process a little more rigorous ($$$).Herb
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322625</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325865</id>
	<title>Re:WTF does maybe mean?</title>
	<author>Anonymous</author>
	<datestamp>1244985660000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>nice...</p></htmltext>
<tokenext>nice.. .</tokentext>
<sentencetext>nice...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323261</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547</id>
	<title>Yes!</title>
	<author>Omnifarious</author>
	<datestamp>1244888940000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>5</modscore>
	<htmltext><p>Code reviews have a lot of value in two ways completely independent of how good they are at catching errors.  First, they are a way to enforce various stylistic guidelines on code that make future maintenance much easier.  Secondly, they are a tool for spreading knowledge about the code around to other members of your development team.</p><p>They can also catch some errors that are very hard to catch in any other way.  I recently worked on a project in which I found an error that would've caused code to only fail in a very limited and non-obvious set of circumstances.  The thing is, somebody would've almost inevitably encountered those circumstances and the phantom and nearly unrepeatable bug reports resulting from this would likely have never been solved.</p><p>I fear code ever stepping off into the land of incorrect behavior as there are few corrective mechanisms that will cajole the errant program back into doing something sane.  The longer it goes without abject failure, the more weirdly wrong it will be.  Therefore I think any and all measures to keep it from ever going there and making sure it dies as quickly as possible if it does are useful.</p></htmltext>
<tokenext>Code reviews have a lot of value in two ways completely independent of how good they are at catching errors .
First , they are a way to enforce various stylistic guidelines on code that make future maintenance much easier .
Secondly , they are a tool for spreading knowledge about the code around to other members of your development team.They can also catch some errors that are very hard to catch in any other way .
I recently worked on a project in which I found an error that would 've caused code to only fail in a very limited and non-obvious set of circumstances .
The thing is , somebody would 've almost inevitably encountered those circumstances and the phantom and nearly unrepeatable bug reports resulting from this would likely have never been solved.I fear code ever stepping off into the land of incorrect behavior as there are few corrective mechanisms that will cajole the errant program back into doing something sane .
The longer it goes without abject failure , the more weirdly wrong it will be .
Therefore I think any and all measures to keep it from ever going there and making sure it dies as quickly as possible if it does are useful .</tokentext>
<sentencetext>Code reviews have a lot of value in two ways completely independent of how good they are at catching errors.
First, they are a way to enforce various stylistic guidelines on code that make future maintenance much easier.
Secondly, they are a tool for spreading knowledge about the code around to other members of your development team.They can also catch some errors that are very hard to catch in any other way.
I recently worked on a project in which I found an error that would've caused code to only fail in a very limited and non-obvious set of circumstances.
The thing is, somebody would've almost inevitably encountered those circumstances and the phantom and nearly unrepeatable bug reports resulting from this would likely have never been solved.I fear code ever stepping off into the land of incorrect behavior as there are few corrective mechanisms that will cajole the errant program back into doing something sane.
The longer it goes without abject failure, the more weirdly wrong it will be.
Therefore I think any and all measures to keep it from ever going there and making sure it dies as quickly as possible if it does are useful.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</id>
	<title>Synergy, leverage, low hanging fruit, etc..</title>
	<author>Anrego</author>
	<datestamp>1244888760000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Having worked on life critical type systems where every line of code was reviewed before making it into the product, I have to say that I've seen them add a lot of value when done properly.</p><p>They also cost a lot.</p><p>The first question I would ask in your situation is: are you doing them right?</p><p>Do bugs get discovered later after deployment? Are the bugs in areas of the code that were supposedly reviewed? If so, you might be doing it wrong.</p><p>And as much as we \_hate\_ the word... I have to say it...</p><p>METRICS!</p><p>If you truly want to make a decision on whether code reviews are worth it.. you need to know:<br>- how much does it cost to conduct the reviews<br>- how many defects are discovered in the review versus how many make it out the door (in other words, how good are you at it)<br>- how how much more does it cost you when a bug gets discovered after deployment? In a life critical system, it costs a fucktonne.. in a desktop app.. it may not be that bad.</p><p>Once you know these, the picture should be clear</p></htmltext>
<tokenext>Having worked on life critical type systems where every line of code was reviewed before making it into the product , I have to say that I 've seen them add a lot of value when done properly.They also cost a lot.The first question I would ask in your situation is : are you doing them right ? Do bugs get discovered later after deployment ?
Are the bugs in areas of the code that were supposedly reviewed ?
If so , you might be doing it wrong.And as much as we \ _hate \ _ the word... I have to say it...METRICS ! If you truly want to make a decision on whether code reviews are worth it.. you need to know : - how much does it cost to conduct the reviews- how many defects are discovered in the review versus how many make it out the door ( in other words , how good are you at it ) - how how much more does it cost you when a bug gets discovered after deployment ?
In a life critical system , it costs a fucktonne.. in a desktop app.. it may not be that bad.Once you know these , the picture should be clear</tokentext>
<sentencetext>Having worked on life critical type systems where every line of code was reviewed before making it into the product, I have to say that I've seen them add a lot of value when done properly.They also cost a lot.The first question I would ask in your situation is: are you doing them right?Do bugs get discovered later after deployment?
Are the bugs in areas of the code that were supposedly reviewed?
If so, you might be doing it wrong.And as much as we \_hate\_ the word... I have to say it...METRICS!If you truly want to make a decision on whether code reviews are worth it.. you need to know:- how much does it cost to conduct the reviews- how many defects are discovered in the review versus how many make it out the door (in other words, how good are you at it)- how how much more does it cost you when a bug gets discovered after deployment?
In a life critical system, it costs a fucktonne.. in a desktop app.. it may not be that bad.Once you know these, the picture should be clear</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324081</id>
	<title>Monk would love stylistic guidelines</title>
	<author>ClosedSource</author>
	<datestamp>1244905620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>" First, they are a way to enforce various stylistic guidelines on code that make future maintenance much easier."</p><p>Yes, I've heard that for many years, but have yet to see any proof that it's true. Perhaps stylistic guidelines are really used because of our compulsion to create order where none is required.</p><p>Besides, checking those guidelines could be performed by any competent admin prior to a review.</p></htmltext>
<tokenext>" First , they are a way to enforce various stylistic guidelines on code that make future maintenance much easier .
" Yes , I 've heard that for many years , but have yet to see any proof that it 's true .
Perhaps stylistic guidelines are really used because of our compulsion to create order where none is required.Besides , checking those guidelines could be performed by any competent admin prior to a review .</tokentext>
<sentencetext>" First, they are a way to enforce various stylistic guidelines on code that make future maintenance much easier.
"Yes, I've heard that for many years, but have yet to see any proof that it's true.
Perhaps stylistic guidelines are really used because of our compulsion to create order where none is required.Besides, checking those guidelines could be performed by any competent admin prior to a review.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323177</id>
	<title>The answer of course is "it depends".</title>
	<author>fooslacker</author>
	<datestamp>1244895000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>What most developers/tech staff don't realize is that code reviews rarely result in a significantly lower bug rate.  Proper unit, integration, and user acceptance testing is your best defense against bugs.  What code reviews do provide is increased code quality with regards to style and supportability as well as some cross training that can benefit support efforts.  It can also benefit performance  and other NFR areas as expert developer help novice developer find less efficient code but if your testing properly tests your NFRs this is less likely to be of any financial benefit other than the growth of your developer staff that might help in a future effort.
<br> <br>
If you have problems with operating / support costs due to poor quality code and code of drastically different styles from different developers then code reviews can help but only if you write good code standards first so everyone is writing to the same standards. This becomes more valuable as the size of the organization grows.  If you have 10 developers the benefit is probably minor compared to if you have 100 developers.
<br> <br>
In general I'm pro design review in ALL situations and I'm pro code review only in instances where I have operating / support issues.</htmltext>
<tokenext>What most developers/tech staff do n't realize is that code reviews rarely result in a significantly lower bug rate .
Proper unit , integration , and user acceptance testing is your best defense against bugs .
What code reviews do provide is increased code quality with regards to style and supportability as well as some cross training that can benefit support efforts .
It can also benefit performance and other NFR areas as expert developer help novice developer find less efficient code but if your testing properly tests your NFRs this is less likely to be of any financial benefit other than the growth of your developer staff that might help in a future effort .
If you have problems with operating / support costs due to poor quality code and code of drastically different styles from different developers then code reviews can help but only if you write good code standards first so everyone is writing to the same standards .
This becomes more valuable as the size of the organization grows .
If you have 10 developers the benefit is probably minor compared to if you have 100 developers .
In general I 'm pro design review in ALL situations and I 'm pro code review only in instances where I have operating / support issues .</tokentext>
<sentencetext>What most developers/tech staff don't realize is that code reviews rarely result in a significantly lower bug rate.
Proper unit, integration, and user acceptance testing is your best defense against bugs.
What code reviews do provide is increased code quality with regards to style and supportability as well as some cross training that can benefit support efforts.
It can also benefit performance  and other NFR areas as expert developer help novice developer find less efficient code but if your testing properly tests your NFRs this is less likely to be of any financial benefit other than the growth of your developer staff that might help in a future effort.
If you have problems with operating / support costs due to poor quality code and code of drastically different styles from different developers then code reviews can help but only if you write good code standards first so everyone is writing to the same standards.
This becomes more valuable as the size of the organization grows.
If you have 10 developers the benefit is probably minor compared to if you have 100 developers.
In general I'm pro design review in ALL situations and I'm pro code review only in instances where I have operating / support issues.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322787</id>
	<title>Practical Programmer: Inspections</title>
	<author>chrisreedy</author>
	<datestamp>1244890680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You should check out this reference: (Apologies, you need access to the ACM Library to read the article) <a href="http://portal.acm.org/citation.cfm?id=299161" title="acm.org" rel="nofollow">http://portal.acm.org/citation.cfm?id=299161</a> [acm.org]. Robert Glass discusses this exact issue. The article offers some references to research done using alternative approaches to inspections.</p></htmltext>
<tokenext>You should check out this reference : ( Apologies , you need access to the ACM Library to read the article ) http : //portal.acm.org/citation.cfm ? id = 299161 [ acm.org ] .
Robert Glass discusses this exact issue .
The article offers some references to research done using alternative approaches to inspections .</tokentext>
<sentencetext>You should check out this reference: (Apologies, you need access to the ACM Library to read the article) http://portal.acm.org/citation.cfm?id=299161 [acm.org].
Robert Glass discusses this exact issue.
The article offers some references to research done using alternative approaches to inspections.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322703</id>
	<title>yes!</title>
	<author>piojo</author>
	<datestamp>1244890020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Well, my last workplace had code reviews for everything, and I found them tremendously helpful. They accomplish a few things:</p><ul> <li>catch basic errors (second set of eyes)</li><li>get new people up to speed (e.g., a more experienced dev says "actually, we have a library that would help here..."). Also, reviews can help an inexperienced engineer become a better developer.</li><li>keep employees abreast of new development (at least two people know about every commit in detail)</li></ul><p>Furthermore, if I edit code that was written by (or is owned by) Bill, I'll ask him to review it so he'll know about the new feature I added (which is good, if he ends up having to support it).</p></htmltext>
<tokenext>Well , my last workplace had code reviews for everything , and I found them tremendously helpful .
They accomplish a few things : catch basic errors ( second set of eyes ) get new people up to speed ( e.g. , a more experienced dev says " actually , we have a library that would help here... " ) .
Also , reviews can help an inexperienced engineer become a better developer.keep employees abreast of new development ( at least two people know about every commit in detail ) Furthermore , if I edit code that was written by ( or is owned by ) Bill , I 'll ask him to review it so he 'll know about the new feature I added ( which is good , if he ends up having to support it ) .</tokentext>
<sentencetext>Well, my last workplace had code reviews for everything, and I found them tremendously helpful.
They accomplish a few things: catch basic errors (second set of eyes)get new people up to speed (e.g., a more experienced dev says "actually, we have a library that would help here...").
Also, reviews can help an inexperienced engineer become a better developer.keep employees abreast of new development (at least two people know about every commit in detail)Furthermore, if I edit code that was written by (or is owned by) Bill, I'll ask him to review it so he'll know about the new feature I added (which is good, if he ends up having to support it).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324871</id>
	<title>Re:a fucktonne?</title>
	<author>bosef1</author>
	<datestamp>1244918760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Unfortunately, the shitload-to-fucktonne conversion depends on the Savage-Santorum thrust/gauge coefficient matrix, which of course varies with load, oscillatory frequency, girth, and country of origin.  For toy problems with minimal covariance, you can handle the second-order "fatty" effects using a first order "Vespa" approximation; but in general the only way to determine the matrix values is by empirical measurement.<nobr> <wbr></nobr>:-(</p><p>It may be noted that the butt-load, or pipe, is equalivalent to two hogsheads, which is 2x63=126 US gallons (108 Imperial accounting for the differences in volume and the size of the hogshead).</p></htmltext>
<tokenext>Unfortunately , the shitload-to-fucktonne conversion depends on the Savage-Santorum thrust/gauge coefficient matrix , which of course varies with load , oscillatory frequency , girth , and country of origin .
For toy problems with minimal covariance , you can handle the second-order " fatty " effects using a first order " Vespa " approximation ; but in general the only way to determine the matrix values is by empirical measurement .
: - ( It may be noted that the butt-load , or pipe , is equalivalent to two hogsheads , which is 2x63 = 126 US gallons ( 108 Imperial accounting for the differences in volume and the size of the hogshead ) .</tokentext>
<sentencetext>Unfortunately, the shitload-to-fucktonne conversion depends on the Savage-Santorum thrust/gauge coefficient matrix, which of course varies with load, oscillatory frequency, girth, and country of origin.
For toy problems with minimal covariance, you can handle the second-order "fatty" effects using a first order "Vespa" approximation; but in general the only way to determine the matrix values is by empirical measurement.
:-(It may be noted that the butt-load, or pipe, is equalivalent to two hogsheads, which is 2x63=126 US gallons (108 Imperial accounting for the differences in volume and the size of the hogshead).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324381</id>
	<title>right and wrong ways</title>
	<author>micromuncher</author>
	<datestamp>1244910720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>As with any software process, there are right and wrong things to do.  First, the formal code review where invitees don't review the code in advance are pointless.  Usually there is so much to go over, even if these are scheduled frequently, that anything more than surface is missed.</p><p>And then when you have a developer do a package and walk through, there are people not to invite.  I've been in reviews where all but one of the reviewees took it seriously, and the one that did not, effectively wanted to review everything in the meeting because they didn't study the prep.  Only invite reviewers that take it seriously.</p><p>A lot of unorganized code reviews degenerate into style comments and surface stuff.  This doesn't help; the most important thing is to have reviewers that bring in their own findings like an audit.  You can delegate things from developer to reviewer, like one reviewer could run through a profiler (ie java findbugs), another through metrics (ie java metricsreloaded), or another with specific data structures and algorithms expertise or concurrency attention.  So... each reviewer can have a role.  Each reviewer is a subject matter expert.</p><p>The best ones in my opinion are where the developer runs the code through a metrics tool to identify hotspots, like complex code, or things that have complex entry/exit conditions.  Things where the developer actively wants to solicit opinions.  Like... "How the heck can I test this?"</p><p>Again it falls to the people though.  Artifacts are really important, as are action items and follow up.  Another example; one review I was in we spotted a developer using floats for guids.  We explained why this was a really bad idea, but because we didn't follow up on it, and neither did the developer, I spent a week hunting down a duplicate spurrious guid conflict.  The team was pretty upset with the developer for not actioning a fix, but our management believed that buy in to process was optional...</p><p>Good luck.  Reviews show professional acumen, but there needs to be some discipline in the prep, review, and follow up.</p></htmltext>
<tokenext>As with any software process , there are right and wrong things to do .
First , the formal code review where invitees do n't review the code in advance are pointless .
Usually there is so much to go over , even if these are scheduled frequently , that anything more than surface is missed.And then when you have a developer do a package and walk through , there are people not to invite .
I 've been in reviews where all but one of the reviewees took it seriously , and the one that did not , effectively wanted to review everything in the meeting because they did n't study the prep .
Only invite reviewers that take it seriously.A lot of unorganized code reviews degenerate into style comments and surface stuff .
This does n't help ; the most important thing is to have reviewers that bring in their own findings like an audit .
You can delegate things from developer to reviewer , like one reviewer could run through a profiler ( ie java findbugs ) , another through metrics ( ie java metricsreloaded ) , or another with specific data structures and algorithms expertise or concurrency attention .
So... each reviewer can have a role .
Each reviewer is a subject matter expert.The best ones in my opinion are where the developer runs the code through a metrics tool to identify hotspots , like complex code , or things that have complex entry/exit conditions .
Things where the developer actively wants to solicit opinions .
Like... " How the heck can I test this ?
" Again it falls to the people though .
Artifacts are really important , as are action items and follow up .
Another example ; one review I was in we spotted a developer using floats for guids .
We explained why this was a really bad idea , but because we did n't follow up on it , and neither did the developer , I spent a week hunting down a duplicate spurrious guid conflict .
The team was pretty upset with the developer for not actioning a fix , but our management believed that buy in to process was optional...Good luck .
Reviews show professional acumen , but there needs to be some discipline in the prep , review , and follow up .</tokentext>
<sentencetext>As with any software process, there are right and wrong things to do.
First, the formal code review where invitees don't review the code in advance are pointless.
Usually there is so much to go over, even if these are scheduled frequently, that anything more than surface is missed.And then when you have a developer do a package and walk through, there are people not to invite.
I've been in reviews where all but one of the reviewees took it seriously, and the one that did not, effectively wanted to review everything in the meeting because they didn't study the prep.
Only invite reviewers that take it seriously.A lot of unorganized code reviews degenerate into style comments and surface stuff.
This doesn't help; the most important thing is to have reviewers that bring in their own findings like an audit.
You can delegate things from developer to reviewer, like one reviewer could run through a profiler (ie java findbugs), another through metrics (ie java metricsreloaded), or another with specific data structures and algorithms expertise or concurrency attention.
So... each reviewer can have a role.
Each reviewer is a subject matter expert.The best ones in my opinion are where the developer runs the code through a metrics tool to identify hotspots, like complex code, or things that have complex entry/exit conditions.
Things where the developer actively wants to solicit opinions.
Like... "How the heck can I test this?
"Again it falls to the people though.
Artifacts are really important, as are action items and follow up.
Another example; one review I was in we spotted a developer using floats for guids.
We explained why this was a really bad idea, but because we didn't follow up on it, and neither did the developer, I spent a week hunting down a duplicate spurrious guid conflict.
The team was pretty upset with the developer for not actioning a fix, but our management believed that buy in to process was optional...Good luck.
Reviews show professional acumen, but there needs to be some discipline in the prep, review, and follow up.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326357</id>
	<title>yes!</title>
	<author>adhocboy</author>
	<datestamp>1244992260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Code reviews are valuable.

Try both automated and human reviews.

Automated reviews are as simple as coming to the table with a profile of the code and quick ratios that make sense to your application.  We run scripts against our source code control system to 'score' certain things... even a basic \% changed is useful in prioritizing human review.  Finding redundant code is another good check.

Human reviews can be useful with the right folks.  Subject matter experts (on the problem space, not technology), senior engineers/architects, and SA/DBAs are always good.  Don't waste time - bring it in, review the high risk areas.  More reviews on common libraries, less (or none) on single use situations.</htmltext>
<tokenext>Code reviews are valuable .
Try both automated and human reviews .
Automated reviews are as simple as coming to the table with a profile of the code and quick ratios that make sense to your application .
We run scripts against our source code control system to 'score ' certain things... even a basic \ % changed is useful in prioritizing human review .
Finding redundant code is another good check .
Human reviews can be useful with the right folks .
Subject matter experts ( on the problem space , not technology ) , senior engineers/architects , and SA/DBAs are always good .
Do n't waste time - bring it in , review the high risk areas .
More reviews on common libraries , less ( or none ) on single use situations .</tokentext>
<sentencetext>Code reviews are valuable.
Try both automated and human reviews.
Automated reviews are as simple as coming to the table with a profile of the code and quick ratios that make sense to your application.
We run scripts against our source code control system to 'score' certain things... even a basic \% changed is useful in prioritizing human review.
Finding redundant code is another good check.
Human reviews can be useful with the right folks.
Subject matter experts (on the problem space, not technology), senior engineers/architects, and SA/DBAs are always good.
Don't waste time - bring it in, review the high risk areas.
More reviews on common libraries, less (or none) on single use situations.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28337513</id>
	<title>I was asking the same question</title>
	<author>jasonofearth</author>
	<datestamp>1245090960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>My company instituted code reviews and I spent some time coming up with why they are useful:

<a href="http://jasonhasalife.blogspot.com/2008/07/code-reviews-are-your-friend.html" title="blogspot.com" rel="nofollow">http://jasonhasalife.blogspot.com/2008/07/code-reviews-are-your-friend.html</a> [blogspot.com]

I am a huge fan, just for what can be learned. But I agree that often corporate 'code reviews' are nothing more than a boring meeting.</htmltext>
<tokenext>My company instituted code reviews and I spent some time coming up with why they are useful : http : //jasonhasalife.blogspot.com/2008/07/code-reviews-are-your-friend.html [ blogspot.com ] I am a huge fan , just for what can be learned .
But I agree that often corporate 'code reviews ' are nothing more than a boring meeting .</tokentext>
<sentencetext>My company instituted code reviews and I spent some time coming up with why they are useful:

http://jasonhasalife.blogspot.com/2008/07/code-reviews-are-your-friend.html [blogspot.com]

I am a huge fan, just for what can be learned.
But I agree that often corporate 'code reviews' are nothing more than a boring meeting.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323103</id>
	<title>Code reviews are manager fodder</title>
	<author>EmperorOfCanada</author>
	<datestamp>1244894100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Personally I am a unit test after coding person. This tends to result in a code review by default. Bad code would have trouble getting past this point in the process.</htmltext>
<tokenext>Personally I am a unit test after coding person .
This tends to result in a code review by default .
Bad code would have trouble getting past this point in the process .</tokentext>
<sentencetext>Personally I am a unit test after coding person.
This tends to result in a code review by default.
Bad code would have trouble getting past this point in the process.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327791</id>
	<title>Re:WTF does maybe mean?</title>
	<author>systrace</author>
	<datestamp>1245007260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Point taken, but perhaps "view source" doesn't show you the original source.
It makes sense that they would strip comments before putting it on the server.

I</htmltext>
<tokenext>Point taken , but perhaps " view source " does n't show you the original source .
It makes sense that they would strip comments before putting it on the server .
I</tokentext>
<sentencetext>Point taken, but perhaps "view source" doesn't show you the original source.
It makes sense that they would strip comments before putting it on the server.
I</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323261</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322737</id>
	<title>Code reviews no match for proper testing</title>
	<author>Anonymous</author>
	<datestamp>1244890200000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Code reviews are of limited use for finding errors, and are certainly no match for structured and comprehensive tests.</p><p>Code reviews are one-shot, while properly written test-suites (on module, integration and system level) are repeatable. This means that you can easily run your test suites again when you change your code, but redoing the code reviews is too great a task. You simply can't re-review your code every time you make changes, but you CAN re-run properly automated test suites.</p><p>Secondly, test suites are deterministic while code reviews aren't. With test suites you can be certain to catch all the error conditions you are testing for, whereas code reviews have random results, depending on the experience, capabilities and attention of the reviewers. You don't want your bug hunting to be non-deterministic</p><p>Put your effort into proper testing, and use code reviews only when everything else fails, or in cases where they're used for enforcing coding guidelines or teaching people how the code works. Then once you got a proper test suite done, maintain it and expand it as you add code and functionality, and more importantly add new test cases every time you encounter a bug.</p></htmltext>
<tokenext>Code reviews are of limited use for finding errors , and are certainly no match for structured and comprehensive tests.Code reviews are one-shot , while properly written test-suites ( on module , integration and system level ) are repeatable .
This means that you can easily run your test suites again when you change your code , but redoing the code reviews is too great a task .
You simply ca n't re-review your code every time you make changes , but you CAN re-run properly automated test suites.Secondly , test suites are deterministic while code reviews are n't .
With test suites you can be certain to catch all the error conditions you are testing for , whereas code reviews have random results , depending on the experience , capabilities and attention of the reviewers .
You do n't want your bug hunting to be non-deterministicPut your effort into proper testing , and use code reviews only when everything else fails , or in cases where they 're used for enforcing coding guidelines or teaching people how the code works .
Then once you got a proper test suite done , maintain it and expand it as you add code and functionality , and more importantly add new test cases every time you encounter a bug .</tokentext>
<sentencetext>Code reviews are of limited use for finding errors, and are certainly no match for structured and comprehensive tests.Code reviews are one-shot, while properly written test-suites (on module, integration and system level) are repeatable.
This means that you can easily run your test suites again when you change your code, but redoing the code reviews is too great a task.
You simply can't re-review your code every time you make changes, but you CAN re-run properly automated test suites.Secondly, test suites are deterministic while code reviews aren't.
With test suites you can be certain to catch all the error conditions you are testing for, whereas code reviews have random results, depending on the experience, capabilities and attention of the reviewers.
You don't want your bug hunting to be non-deterministicPut your effort into proper testing, and use code reviews only when everything else fails, or in cases where they're used for enforcing coding guidelines or teaching people how the code works.
Then once you got a proper test suite done, maintain it and expand it as you add code and functionality, and more importantly add new test cases every time you encounter a bug.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322885</id>
	<title>"Take forever"</title>
	<author>Anonymous</author>
	<datestamp>1244891760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>What we've found is that code reviews take forever<nobr> <wbr></nobr>...</p> </div><p>In one place where I worked in the past, we had a very simple rule: if you are doing a code review, and it takes longer than 10 minutes, then you stop it right there and return the whole thing marked as "overcomplicated" - if it really takes that long, then either the code is written in non-obvious ways and/or poorly commented (which will result in poor maintainability anyway), or the change is too big for one source control commit. By and large, it worked, even if you have to make exceptions occasionally (but at that point you know it's not a typical review, and pay more attention).</p><p>In addition to that, you might want to consider better tooling. If you're doing reviews by sending<nobr> <wbr></nobr>.diff files over email, you're doing it wrong - there are many specialized tools out there that will do automatic and smart diffing (including between rounds in a multi-round CR), notify people responsible for affected files, allow to set up the workflow according to your needs, enable attaching review comments and conversations to particular files and lines of code, and so on. The shop I was working for used <a href="http://smartbear.com/codecollab-features.php" title="smartbear.com">Code Collaborator</a> [smartbear.com] , and I found it to be pretty good, but there are plenty other similar tools out there, and you might even be able to find some good free ones.</p></div>
	</htmltext>
<tokenext>What we 've found is that code reviews take forever ... In one place where I worked in the past , we had a very simple rule : if you are doing a code review , and it takes longer than 10 minutes , then you stop it right there and return the whole thing marked as " overcomplicated " - if it really takes that long , then either the code is written in non-obvious ways and/or poorly commented ( which will result in poor maintainability anyway ) , or the change is too big for one source control commit .
By and large , it worked , even if you have to make exceptions occasionally ( but at that point you know it 's not a typical review , and pay more attention ) .In addition to that , you might want to consider better tooling .
If you 're doing reviews by sending .diff files over email , you 're doing it wrong - there are many specialized tools out there that will do automatic and smart diffing ( including between rounds in a multi-round CR ) , notify people responsible for affected files , allow to set up the workflow according to your needs , enable attaching review comments and conversations to particular files and lines of code , and so on .
The shop I was working for used Code Collaborator [ smartbear.com ] , and I found it to be pretty good , but there are plenty other similar tools out there , and you might even be able to find some good free ones .</tokentext>
<sentencetext>What we've found is that code reviews take forever ... In one place where I worked in the past, we had a very simple rule: if you are doing a code review, and it takes longer than 10 minutes, then you stop it right there and return the whole thing marked as "overcomplicated" - if it really takes that long, then either the code is written in non-obvious ways and/or poorly commented (which will result in poor maintainability anyway), or the change is too big for one source control commit.
By and large, it worked, even if you have to make exceptions occasionally (but at that point you know it's not a typical review, and pay more attention).In addition to that, you might want to consider better tooling.
If you're doing reviews by sending .diff files over email, you're doing it wrong - there are many specialized tools out there that will do automatic and smart diffing (including between rounds in a multi-round CR), notify people responsible for affected files, allow to set up the workflow according to your needs, enable attaching review comments and conversations to particular files and lines of code, and so on.
The shop I was working for used Code Collaborator [smartbear.com] , and I found it to be pretty good, but there are plenty other similar tools out there, and you might even be able to find some good free ones.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325389</id>
	<title>Re:Yes!</title>
	<author>dhavleak</author>
	<datestamp>1244973900000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Absolutely dead right.

</p><p>Code reviews also have an important place in secure development processes. It's important to train all your devs on secure development practices and then have them look for insecure coding while reviewing code. It's not a substitute to having a security expert (in-house or consultant) audit your code - but it's still a valuable step to catch low-hanging stuff like silliness with string buffers, absent-minded sizeof calculations (that could lead to buffer overrun vulnerabilities), etc.

</p><p>Another common defect that tends to be caught in code reviews -- memory leaks. It's nothing that a half-decent stress test won't catch, but I've seen a lot of companies do very half-assed testing with no proper stress testing / leak detection etc. It's <i>relatively</i> common to see a developer forget to close a handle, or absentmindedly use the wrong function to close a handle (happens when using non object-oriented APIs with multiple handle types and consequently multiple handle closing functions) -- this is exacerbated by the fact that people rarely check the return status of a close-handle call. Sometimes even memory allocation/deallocation issues get caught in code reviews.

</p><p>And of couse, that's no substitute for proper stress testing / memory profiling / leak detection.

</p><p>I've found that the best way to maximize what you're getting out of code reviews is to give some thought to what benefits you could get out of it (for example, if you're developing in C# you can toss out the string buffer stuff above, but you can add stuff like dereferencing..). Obviously you should solicit input from all your devs in this step. Next, you should compile that information into an informal guideline (or rather "'things to keep in mind checklist") that people can pin to the wall. Take 10 seconds to scan the list before doing a code-review -- it helps align your thoughts in terms of what you're looking for in the code review.</p></htmltext>
<tokenext>Absolutely dead right .
Code reviews also have an important place in secure development processes .
It 's important to train all your devs on secure development practices and then have them look for insecure coding while reviewing code .
It 's not a substitute to having a security expert ( in-house or consultant ) audit your code - but it 's still a valuable step to catch low-hanging stuff like silliness with string buffers , absent-minded sizeof calculations ( that could lead to buffer overrun vulnerabilities ) , etc .
Another common defect that tends to be caught in code reviews -- memory leaks .
It 's nothing that a half-decent stress test wo n't catch , but I 've seen a lot of companies do very half-assed testing with no proper stress testing / leak detection etc .
It 's relatively common to see a developer forget to close a handle , or absentmindedly use the wrong function to close a handle ( happens when using non object-oriented APIs with multiple handle types and consequently multiple handle closing functions ) -- this is exacerbated by the fact that people rarely check the return status of a close-handle call .
Sometimes even memory allocation/deallocation issues get caught in code reviews .
And of couse , that 's no substitute for proper stress testing / memory profiling / leak detection .
I 've found that the best way to maximize what you 're getting out of code reviews is to give some thought to what benefits you could get out of it ( for example , if you 're developing in C # you can toss out the string buffer stuff above , but you can add stuff like dereferencing.. ) .
Obviously you should solicit input from all your devs in this step .
Next , you should compile that information into an informal guideline ( or rather " 'things to keep in mind checklist " ) that people can pin to the wall .
Take 10 seconds to scan the list before doing a code-review -- it helps align your thoughts in terms of what you 're looking for in the code review .</tokentext>
<sentencetext>Absolutely dead right.
Code reviews also have an important place in secure development processes.
It's important to train all your devs on secure development practices and then have them look for insecure coding while reviewing code.
It's not a substitute to having a security expert (in-house or consultant) audit your code - but it's still a valuable step to catch low-hanging stuff like silliness with string buffers, absent-minded sizeof calculations (that could lead to buffer overrun vulnerabilities), etc.
Another common defect that tends to be caught in code reviews -- memory leaks.
It's nothing that a half-decent stress test won't catch, but I've seen a lot of companies do very half-assed testing with no proper stress testing / leak detection etc.
It's relatively common to see a developer forget to close a handle, or absentmindedly use the wrong function to close a handle (happens when using non object-oriented APIs with multiple handle types and consequently multiple handle closing functions) -- this is exacerbated by the fact that people rarely check the return status of a close-handle call.
Sometimes even memory allocation/deallocation issues get caught in code reviews.
And of couse, that's no substitute for proper stress testing / memory profiling / leak detection.
I've found that the best way to maximize what you're getting out of code reviews is to give some thought to what benefits you could get out of it (for example, if you're developing in C# you can toss out the string buffer stuff above, but you can add stuff like dereferencing..).
Obviously you should solicit input from all your devs in this step.
Next, you should compile that information into an informal guideline (or rather "'things to keep in mind checklist") that people can pin to the wall.
Take 10 seconds to scan the list before doing a code-review -- it helps align your thoughts in terms of what you're looking for in the code review.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323421</id>
	<title>Desk checks vs code reviews</title>
	<author>Anonymous</author>
	<datestamp>1244897460000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>In my organization we separate "code reviews" and "desk checks".</p><p>Code reviews are formal meetings as described in several of the previous threads where you may call in a host of designers who sit down in a conference room, trying to dissect the code. These reviews are held seldom and normally only for major code changes which often affects other subsystems, to find ensure that the changes will not cause unexpected behavior of the system. This is very expensive.</p><p>Desk checks is when you call a team member over, show the code, and describe the changes you've made. This is obviously very cheap.</p><p>We have no hard statistics on the number of faults found in desk checks, but the general opinion is that they are very good to perform because:</p><p>1. everybody can find time to perform them<br>2. the coder receive a confirmation from a second mind/pair of eyes that there are no obvious faults<br>3. even though faults are not often found, the return of investment is high due to the low cost.</p><p>We plan to enforce desk checks on ALL changes. Code reviews will be reserved for the special cases.</p><p>However, desk checks and code reviews will never ever be able to replace a solid regression test. Desk checks are a compliment.</p></htmltext>
<tokenext>In my organization we separate " code reviews " and " desk checks " .Code reviews are formal meetings as described in several of the previous threads where you may call in a host of designers who sit down in a conference room , trying to dissect the code .
These reviews are held seldom and normally only for major code changes which often affects other subsystems , to find ensure that the changes will not cause unexpected behavior of the system .
This is very expensive.Desk checks is when you call a team member over , show the code , and describe the changes you 've made .
This is obviously very cheap.We have no hard statistics on the number of faults found in desk checks , but the general opinion is that they are very good to perform because : 1. everybody can find time to perform them2 .
the coder receive a confirmation from a second mind/pair of eyes that there are no obvious faults3 .
even though faults are not often found , the return of investment is high due to the low cost.We plan to enforce desk checks on ALL changes .
Code reviews will be reserved for the special cases.However , desk checks and code reviews will never ever be able to replace a solid regression test .
Desk checks are a compliment .</tokentext>
<sentencetext>In my organization we separate "code reviews" and "desk checks".Code reviews are formal meetings as described in several of the previous threads where you may call in a host of designers who sit down in a conference room, trying to dissect the code.
These reviews are held seldom and normally only for major code changes which often affects other subsystems, to find ensure that the changes will not cause unexpected behavior of the system.
This is very expensive.Desk checks is when you call a team member over, show the code, and describe the changes you've made.
This is obviously very cheap.We have no hard statistics on the number of faults found in desk checks, but the general opinion is that they are very good to perform because:1. everybody can find time to perform them2.
the coder receive a confirmation from a second mind/pair of eyes that there are no obvious faults3.
even though faults are not often found, the return of investment is high due to the low cost.We plan to enforce desk checks on ALL changes.
Code reviews will be reserved for the special cases.However, desk checks and code reviews will never ever be able to replace a solid regression test.
Desk checks are a compliment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323445</id>
	<title>Re:Synergy, leverage, low hanging fruit, etc..</title>
	<author>Anonymous</author>
	<datestamp>1244897760000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Nah, the fact is that reviews of code take time, and they can be fixed after your former clients find the holes.</p></htmltext>
<tokenext>Nah , the fact is that reviews of code take time , and they can be fixed after your former clients find the holes .</tokentext>
<sentencetext>Nah, the fact is that reviews of code take time, and they can be fixed after your former clients find the holes.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28329861</id>
	<title>Re:they are worth it</title>
	<author>n8r0n</author>
	<datestamp>1244980080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p> the cheapest way to do code reviews is for a manager to just scan submitted code from time to time and send out polite emails if they see something amiss.</p></div></blockquote><p>

If this works for you, then you've got a hell of a lot better managers than most of the software world.  I'm not sure I'd want to leave this responsibility to the guys with pointy hair.</p></div>
	</htmltext>
<tokenext>the cheapest way to do code reviews is for a manager to just scan submitted code from time to time and send out polite emails if they see something amiss .
If this works for you , then you 've got a hell of a lot better managers than most of the software world .
I 'm not sure I 'd want to leave this responsibility to the guys with pointy hair .</tokentext>
<sentencetext> the cheapest way to do code reviews is for a manager to just scan submitted code from time to time and send out polite emails if they see something amiss.
If this works for you, then you've got a hell of a lot better managers than most of the software world.
I'm not sure I'd want to leave this responsibility to the guys with pointy hair.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322751</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324859</id>
	<title>Absolutely</title>
	<author>Anonymous</author>
	<datestamp>1244918640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Code review provides huge benefits.  It may seem like a lot of work to find "just" one or two bugs an hour (and typically a good review will turn up at least that) but those bugs can be fixed without engaging a full QA cycle.  The bugs turned up are often also exactly the kind that don't reliably turn up in test like memory leaks and race conditions.  I've seen situations where just a identified issue provided savings that justified the entire cost of the program.  Those are pretty serious issues but even a typo can produce considerable paperwork if it gets into a release (test&gt;triage&gt;dev&gt;fix&gt;retest).</p></htmltext>
<tokenext>Code review provides huge benefits .
It may seem like a lot of work to find " just " one or two bugs an hour ( and typically a good review will turn up at least that ) but those bugs can be fixed without engaging a full QA cycle .
The bugs turned up are often also exactly the kind that do n't reliably turn up in test like memory leaks and race conditions .
I 've seen situations where just a identified issue provided savings that justified the entire cost of the program .
Those are pretty serious issues but even a typo can produce considerable paperwork if it gets into a release ( test &gt; triage &gt; dev &gt; fix &gt; retest ) .</tokentext>
<sentencetext>Code review provides huge benefits.
It may seem like a lot of work to find "just" one or two bugs an hour (and typically a good review will turn up at least that) but those bugs can be fixed without engaging a full QA cycle.
The bugs turned up are often also exactly the kind that don't reliably turn up in test like memory leaks and race conditions.
I've seen situations where just a identified issue provided savings that justified the entire cost of the program.
Those are pretty serious issues but even a typo can produce considerable paperwork if it gets into a release (test&gt;triage&gt;dev&gt;fix&gt;retest).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325709</id>
	<title>Code reviews are a question of life and death</title>
	<author>GPLHost-Thomas</author>
	<datestamp>1244981820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The recent story about HyperVM security holes teaches that code reviews can be a question of life and death. See the story on <a href="http://www.theregister.co.uk/2009/06/09/lxlabs\_funder\_death/" title="theregister.co.uk" rel="nofollow">the register</a> [theregister.co.uk] and maybe you will understand... Sad...<br> <br>

Thomas</htmltext>
<tokenext>The recent story about HyperVM security holes teaches that code reviews can be a question of life and death .
See the story on the register [ theregister.co.uk ] and maybe you will understand... Sad.. . Thomas</tokentext>
<sentencetext>The recent story about HyperVM security holes teaches that code reviews can be a question of life and death.
See the story on the register [theregister.co.uk] and maybe you will understand... Sad... 

Thomas</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323469</id>
	<title>Re:Code reviews are manager fodder</title>
	<author>ivan256</author>
	<datestamp>1244898060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I work on a small team (20 developers). Every day I see at least one bug in highly unit tested code that wouldn't have made it past a code review.</p><p>Unit tests are a situationally appropriate tool. But they are not a replacement for a review on any team larger than a few people. You have to understand every possible interaction between what you're changing and the rest of the system to write a 100\% effective unit test. That just can't happen once you have a few dozen people writing your product.</p></htmltext>
<tokenext>I work on a small team ( 20 developers ) .
Every day I see at least one bug in highly unit tested code that would n't have made it past a code review.Unit tests are a situationally appropriate tool .
But they are not a replacement for a review on any team larger than a few people .
You have to understand every possible interaction between what you 're changing and the rest of the system to write a 100 \ % effective unit test .
That just ca n't happen once you have a few dozen people writing your product .</tokentext>
<sentencetext>I work on a small team (20 developers).
Every day I see at least one bug in highly unit tested code that wouldn't have made it past a code review.Unit tests are a situationally appropriate tool.
But they are not a replacement for a review on any team larger than a few people.
You have to understand every possible interaction between what you're changing and the rest of the system to write a 100\% effective unit test.
That just can't happen once you have a few dozen people writing your product.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323103</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324681</id>
	<title>Yes it's a waste of time unless..</title>
	<author>Anonymous</author>
	<datestamp>1244914860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Unless you have a bunch of 2-bit hacks fresh out of tech school/Uni. Otherwise good programmers can review their own code safely and effectively. Using automated styling-enforcement in Eclipse will keep everything clean and 99\% of all algorithms you need are just library classes which have already been reviewed and optimized.</p><p>Now if you're a code-shop using<nobr> <wbr></nobr>.net and $5/hr Indian programmers...</p></htmltext>
<tokenext>Unless you have a bunch of 2-bit hacks fresh out of tech school/Uni .
Otherwise good programmers can review their own code safely and effectively .
Using automated styling-enforcement in Eclipse will keep everything clean and 99 \ % of all algorithms you need are just library classes which have already been reviewed and optimized.Now if you 're a code-shop using .net and $ 5/hr Indian programmers.. .</tokentext>
<sentencetext>Unless you have a bunch of 2-bit hacks fresh out of tech school/Uni.
Otherwise good programmers can review their own code safely and effectively.
Using automated styling-enforcement in Eclipse will keep everything clean and 99\% of all algorithms you need are just library classes which have already been reviewed and optimized.Now if you're a code-shop using .net and $5/hr Indian programmers...</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322741</id>
	<title>Re:If you're code review is taking forever...</title>
	<author>sakdoctor</author>
	<datestamp>1244890200000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My code is self reviewing.</p></htmltext>
<tokenext>My code is self reviewing .</tokentext>
<sentencetext>My code is self reviewing.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603</id>
	<title>If you're code review is taking forever...</title>
	<author>ciroknight</author>
	<datestamp>1244889360000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>then you're doing it wrong. Plain and simple.<br> <br>
Code reviews shouldn't be a "full stop, let's go over this" event. Code review should be a part of the every day workings of the development team. Nothing should go into version control's master/trunk/HEAD until it has been reviewed.
<br> <br>
Sometimes you'll find that stopping to review a single module is helpful, but most of the time it's actively harmful to the team, since it takes developer's concentration off of what they're currently working on to review things that they half-don't-remember, which then makes the code review take forever.
<br> <br>
Review and document inline with your coding, and you'll find you'll never need a "Full Stop" review.</htmltext>
<tokenext>then you 're doing it wrong .
Plain and simple .
Code reviews should n't be a " full stop , let 's go over this " event .
Code review should be a part of the every day workings of the development team .
Nothing should go into version control 's master/trunk/HEAD until it has been reviewed .
Sometimes you 'll find that stopping to review a single module is helpful , but most of the time it 's actively harmful to the team , since it takes developer 's concentration off of what they 're currently working on to review things that they half-do n't-remember , which then makes the code review take forever .
Review and document inline with your coding , and you 'll find you 'll never need a " Full Stop " review .</tokentext>
<sentencetext>then you're doing it wrong.
Plain and simple.
Code reviews shouldn't be a "full stop, let's go over this" event.
Code review should be a part of the every day workings of the development team.
Nothing should go into version control's master/trunk/HEAD until it has been reviewed.
Sometimes you'll find that stopping to review a single module is helpful, but most of the time it's actively harmful to the team, since it takes developer's concentration off of what they're currently working on to review things that they half-don't-remember, which then makes the code review take forever.
Review and document inline with your coding, and you'll find you'll never need a "Full Stop" review.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322751</id>
	<title>they are worth it</title>
	<author>acidrain</author>
	<datestamp>1244890440000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><blockquote><div><p>no</p></div></blockquote><p>
You often *have* to review a entry level programmer's work until it reaches an acceptable quality.  I consider code reviews as a method of improving the programmer more so than the code.  One an engineer is producing generally acceptable code it becomes safe enough to treat their code as a black box and wait for problems to be unearthed by testing.  If you are shipping bugs your problem is testing, not code reviews.  Finally, the cheapest way to do code reviews is for a manager to just scan submitted code from time to time and send out polite emails if they see something amiss.  On the other hand getting five senior guys in a room to discuss the work of another senior engineer is a just going to result in unproductive, cranky engineers.</p></div>
	</htmltext>
<tokenext>no You often * have * to review a entry level programmer 's work until it reaches an acceptable quality .
I consider code reviews as a method of improving the programmer more so than the code .
One an engineer is producing generally acceptable code it becomes safe enough to treat their code as a black box and wait for problems to be unearthed by testing .
If you are shipping bugs your problem is testing , not code reviews .
Finally , the cheapest way to do code reviews is for a manager to just scan submitted code from time to time and send out polite emails if they see something amiss .
On the other hand getting five senior guys in a room to discuss the work of another senior engineer is a just going to result in unproductive , cranky engineers .</tokentext>
<sentencetext>no
You often *have* to review a entry level programmer's work until it reaches an acceptable quality.
I consider code reviews as a method of improving the programmer more so than the code.
One an engineer is producing generally acceptable code it becomes safe enough to treat their code as a black box and wait for problems to be unearthed by testing.
If you are shipping bugs your problem is testing, not code reviews.
Finally, the cheapest way to do code reviews is for a manager to just scan submitted code from time to time and send out polite emails if they see something amiss.
On the other hand getting five senior guys in a room to discuss the work of another senior engineer is a just going to result in unproductive, cranky engineers.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323211</id>
	<title>No, they're not worth it.</title>
	<author>kimanaw</author>
	<datestamp>1244895360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Code reviews are highly subjective, human endeavors. I've certainly wasted more than a little of my life in "reviews" that were nothing more than
personality driven, agenda laden time-wasters that usually surfaced little more than grammatical erros in comments. *If* the reviewers actually
bother to look at the code before making comments.<p>

Here's a little exersize you might want your boss to be involved in:

</p><ul>
<li>Grab an arbitrary piece of code from outside your organization. </li><li>Inject 10 or so errors or other issues into it</li><li>Divide your usual review crew into 2 groups to review the code separately. </li><li>Tell one group that the code was written by a new intern, so you'd like them to eyeball it.</li><li>Tell the other group that the code was written by your most senior developer (preferably, one w/ a big ego),
and they need to review it "cuz the boss says we have to"</li><li>Compare how many issues each group finds/reports.</li></ul><p>

I suspect you already have a good idea what the outcome will be. That should be enough to tell you how effective code reviews are.</p><p>

Automated code formatters/code inspectors, along with decent compilers/linkers (or interpreters) will surface most of the
issues that code reviews find.</p><p>

Instead of pissing away valuable developer time, put those reviewers to work <b>writing and executing tests</b>. Right away, you'll discover
whether the code is testable. And then you'll discover whether its actually correct.</p><p>

Tests don't have egos, agendas, personal axes to grind, or coworkers they don't want to piss off. They don't take vacations or sick days.
They don't have opinions about the author of the code. They usually don't leave the company. They generally don't have an opinion about
how many/few comments there are, or if the code has been formatted to corporate spec (unless those tests are executed as part of the
automated tools mentioned above). Sure they can be drudgery to write, but its the only real way to know if the code actually does
whats its supposed to.</p></htmltext>
<tokenext>Code reviews are highly subjective , human endeavors .
I 've certainly wasted more than a little of my life in " reviews " that were nothing more than personality driven , agenda laden time-wasters that usually surfaced little more than grammatical erros in comments .
* If * the reviewers actually bother to look at the code before making comments .
Here 's a little exersize you might want your boss to be involved in : Grab an arbitrary piece of code from outside your organization .
Inject 10 or so errors or other issues into itDivide your usual review crew into 2 groups to review the code separately .
Tell one group that the code was written by a new intern , so you 'd like them to eyeball it.Tell the other group that the code was written by your most senior developer ( preferably , one w/ a big ego ) , and they need to review it " cuz the boss says we have to " Compare how many issues each group finds/reports .
I suspect you already have a good idea what the outcome will be .
That should be enough to tell you how effective code reviews are .
Automated code formatters/code inspectors , along with decent compilers/linkers ( or interpreters ) will surface most of the issues that code reviews find .
Instead of pissing away valuable developer time , put those reviewers to work writing and executing tests .
Right away , you 'll discover whether the code is testable .
And then you 'll discover whether its actually correct .
Tests do n't have egos , agendas , personal axes to grind , or coworkers they do n't want to piss off .
They do n't take vacations or sick days .
They do n't have opinions about the author of the code .
They usually do n't leave the company .
They generally do n't have an opinion about how many/few comments there are , or if the code has been formatted to corporate spec ( unless those tests are executed as part of the automated tools mentioned above ) .
Sure they can be drudgery to write , but its the only real way to know if the code actually does whats its supposed to .</tokentext>
<sentencetext>Code reviews are highly subjective, human endeavors.
I've certainly wasted more than a little of my life in "reviews" that were nothing more than
personality driven, agenda laden time-wasters that usually surfaced little more than grammatical erros in comments.
*If* the reviewers actually
bother to look at the code before making comments.
Here's a little exersize you might want your boss to be involved in:


Grab an arbitrary piece of code from outside your organization.
Inject 10 or so errors or other issues into itDivide your usual review crew into 2 groups to review the code separately.
Tell one group that the code was written by a new intern, so you'd like them to eyeball it.Tell the other group that the code was written by your most senior developer (preferably, one w/ a big ego),
and they need to review it "cuz the boss says we have to"Compare how many issues each group finds/reports.
I suspect you already have a good idea what the outcome will be.
That should be enough to tell you how effective code reviews are.
Automated code formatters/code inspectors, along with decent compilers/linkers (or interpreters) will surface most of the
issues that code reviews find.
Instead of pissing away valuable developer time, put those reviewers to work writing and executing tests.
Right away, you'll discover
whether the code is testable.
And then you'll discover whether its actually correct.
Tests don't have egos, agendas, personal axes to grind, or coworkers they don't want to piss off.
They don't take vacations or sick days.
They don't have opinions about the author of the code.
They usually don't leave the company.
They generally don't have an opinion about
how many/few comments there are, or if the code has been formatted to corporate spec (unless those tests are executed as part of the
automated tools mentioned above).
Sure they can be drudgery to write, but its the only real way to know if the code actually does
whats its supposed to.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324875</id>
	<title>Re:Delusions of grandeur</title>
	<author>cryptoluddite</author>
	<datestamp>1244918820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Code reviews are like testing... it's only worth doing if the quality is already high.  A tester that ever has to file a bug like "crashes if run with zero args, or 5 or more args" is going to shoot somebody or just phone it in.  Same with code reviews.  If you have to explain to somebody why their use of a bubble sort is "not a good solution" then there is no point in doing one in the first place.  It's just wasting people's time.</p><p>But on the other hand if you go to a code review and see some code implementing chmod octal and oug+-rwx,... syntax in 40 lines compiling to ~200 bytes of assembly you're going to say 'damn, that's cool' and it'll pump everybody up and they might learn a few things about binary operations and masks.  You might catch some errors too, that's nice, but the main point of the review should be to learn about the code and to learn better programming.  If you want to use them to catch errors, you should use testing and auditing of the code instead (if the presence of a bug is important enough to convene a meeting to look the for the mere possibility of it existing, then you need to really get serious about it).</p></htmltext>
<tokenext>Code reviews are like testing... it 's only worth doing if the quality is already high .
A tester that ever has to file a bug like " crashes if run with zero args , or 5 or more args " is going to shoot somebody or just phone it in .
Same with code reviews .
If you have to explain to somebody why their use of a bubble sort is " not a good solution " then there is no point in doing one in the first place .
It 's just wasting people 's time.But on the other hand if you go to a code review and see some code implementing chmod octal and oug + -rwx,... syntax in 40 lines compiling to ~ 200 bytes of assembly you 're going to say 'damn , that 's cool ' and it 'll pump everybody up and they might learn a few things about binary operations and masks .
You might catch some errors too , that 's nice , but the main point of the review should be to learn about the code and to learn better programming .
If you want to use them to catch errors , you should use testing and auditing of the code instead ( if the presence of a bug is important enough to convene a meeting to look the for the mere possibility of it existing , then you need to really get serious about it ) .</tokentext>
<sentencetext>Code reviews are like testing... it's only worth doing if the quality is already high.
A tester that ever has to file a bug like "crashes if run with zero args, or 5 or more args" is going to shoot somebody or just phone it in.
Same with code reviews.
If you have to explain to somebody why their use of a bubble sort is "not a good solution" then there is no point in doing one in the first place.
It's just wasting people's time.But on the other hand if you go to a code review and see some code implementing chmod octal and oug+-rwx,... syntax in 40 lines compiling to ~200 bytes of assembly you're going to say 'damn, that's cool' and it'll pump everybody up and they might learn a few things about binary operations and masks.
You might catch some errors too, that's nice, but the main point of the review should be to learn about the code and to learn better programming.
If you want to use them to catch errors, you should use testing and auditing of the code instead (if the presence of a bug is important enough to convene a meeting to look the for the mere possibility of it existing, then you need to really get serious about it).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324473</id>
	<title>Read an XP book</title>
	<author>Anonymous</author>
	<datestamp>1244912100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>XP advocates to pair program 100\% of the time. I would suggest that you guys try to work pairing into your development schedule. Most people are afraid because they feel as though it will slow down their velocity but it should actually accelerate it. You'd be done with the lengthy code review process, which is silly in my opinion. It's almost always better to have 2 eyes on code than 1. It keeps the developers engaged if they ping pong back and fourth (taking turns to code/test). It reduces the number of bugs. It increases the readability of the code (now both have to agree on how readable it is). It also helps spread the knowledge amongst more than just a single person (what if one got hit by a bus the following day?).</p></htmltext>
<tokenext>XP advocates to pair program 100 \ % of the time .
I would suggest that you guys try to work pairing into your development schedule .
Most people are afraid because they feel as though it will slow down their velocity but it should actually accelerate it .
You 'd be done with the lengthy code review process , which is silly in my opinion .
It 's almost always better to have 2 eyes on code than 1 .
It keeps the developers engaged if they ping pong back and fourth ( taking turns to code/test ) .
It reduces the number of bugs .
It increases the readability of the code ( now both have to agree on how readable it is ) .
It also helps spread the knowledge amongst more than just a single person ( what if one got hit by a bus the following day ?
) .</tokentext>
<sentencetext>XP advocates to pair program 100\% of the time.
I would suggest that you guys try to work pairing into your development schedule.
Most people are afraid because they feel as though it will slow down their velocity but it should actually accelerate it.
You'd be done with the lengthy code review process, which is silly in my opinion.
It's almost always better to have 2 eyes on code than 1.
It keeps the developers engaged if they ping pong back and fourth (taking turns to code/test).
It reduces the number of bugs.
It increases the readability of the code (now both have to agree on how readable it is).
It also helps spread the knowledge amongst more than just a single person (what if one got hit by a bus the following day?
).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28329379</id>
	<title>Hard to say...</title>
	<author>Anonymous</author>
	<datestamp>1244975100000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>     I'd say it's hard to say.  If you are going to be expected to keep adding features, or work on something else, then the code reviews would be useless -- you could find out some code is crap but would not be given the time to do anything about it, as long as it barely works.  If you have some control over improving the product, then do code reviews.  Sounds to me like your current boss is in the first camp, doing code reviews wouldn't help at all then.</p></htmltext>
<tokenext>I 'd say it 's hard to say .
If you are going to be expected to keep adding features , or work on something else , then the code reviews would be useless -- you could find out some code is crap but would not be given the time to do anything about it , as long as it barely works .
If you have some control over improving the product , then do code reviews .
Sounds to me like your current boss is in the first camp , doing code reviews would n't help at all then .</tokentext>
<sentencetext>     I'd say it's hard to say.
If you are going to be expected to keep adding features, or work on something else, then the code reviews would be useless -- you could find out some code is crap but would not be given the time to do anything about it, as long as it barely works.
If you have some control over improving the product, then do code reviews.
Sounds to me like your current boss is in the first camp, doing code reviews wouldn't help at all then.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323991</id>
	<title>should be nearly mandatory</title>
	<author>OrangeTide</author>
	<datestamp>1244904360000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Get a software package or share "diffs" via email. You should really not accept code until at least 1 or 2 other people have taking a quick look through the changes.<br>Code reviews are important not only to filter out mistakes, but to also make sure multiple people are familiarized with the code.<br>But managers are really bad at handling special cases. Sometimes it's more important to commit code than to do a code review (at my work we can't svn commit until we put in Review Board entry that has at least two "ship its"), flexibility in process is also very important. Most companies don't "get" that, they just look for a silver bullet they can apply broadly.</p></htmltext>
<tokenext>Get a software package or share " diffs " via email .
You should really not accept code until at least 1 or 2 other people have taking a quick look through the changes.Code reviews are important not only to filter out mistakes , but to also make sure multiple people are familiarized with the code.But managers are really bad at handling special cases .
Sometimes it 's more important to commit code than to do a code review ( at my work we ca n't svn commit until we put in Review Board entry that has at least two " ship its " ) , flexibility in process is also very important .
Most companies do n't " get " that , they just look for a silver bullet they can apply broadly .</tokentext>
<sentencetext>Get a software package or share "diffs" via email.
You should really not accept code until at least 1 or 2 other people have taking a quick look through the changes.Code reviews are important not only to filter out mistakes, but to also make sure multiple people are familiarized with the code.But managers are really bad at handling special cases.
Sometimes it's more important to commit code than to do a code review (at my work we can't svn commit until we put in Review Board entry that has at least two "ship its"), flexibility in process is also very important.
Most companies don't "get" that, they just look for a silver bullet they can apply broadly.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323003</id>
	<title>We do this. It's valuable.</title>
	<author>erikharrison</author>
	<datestamp>1244892960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In my shop, there is no formal code review process. But informally, we all have to maintain this stuff, and there aren't enough of us that everyone gets one nice, clearly demarcated area of responsibility. So in that principle, there is a strong informal process.</p><p>In the course of designing a piece of software, or subsystem there is a lot of "Okay, here is my approach. See any pitfalls?" During implementation, there is a lot of over the shoulder "could you take this over?". And once a piece of code is ready to be merged into trunk, a fresh pair of eyes are pulled over, and the code is looked over.</p><p>It's a lightweight process, code gets checked numerous times, and we don't run into cases where you suddenly have to review several thousands of lines of code. This has caught numerous bugs, time and time again, and catches the kinds of bugs that user level testing can be the worst at finding - corner cases and intermittent issues.</p></htmltext>
<tokenext>In my shop , there is no formal code review process .
But informally , we all have to maintain this stuff , and there are n't enough of us that everyone gets one nice , clearly demarcated area of responsibility .
So in that principle , there is a strong informal process.In the course of designing a piece of software , or subsystem there is a lot of " Okay , here is my approach .
See any pitfalls ?
" During implementation , there is a lot of over the shoulder " could you take this over ? " .
And once a piece of code is ready to be merged into trunk , a fresh pair of eyes are pulled over , and the code is looked over.It 's a lightweight process , code gets checked numerous times , and we do n't run into cases where you suddenly have to review several thousands of lines of code .
This has caught numerous bugs , time and time again , and catches the kinds of bugs that user level testing can be the worst at finding - corner cases and intermittent issues .</tokentext>
<sentencetext>In my shop, there is no formal code review process.
But informally, we all have to maintain this stuff, and there aren't enough of us that everyone gets one nice, clearly demarcated area of responsibility.
So in that principle, there is a strong informal process.In the course of designing a piece of software, or subsystem there is a lot of "Okay, here is my approach.
See any pitfalls?
" During implementation, there is a lot of over the shoulder "could you take this over?".
And once a piece of code is ready to be merged into trunk, a fresh pair of eyes are pulled over, and the code is looked over.It's a lightweight process, code gets checked numerous times, and we don't run into cases where you suddenly have to review several thousands of lines of code.
This has caught numerous bugs, time and time again, and catches the kinds of bugs that user level testing can be the worst at finding - corner cases and intermittent issues.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327285</id>
	<title>Their code is a successful as their country.</title>
	<author>Anonymous</author>
	<datestamp>1245002280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>H1B Visa Indians modded the parent post "Troll".</htmltext>
<tokenext>H1B Visa Indians modded the parent post " Troll " .</tokentext>
<sentencetext>H1B Visa Indians modded the parent post "Troll".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322549</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322631</id>
	<title>Signs point to yes</title>
	<author>ucblockhead</author>
	<datestamp>1244889600000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>My group started implementing code reviews this month.  To get in the swing of things, we decided to do a test review of existing foundation code, stuff that had been in the product for many months, had gone through multiple QA cycles, and had been shipped to the customer as part of the first "production" release.</p><p>In the first hour-long review, we found a number of significant issues, and one full-blown bug.</p></htmltext>
<tokenext>My group started implementing code reviews this month .
To get in the swing of things , we decided to do a test review of existing foundation code , stuff that had been in the product for many months , had gone through multiple QA cycles , and had been shipped to the customer as part of the first " production " release.In the first hour-long review , we found a number of significant issues , and one full-blown bug .</tokentext>
<sentencetext>My group started implementing code reviews this month.
To get in the swing of things, we decided to do a test review of existing foundation code, stuff that had been in the product for many months, had gone through multiple QA cycles, and had been shipped to the customer as part of the first "production" release.In the first hour-long review, we found a number of significant issues, and one full-blown bug.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28346433</id>
	<title>Re:a fucktonne?</title>
	<author>dstones</author>
	<datestamp>1245159780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Damn europeans and their metric system.</p></div><p>lol heads up dude.  its about everyone BUT the US that uses the metric system.</p></div>
	</htmltext>
<tokenext>Damn europeans and their metric system.lol heads up dude .
its about everyone BUT the US that uses the metric system .</tokentext>
<sentencetext>Damn europeans and their metric system.lol heads up dude.
its about everyone BUT the US that uses the metric system.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322675
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322771
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323647
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324875
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323545
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324871
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28332383
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323199
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325085
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323641
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323831
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323445
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28336155
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28328961
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325201
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322883
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323261
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325865
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324027
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322549
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327285
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322955
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28331323
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322625
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325533
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323129
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323199
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28334479
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28330761
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322779
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326487
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325389
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322675
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323611
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323559
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28346409
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325325
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325607
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323911
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322881
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28337949
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322779
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322931
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325129
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28346433
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322625
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28388699
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327041
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28470583
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28333429
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28333895
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322675
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322849
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28330347
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325697
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324081
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326417
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28339003
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323243
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324935
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322741
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323261
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327791
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322751
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28329861
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322743
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324995
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323263
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323107
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322739
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324577
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325105
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323103
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323469
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_13_1859216_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28353139
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322835
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28333895
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323831
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323911
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324875
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322703
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322675
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323611
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322849
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28330347
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322771
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323647
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323103
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323469
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322549
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327285
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322623
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322613
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322637
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322631
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322531
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325325
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325201
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325105
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322751
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28329861
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322837
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323559
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28330761
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28353139
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28328961
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28332383
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322739
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322547
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323243
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323199
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325085
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28334479
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322881
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324935
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28337949
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325389
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324081
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323261
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325865
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327791
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323391
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322639
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322885
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322603
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323107
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323545
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322741
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323641
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322883
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322685
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322743
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324995
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322533
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28470583
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28339003
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322955
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324577
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325697
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323263
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323119
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324871
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28324027
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28327041
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28331323
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28346409
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28333429
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28346433
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325607
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28336155
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322625
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28388699
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325533
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323129
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326417
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322779
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322931
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28325129
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28326487
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323445
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28323963
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322643
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322601
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322917
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_13_1859216.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_13_1859216.28322787
</commentlist>
</conversation>
