<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Bugging Your Code Reviews – See if your peers are really reading your code.</title>
	<atom:link href="http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/feed/" rel="self" type="application/rss+xml" />
	<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/</link>
	<description>Al Sweigart&#039;s blog.</description>
	<lastBuildDate>Fri, 27 Apr 2012 00:50:31 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Alexwebmaster</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-48137</link>
		<dc:creator>Alexwebmaster</dc:creator>
		<pubDate>Tue, 03 Mar 2009 13:23:36 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-48137</guid>
		<description>Hello webmaster
I would like to share with you a link to your site
write me here preonrelt@mail.ru</description>
		<content:encoded><![CDATA[<p>Hello webmaster<br />
I would like to share with you a link to your site<br />
write me here <a href="mailto:preonrelt@mail.ru">preonrelt@mail.ru</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bobo The Sperm Whale</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-15848</link>
		<dc:creator>Bobo The Sperm Whale</dc:creator>
		<pubDate>Wed, 27 Aug 2008 14:57:55 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-15848</guid>
		<description>Throw in a multi-threaded race condition memory corruption bug for kicks!  They&#039;re like, sooo easy to spot too.</description>
		<content:encoded><![CDATA[<p>Throw in a multi-threaded race condition memory corruption bug for kicks!  They&#8217;re like, sooo easy to spot too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Maintenance Man</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-15530</link>
		<dc:creator>Maintenance Man</dc:creator>
		<pubDate>Sat, 23 Aug 2008 08:38:30 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-15530</guid>
		<description>I have heard of this idea before. And I think it is called Defect Injection. You basically game the code to be reviewed to see whether your peer review process is working.
Recently I asked my manager if we could try this at my work. He was very supportive. Previously my project has done peer reviews with great success. However the practice has fallen to the side due to the normal pressuress of software development.
Thanks for the post.</description>
		<content:encoded><![CDATA[<p>I have heard of this idea before. And I think it is called Defect Injection. You basically game the code to be reviewed to see whether your peer review process is working.</p>
<p>Recently I asked my manager if we could try this at my work. He was very supportive. Previously my project has done peer reviews with great success. However the practice has fallen to the side due to the normal pressuress of software development.</p>
<p>Thanks for the post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob C</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-15504</link>
		<dc:creator>Bob C</dc:creator>
		<pubDate>Fri, 22 Aug 2008 23:43:28 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-15504</guid>
		<description>Also - Its important to realize that many things cannot be tested with Unit tests or even jester bugs being inserted. What about style or UI issues that are blatent that go ignored or unaddressed?
You may not be able to automate everything away, as many people of the geek mentality appear to believe. I happen to be a huge proponent of using technology for what it is good for and find people trying to use it in incorrect ways abhorrent.
Let me know your thoughts
=) Huge fan and follower.
You may appreciate the many responses to your videos from on my blog. Keep up the good, clear, rational thought process.</description>
		<content:encoded><![CDATA[<p>Also &#8211; Its important to realize that many things cannot be tested with Unit tests or even jester bugs being inserted. What about style or UI issues that are blatent that go ignored or unaddressed?</p>
<p>You may not be able to automate everything away, as many people of the geek mentality appear to believe. I happen to be a huge proponent of using technology for what it is good for and find people trying to use it in incorrect ways abhorrent. </p>
<p>Let me know your thoughts </p>
<p>=) Huge fan and follower.</p>
<p>You may appreciate the many responses to your videos from on my blog. Keep up the good, clear, rational thought process.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob C</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-15503</link>
		<dc:creator>Bob C</dc:creator>
		<pubDate>Fri, 22 Aug 2008 23:39:23 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-15503</guid>
		<description>I think this is a brilliant idea, in that i aspire to be a shrink wrap software developer one day and have become the goto guy for code reviews. Unfortunately the mindset that voladia is tossing about, as well as the 80/20 rule are really prevalent here.
I review two people code on a regular basis, both are back end apps and notorious for crappy adherence to standards or anything else for that matter, so i get my times worth.
My question to you is... when i submit my code changes for review how do you think i should respond when i get a failure in response? How should i react when they come back the fourth time and have just refused to notice the semi-colon on the end of my if statement?</description>
		<content:encoded><![CDATA[<p>I think this is a brilliant idea, in that i aspire to be a shrink wrap software developer one day and have become the goto guy for code reviews. Unfortunately the mindset that voladia is tossing about, as well as the 80/20 rule are really prevalent here. </p>
<p>I review two people code on a regular basis, both are back end apps and notorious for crappy adherence to standards or anything else for that matter, so i get my times worth. </p>
<p>My question to you is&#8230; when i submit my code changes for review how do you think i should respond when i get a failure in response? How should i react when they come back the fourth time and have just refused to notice the semi-colon on the end of my if statement?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AlSweigart</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-15500</link>
		<dc:creator>AlSweigart</dc:creator>
		<pubDate>Fri, 22 Aug 2008 22:45:50 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-15500</guid>
		<description>voladia: It is exactly that &quot;push product out the door&quot; mindset that causes people to skip doing real code reviews. At that point, you have no way of telling if they are being effective.
The best way to keep costs down (and support the business) is to catch bugs as early as possible and BEFORE they are found by the public.</description>
		<content:encoded><![CDATA[<p>voladia: It is exactly that &#8220;push product out the door&#8221; mindset that causes people to skip doing real code reviews. At that point, you have no way of telling if they are being effective.</p>
<p>The best way to keep costs down (and support the business) is to catch bugs as early as possible and BEFORE they are found by the public.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: voladia</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-15499</link>
		<dc:creator>voladia</dc:creator>
		<pubDate>Fri, 22 Aug 2008 22:40:00 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-15499</guid>
		<description>What a waste of time. We write software to push product out door to support business. If we delay push through petty actions, we increase our business&#039;s expenses.</description>
		<content:encoded><![CDATA[<p>What a waste of time. We write software to push product out door to support business. If we delay push through petty actions, we increase our business&#8217;s expenses.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tony</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-15497</link>
		<dc:creator>Tony</dc:creator>
		<pubDate>Fri, 22 Aug 2008 22:16:34 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-15497</guid>
		<description>Oh Dougal, that is simply brilliant! Then we could also have top-scores and ladders for reviewers who &quot;play&quot; the best... Until someone figures out how to build a bot based on the test-suite that&#039;s supposed to accompany the software anyway.</description>
		<content:encoded><![CDATA[<p>Oh Dougal, that is simply brilliant! Then we could also have top-scores and ladders for reviewers who &#8220;play&#8221; the best&#8230; Until someone figures out how to build a bot based on the test-suite that&#8217;s supposed to accompany the software anyway.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dougal Stanton</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-15493</link>
		<dc:creator>Dougal Stanton</dc:creator>
		<pubDate>Fri, 22 Aug 2008 21:29:18 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-15493</guid>
		<description>If you use a code review tool (like a web-based code review) then you could add the Jester bugs through that interface, so the tool knows the real code from the tainted code.
This way you can also get the code review tool to check the validity of the review. Reviewers can mark a line they don&#039;t like, like a game of minesweeper. If they submit and they haven&#039;t marked a tainted line then it rejects their review.
Damn that&#039;s evil... ;-)</description>
		<content:encoded><![CDATA[<p>If you use a code review tool (like a web-based code review) then you could add the Jester bugs through that interface, so the tool knows the real code from the tainted code.</p>
<p>This way you can also get the code review tool to check the validity of the review. Reviewers can mark a line they don&#8217;t like, like a game of minesweeper. If they submit and they haven&#8217;t marked a tainted line then it rejects their review.</p>
<p>Damn that&#8217;s evil&#8230; ;-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AlSweigart</title>
		<link>http://coffeeghost.net/2008/08/22/bugging-your-code-reviews/comment-page-1/#comment-15485</link>
		<dc:creator>AlSweigart</dc:creator>
		<pubDate>Fri, 22 Aug 2008 20:29:48 +0000</pubDate>
		<guid isPermaLink="false">http://coffeeghost.net/?p=79#comment-15485</guid>
		<description>Micah: I suppose &quot;design decisions&quot; was too high level of a description, I mostly meant justifying small implementation and algorithm details (but not so small where it becomes an argument of where the curly braces go).
I agree that design decisions should be made and approved before the actual coding starts.</description>
		<content:encoded><![CDATA[<p>Micah: I suppose &#8220;design decisions&#8221; was too high level of a description, I mostly meant justifying small implementation and algorithm details (but not so small where it becomes an argument of where the curly braces go).</p>
<p>I agree that design decisions should be made and approved before the actual coding starts.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

