<story><title>When TDD Doesn&apos;t Work</title><url>http://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html</url></story><parent_chain><item><author>Nursie</author><text>IMHO TDD, like a lot of the agile stuff, is a good idea with solid foundations that people get wrong all the time and end up making things worse with.&lt;p&gt;Agile was supposed to ease up on process and make teams adapt to changing requirements. It wasn&amp;#x27;t supposed to use up &amp;gt;30% of your working time just to service the methodology, but that&amp;#x27;s what it ends up doing when you get in the Agile Evangelists.&lt;p&gt;TDD was supposed to ensure more correct software at the cost of some overhead (perhaps 30%?) by making sure every unit had its tests written ahead of the code. In practice I&amp;#x27;ve seen it kill productivity entirely as people write test harnesses, dummy systems and frameworks galore, and never produce anything.&lt;p&gt;A combination of these two approaches recently cost an entire team (30+) people their jobs as they produced almost nothing for almost a year, despite being busy and ostensibly working hard all year. We kept one guy to deal with some of the stuff they left behind and do some new development. When asked for an estimate to do a trivial change he gave a massive timescale and then explained that &amp;#x27;in the gateway team we like to write extensive tests before the code&amp;#x27;.&lt;p&gt;The only response we had for him was &amp;#x27;and do you see the rest of the gateway team here now?&amp;#x27;</text></item></parent_chain><comment><author>forgottenpass</author><text>&lt;i&gt;IMHO TDD, like a lot of the agile stuff, is a good idea with solid foundations that people get wrong all the time and end up making things worse with.&lt;/i&gt;&lt;p&gt;I think the reason it can go sideways is because the advocates and casual adherents don&amp;#x27;t accept that for some teams a methodology really may not provide the claimed benefits, or it costs too much elsewhere.  It&amp;#x27;s easier to say &amp;quot;It&amp;#x27;s not [methodology] that isn&amp;#x27;t working, you&amp;#x27;re doing it wrong.&amp;quot;&lt;p&gt;That&amp;#x27;s a really attractive answer, made all the more tempting because it&amp;#x27;s sometimes true.  But not every software team is the same, operating in the same constraints.  People tend to generalize based on their own experiences.  Lessons learned about what works for X doesn&amp;#x27;t necessarily apply to Y.  The thing that has been lacking in the TDD&amp;#x2F;Agile&amp;#x2F;Insert Fad is a higher level &amp;quot;this is why the ideas worked for us, here are the component pieces and their purpose, this is how to determine the pieces to adopt and how to  tailor them to your organization.&amp;quot;&lt;p&gt;You could say that someone out there is making that case, but their voice is drowning under the snakeoil salesmen.  I don&amp;#x27;t hear it up front, the rare times I do hear it is deep into the &amp;quot;you&amp;#x27;re doing it wrong&amp;quot; conversation when any sense of perspective in the discussion has already been beaten to death.</text></comment>
<story><title>When TDD Doesn&apos;t Work</title><url>http://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html</url></story><parent_chain><item><author>Nursie</author><text>IMHO TDD, like a lot of the agile stuff, is a good idea with solid foundations that people get wrong all the time and end up making things worse with.&lt;p&gt;Agile was supposed to ease up on process and make teams adapt to changing requirements. It wasn&amp;#x27;t supposed to use up &amp;gt;30% of your working time just to service the methodology, but that&amp;#x27;s what it ends up doing when you get in the Agile Evangelists.&lt;p&gt;TDD was supposed to ensure more correct software at the cost of some overhead (perhaps 30%?) by making sure every unit had its tests written ahead of the code. In practice I&amp;#x27;ve seen it kill productivity entirely as people write test harnesses, dummy systems and frameworks galore, and never produce anything.&lt;p&gt;A combination of these two approaches recently cost an entire team (30+) people their jobs as they produced almost nothing for almost a year, despite being busy and ostensibly working hard all year. We kept one guy to deal with some of the stuff they left behind and do some new development. When asked for an estimate to do a trivial change he gave a massive timescale and then explained that &amp;#x27;in the gateway team we like to write extensive tests before the code&amp;#x27;.&lt;p&gt;The only response we had for him was &amp;#x27;and do you see the rest of the gateway team here now?&amp;#x27;</text></item></parent_chain><comment><author>TelmoMenezes</author><text>&amp;gt; IMHO TDD, like a lot of the agile stuff, is a good idea with solid foundations that people get wrong all the time and end up making things worse with.&lt;p&gt;So one could reasonably suspect that people who &amp;quot;get agile&amp;quot; are just talented and would be good developers anyway. Occam&amp;#x27;s razor invites us to assume that agile has no effect. Are there any scientific studies on the effectiveness of agile (or TDD), or is this just a homeopathy situation?</text></comment>