<?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: How do you convince your boss to TDD</title>
	<atom:link href="http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/feed/" rel="self" type="application/rss+xml" />
	<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/</link>
	<description>Testability Explorer</description>
	<lastBuildDate>Fri, 30 Jul 2010 03:59:03 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: mike</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1245</link>
		<dc:creator>mike</dc:creator>
		<pubDate>Thu, 18 Jun 2009 03:43:11 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1245</guid>
		<description>In &quot;Rapid Development&quot; by Steve McConnell, he write the following, siting some usefull statistics:

&quot;Unit testing can find anywhere from 10 to 50 percent of the defects in a program. System testing can find from 20 to 60 percent of a programs defects. Together, their cumulative defect-detection rate is often less than 60 percent (Jones 1986a).&quot;

He sites &quot;Programming Productivity&quot; by Capers Jones published in 1986. It seems that the effect of TDD should be clearly understood, and predictable by now if we look to the studies.</description>
		<content:encoded><![CDATA[<p>In &#8220;Rapid Development&#8221; by Steve McConnell, he write the following, siting some usefull statistics:</p>
<p>&#8220;Unit testing can find anywhere from 10 to 50 percent of the defects in a program. System testing can find from 20 to 60 percent of a programs defects. Together, their cumulative defect-detection rate is often less than 60 percent (Jones 1986a).&#8221;</p>
<p>He sites &#8220;Programming Productivity&#8221; by Capers Jones published in 1986. It seems that the effect of TDD should be clearly understood, and predictable by now if we look to the studies.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dennis Gorelik</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1217</link>
		<dc:creator>Dennis Gorelik</dc:creator>
		<pubDate>Sun, 14 Jun 2009 01:37:24 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1217</guid>
		<description>Misko, you wrote: &quot;If you can’t write a test, you don’t have reusable code.&quot;.I don&#039;t agree with that.A method that reads from database is quite reusable, but may be not very testable (because of database dependency).Overall TDD make sense only for certain areas of the project. Quite often it&#039;s more efficient not to even cover certain areas of code with auto-tests at all (especially if it&#039;s UI).</description>
		<content:encoded><![CDATA[<p>Misko, you wrote: &#8220;If you can’t write a test, you don’t have reusable code.&#8221;.I don&#8217;t agree with that.A method that reads from database is quite reusable, but may be not very testable (because of database dependency).Overall TDD make sense only for certain areas of the project. Quite often it&#8217;s more efficient not to even cover certain areas of code with auto-tests at all (especially if it&#8217;s UI).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Igor</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1086</link>
		<dc:creator>Igor</dc:creator>
		<pubDate>Thu, 21 May 2009 08:50:33 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1086</guid>
		<description>@GermanDon&#039;t you think you may have other problems than lack of management support if what you described happens ?I don&#039;t think management can seriously influence quality culture in the team. It&#039;s the team itself, who needs to understand the importance and benefits of the practice(s). &#160;Unless it happens no management support can help.</description>
		<content:encoded><![CDATA[<p>@GermanDon&#8217;t you think you may have other problems than lack of management support if what you described happens ?I don&#8217;t think management can seriously influence quality culture in the team. It&#8217;s the team itself, who needs to understand the importance and benefits of the practice(s). &nbsp;Unless it happens no management support can help.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kaleb Pederson</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1085</link>
		<dc:creator>Kaleb Pederson</dc:creator>
		<pubDate>Wed, 20 May 2009 19:31:29 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1085</guid>
		<description>If you know TDD, then I would ask one simple question:&quot;I&#039;ve been doing TDD for XXX years now at prior jobs.&#160; I know that 90% of the time I can write automated tests faster than I can manually test the application. Will you permit me to use TDD or would you like me to take use the slower testing methodology?&quot;If you have a strong reputation, they will likely stop and think.</description>
		<content:encoded><![CDATA[<p>If you know TDD, then I would ask one simple question:&#8221;I&#8217;ve been doing TDD for XXX years now at prior jobs.&nbsp; I know that 90% of the time I can write automated tests faster than I can manually test the application. Will you permit me to use TDD or would you like me to take use the slower testing methodology?&#8221;If you have a strong reputation, they will likely stop and think.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Germán</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1077</link>
		<dc:creator>Germán</dc:creator>
		<pubDate>Tue, 19 May 2009 19:08:12 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1077</guid>
		<description>Igor: sometimes you need explicit management support. What if you&#039;re part of a team working on a project? How good would it be that you&#039;re the only one doing TDD, when other people are checking in changes that break your tests? If I&#039;m the only coder in the project, I agree, I can simply do it. But in a team, everyone should be involved...</description>
		<content:encoded><![CDATA[<p>Igor: sometimes you need explicit management support. What if you&#8217;re part of a team working on a project? How good would it be that you&#8217;re the only one doing TDD, when other people are checking in changes that break your tests? If I&#8217;m the only coder in the project, I agree, I can simply do it. But in a team, everyone should be involved&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Igor</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1074</link>
		<dc:creator>Igor</dc:creator>
		<pubDate>Tue, 19 May 2009 12:53:00 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1074</guid>
		<description>&#160;I wonder if anyone&#160;goes and asks for approval to use a debuger.It looks to me that the real reason &#160;behind asking for a permission to practice TDD is to look for managers support. Either to bring some training/coaching or to understand people may be a little bit slow at the beginning.Whenever you think you have enough skill - don&#039;t wait for permission. Go for it.&#160;</description>
		<content:encoded><![CDATA[<p>&nbsp;I wonder if anyone&nbsp;goes and asks for approval to use a debuger.It looks to me that the real reason &nbsp;behind asking for a permission to practice TDD is to look for managers support. Either to bring some training/coaching or to understand people may be a little bit slow at the beginning.Whenever you think you have enough skill &#8211; don&#8217;t wait for permission. Go for it.&nbsp;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1061</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Mon, 18 May 2009 23:05:32 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1061</guid>
		<description>I work in a test origanisation that tried out TDD. We were lucky to have a management team that encouraged new ideas and ways of working. Some of our test/design teams were struggling with incremental development so it was quite an easy option to try out TDD in one team - as a pilot. The team went through a development and delivery cycle and then documented their experiences. So now we have TDD as one of our best practices - it&#039;s still up to the teams to decide whether to use it in a given development phase - everything is on a case-by-case basis.So, to answer the readers question: I think you have to try and quote some case studies, being sure that TDD is the right fit for you - to solve the problem in hand. Remember, not all test approaches/methodologies work for all situations all of the time.</description>
		<content:encoded><![CDATA[<p>I work in a test origanisation that tried out TDD. We were lucky to have a management team that encouraged new ideas and ways of working. Some of our test/design teams were struggling with incremental development so it was quite an easy option to try out TDD in one team &#8211; as a pilot. The team went through a development and delivery cycle and then documented their experiences. So now we have TDD as one of our best practices &#8211; it&#8217;s still up to the teams to decide whether to use it in a given development phase &#8211; everything is on a case-by-case basis.So, to answer the readers question: I think you have to try and quote some case studies, being sure that TDD is the right fit for you &#8211; to solve the problem in hand. Remember, not all test approaches/methodologies work for all situations all of the time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: PHB</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1060</link>
		<dc:creator>PHB</dc:creator>
		<pubDate>Mon, 18 May 2009 17:06:36 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1060</guid>
		<description>This post is really helpful.&#160; Thanks.&#160; I manage a small team and want to convince my developers that a TDD and dependency injection approach is the way to go.&#160; I don&#039;t want to enforce a policy but my attempts at debate and education are not making headway.&#160; How would you approach this problem?</description>
		<content:encoded><![CDATA[<p>This post is really helpful.&nbsp; Thanks.&nbsp; I manage a small team and want to convince my developers that a TDD and dependency injection approach is the way to go.&nbsp; I don&#8217;t want to enforce a policy but my attempts at debate and education are not making headway.&nbsp; How would you approach this problem?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: chris</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1056</link>
		<dc:creator>chris</dc:creator>
		<pubDate>Mon, 18 May 2009 09:51:37 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1056</guid>
		<description>This is based on my experience :&#160;* firstly, yo need to convince your boss that tests are good&#160;* secondly, you need to convinve your boss that automatic tests are goodIn order to achieve this, the 1st thing you need is a failed project (i.e when you do a small code change somewhere, it breaks somewhere else).Then, you can say : &quot;if we had tests, ...&quot; =&gt; 1st pointThe 2nd point is harder because you need time to write tests (i.e 33% is good estimate IMHO).You need to convince your boss to give it a try (/!\ do it on something new, writing tests above not tested code is recipe for failure)In my experience, doing something &quot;in the back&quot; of your manager (like writing tests) is a bad thing...Writing tests takes time, so it needs to be accounted in the budget.</description>
		<content:encoded><![CDATA[<p>This is based on my experience :&nbsp;* firstly, yo need to convince your boss that tests are good&nbsp;* secondly, you need to convinve your boss that automatic tests are goodIn order to achieve this, the 1st thing you need is a failed project (i.e when you do a small code change somewhere, it breaks somewhere else).Then, you can say : &#8220;if we had tests, &#8230;&#8221; =&gt; 1st pointThe 2nd point is harder because you need time to write tests (i.e 33% is good estimate IMHO).You need to convince your boss to give it a try (/!\ do it on something new, writing tests above not tested code is recipe for failure)In my experience, doing something &#8220;in the back&#8221; of your manager (like writing tests) is a bad thing&#8230;Writing tests takes time, so it needs to be accounted in the budget.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Truls</title>
		<link>http://misko.hevery.com/2009/05/16/how-do-you-convince-your-boss-to-tdd/comment-page-1/#comment-1050</link>
		<dc:creator>Truls</dc:creator>
		<pubDate>Sun, 17 May 2009 13:56:20 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=481#comment-1050</guid>
		<description>Like you said, bosses shouldn&#039;t have to do micromanagement, and we shouldn&#039;t put them in a position where they have to. I think in many situations you can just start doing TDD without anyone&#039;s approval as long as you churn out good code that works for the project.It&#039;s usually more of an issue to also convince your co-developers to do the same thing, so that you all run the tests and add new useful tests while developing.</description>
		<content:encoded><![CDATA[<p>Like you said, bosses shouldn&#8217;t have to do micromanagement, and we shouldn&#8217;t put them in a position where they have to. I think in many situations you can just start doing TDD without anyone&#8217;s approval as long as you churn out good code that works for the project.It&#8217;s usually more of an issue to also convince your co-developers to do the same thing, so that you all run the tests and add new useful tests while developing.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
