On Wed, Mar 21, 2012 at 10:28 AM, Chris Parsons <span dir="ltr"><<a href="mailto:chris.p@rsons.org">chris.p@rsons.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>That would be a fun dojo to run, actually... give teams of 2-3 people a spec to work to, and an hour to do it.</div><div>Half the teams have to write tests. The other half are not allow to write any tests.</div>
<div>At the end, compare the production code, talk about the experience, and see who managed to complete the spec...</div></div></blockquote><div><br></div><div>I suspect that might put the TDD team at a disadvantage since the nature of TDD means it takes longer at the outset.  It's likely obvious to most of you, but seems the value of TDD is much greater when you go back and revisit/refactor your code or need to add something to it—you have the test scaffolding in place to make sure you don't break things. I also think it encourages good design for the usual reasons, but also for the simple effect of increasing the amount of thought time that goes into a given design.</div>
<div><br></div><div>It *would* be an interesting discussion, especially if the results turned out to counter-intuitive.</div><div><br></div></div>-- <br><br>Damon Allen Davison<br>Music industry technology, photographer and filmmaker, master of philology, gourmand, gannet.<br>
<a href="http://allolex.net" target="_blank">http://allolex.net</a> – Twitter @allolex<br>