<div dir="ltr">+1x10^gazillion, The next time the topic of TDD comes up, I'm just going to copy-paste this email. It's all I have to say on the topic and I don't disagree with a single word :)</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Apr 28, 2014 at 10:30 AM, Gabe da Silveira <span dir="ltr"><<a href="mailto:gabe@websaviour.com" target="_blank">gabe@websaviour.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="">On Sun, Apr 27, 2014 at 8:15 AM, Anthony Green <span dir="ltr"><<a href="mailto:anthony.charles.green@gmail.com" target="_blank">anthony.charles.green@gmail.com</a>></span> wrote:<br></div>
<div class="gmail_extra">
<div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
</div></div>These kind of missives have a tendency to devolve to flame bait. TDD goes through the same cyclical exchanges.<br>
And this continues despite the 'TDD - Thats not what we meant'  interventions.<br>
As I get older I have an increasing desire to move on and focus on exchanges that help me improve on the disciplines I've chosen to believe will help me produce better software.<br></blockquote><div><br></div></div><div>
To be fair, flame bait is one of DHH's prime MOs. His goal isn't nuanced discourse, as evidenced by his conflation of computer science with serious software engineering in the keynote.  That said, I appreciate his challenge of TDD and architecture astronautism simply as a counterpoint to prevailing ideologies which, in the absence of push back, have a tendency to be cargo culted mercilessly.  </div>

<div><br></div><div>On the one hand, I think DHH's critiques of techniques for separating persistence and business model concerns are pretty weak since his entire career is based on controlling his own domain and keeping it dead simple.  It's easy for him to shoot down the need for any more complex architecture because any small example for the sake of discussion is necessarily reduced below the scope where such structure is necessary.  But on the other hand, I couldn't agree more that TDD/BDD do not lead to better designs—they lead to better tests, and good tests are just one metric of a good codebase.  Ruby, of course, requires good tests to have any reliability over time whatsoever, but we shouldn't forget that tests are still ancillary.  Being testable is only a small fraction of what makes a given architecture good.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-gabe</div></font></span></div></div></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>