Robby on Rails: Dialogue-Driven Development is about rounded cornersthoughts.sort_by{|t| t[:topic]}.collect tag:www.robbyonrails.com,2005:TypoTypo2006-09-05T22:12:44-04:00Robby Russellurn:uuid:94cb33a8-bd84-4bad-9a20-7b6e2f9cd5722006-08-05T10:49:00-04:002006-09-05T22:12:44-04:00Dialogue-Driven Development is about rounded corners<p>In response to our <a href="http://www.robbyonrails.com/articles/2006/08/02/dialogue-driven-development">introduction of Dialogue-Driven Development</a>, mechanismalley.com writes, <em>”...it seems to be the Rails community’s pattern to take an existing concept — or misconception — put rounded corners on it and deem it something new.”</em> (<a href="http://mechanismalley.com/blog/2006/08/04/on-product-backlogs/">link</a>)</p>
<p>I’m not sure that I can completely agree with this generalization. What I’ve witnessed as a member of the Rails community, is an attempt to <em>simplify</em> code, solutions, processes, and as a result… conversation between developers and clients has become much richer and coherent. Take this with a grain of salt as this has only been my experience. <strong>Complex solutions are complex to explain</strong> and often too complex to know if they are actually solving <em>the right goal.</em> On the other hand, <strong>simple solutions make way for better dialogue</strong>. With <a href="http://www.rubyonrails.org">Ruby on Rails</a>, we are provided with a foundation that <em>encourages</em> and <em>embraces</em> best practices and simple solutions (rounded corners?), which makes it easier to discuss with the client. This is what fascinates me about Ruby on Rails… and what Martin Fowler in <a href="http://blog.scribestudio.com/articles/2006/07/03/martin-fowler-railsconf-2006-keynote-address">his keynote</a> at <a href="http://www.railsconf.org">RailsConf</a>.</p>
<p>Perhaps it makes sense that what Brian and I are outlining with our approach to defining patterns for client<->development team interaction evolved through us working with Ruby on Rails. However, there is nothing that requires Rails in order to follow the patterns that we’re discussing. In Brian’s <a href="http://blog.brightredglow.com/articles/2006/08/04/its-all-about-the-dialogue">first article about d3</a>, he referenced the following…</p>
<blockquote><em>“What we are seeing is a drive toward simplicity. Conventional wisdom once was “quick necessarily means dirty”. Ruby challenges that.</em>
<br />
—<a href="http://www.martinfowler.com/">Martin Fowler</a>
</blockquote>
<p>At the very core of our approach with Dialogue-Driven Development is the <a href="http://www.agilemanifesto.org/">Agile Manifesto</a>. The author of this post is correct, we’re taking an existing concept and putting rounded corners on it. We’re trying to <strong>make it simpler</strong>. We find that Scrum is too process heavy and while we can see it being a good step away from the <a href="http://www.waterfall2006.com/">Waterfall</a> approach, it’s still not giving us that warm and fuzzy feeling. Rails developers know what that warm and fuzzy feeling is… and we are hoping to find something that gives our clients and us the same feeling when we’re not coding. We want lightweight methodologies to complement our lightweight frameworks and patterns.</p>
<blockquote>
We are uncovering better ways of developing<br />
software by doing it and helping others do it. <br />
Through this work we have come to value:<br />
<br />
Individuals and interactions over processes and tools <br />
Working software over comprehensive documentation <br />
Customer collaboration over contract negotiation <br />
Responding to change over following a plan <br />
<br />
That is, while there is value in the items on <br />
the right, we value the items on the left more.<br />
<br />
—<a href="http://www.agilemanifesto.org/">The Agile Manifesto</a>
</blockquote>
<p>It’s time to start rethinking how we work <em>with</em> clients. Too often we end up working <em>for</em> them and while we might build them what they want… we might not be giving them what they need.</p>
<p>So, I must ask… has working with Ruby on Rails reshaped the way you think about client and developer conversation? If so, for the better or worse?</p>
<p>High traces of collaboration and dialogue are usually found in the recipe of any successful project.</p>
<h3>Related Articles</h3>
<ul>
<li><a href="http://blog.brightredglow.com/articles/2006/08/06/one-cuckoo-flew-over-the-nest">One cuckoo flew over the nest</a>, Brian Ford</li>
<li><a href="http://www.robbyonrails.com/articles/2006/08/02/dialogue-driven-development">Dialogue-Driven Development</a></li>
<li><a href="http://iamrice.org/articles/2006/08/03/dialog-driven-development-is-the-real-agile">Dialog driven development is the real agile</a>, Damien Tanner</li>
<li><a href="http://spellcoder.com/blogs/dodyg/archive/2006/08/03/254.aspx">Dialog driven development</a>, Lazy Coder</li>
<li><a href="http://blog.brightredglow.com/articles/2006/08/04/its-all-about-the-dialogue">It’s all about the dialogue</a>, Brian Ford</li>
</ul><p>In response to our <a href="http://www.robbyonrails.com/articles/2006/08/02/dialogue-driven-development">introduction of Dialogue-Driven Development</a>, mechanismalley.com writes, <em>”...it seems to be the Rails community’s pattern to take an existing concept — or misconception — put rounded corners on it and deem it something new.”</em> (<a href="http://mechanismalley.com/blog/2006/08/04/on-product-backlogs/">link</a>)</p>
<p>I’m not sure that I can completely agree with this generalization. What I’ve witnessed as a member of the Rails community, is an attempt to <em>simplify</em> code, solutions, processes, and as a result… conversation between developers and clients has become much richer and coherent. Take this with a grain of salt as this has only been my experience. <strong>Complex solutions are complex to explain</strong> and often too complex to know if they are actually solving <em>the right goal.</em> On the other hand, <strong>simple solutions make way for better dialogue</strong>. With <a href="http://www.rubyonrails.org">Ruby on Rails</a>, we are provided with a foundation that <em>encourages</em> and <em>embraces</em> best practices and simple solutions (rounded corners?), which makes it easier to discuss with the client. This is what fascinates me about Ruby on Rails… and what Martin Fowler in <a href="http://blog.scribestudio.com/articles/2006/07/03/martin-fowler-railsconf-2006-keynote-address">his keynote</a> at <a href="http://www.railsconf.org">RailsConf</a>.</p>
<p>Perhaps it makes sense that what Brian and I are outlining with our approach to defining patterns for client<->development team interaction evolved through us working with Ruby on Rails. However, there is nothing that requires Rails in order to follow the patterns that we’re discussing. In Brian’s <a href="http://blog.brightredglow.com/articles/2006/08/04/its-all-about-the-dialogue">first article about d3</a>, he referenced the following…</p>
<blockquote><em>“What we are seeing is a drive toward simplicity. Conventional wisdom once was “quick necessarily means dirty”. Ruby challenges that.</em>
<br />
—<a href="http://www.martinfowler.com/">Martin Fowler</a>
</blockquote>
<p>At the very core of our approach with Dialogue-Driven Development is the <a href="http://www.agilemanifesto.org/">Agile Manifesto</a>. The author of this post is correct, we’re taking an existing concept and putting rounded corners on it. We’re trying to <strong>make it simpler</strong>. We find that Scrum is too process heavy and while we can see it being a good step away from the <a href="http://www.waterfall2006.com/">Waterfall</a> approach, it’s still not giving us that warm and fuzzy feeling. Rails developers know what that warm and fuzzy feeling is… and we are hoping to find something that gives our clients and us the same feeling when we’re not coding. We want lightweight methodologies to complement our lightweight frameworks and patterns.</p>
<blockquote>
We are uncovering better ways of developing<br />
software by doing it and helping others do it. <br />
Through this work we have come to value:<br />
<br />
Individuals and interactions over processes and tools <br />
Working software over comprehensive documentation <br />
Customer collaboration over contract negotiation <br />
Responding to change over following a plan <br />
<br />
That is, while there is value in the items on <br />
the right, we value the items on the left more.<br />
<br />
—<a href="http://www.agilemanifesto.org/">The Agile Manifesto</a>
</blockquote>
<p>It’s time to start rethinking how we work <em>with</em> clients. Too often we end up working <em>for</em> them and while we might build them what they want… we might not be giving them what they need.</p>
<p>So, I must ask… has working with Ruby on Rails reshaped the way you think about client and developer conversation? If so, for the better or worse?</p>
<p>High traces of collaboration and dialogue are usually found in the recipe of any successful project.</p>
<h3>Related Articles</h3>
<ul>
<li><a href="http://blog.brightredglow.com/articles/2006/08/06/one-cuckoo-flew-over-the-nest">One cuckoo flew over the nest</a>, Brian Ford</li>
<li><a href="http://www.robbyonrails.com/articles/2006/08/02/dialogue-driven-development">Dialogue-Driven Development</a></li>
<li><a href="http://iamrice.org/articles/2006/08/03/dialog-driven-development-is-the-real-agile">Dialog driven development is the real agile</a>, Damien Tanner</li>
<li><a href="http://spellcoder.com/blogs/dodyg/archive/2006/08/03/254.aspx">Dialog driven development</a>, Lazy Coder</li>
<li><a href="http://blog.brightredglow.com/articles/2006/08/04/its-all-about-the-dialogue">It’s all about the dialogue</a>, Brian Ford</li>
</ul>
Jamesurn:uuid:f7a962fc-88dd-4cfd-8e86-068352fe46202006-08-07T17:01:31-04:002006-09-05T22:12:53-04:00Comment on Dialogue-Driven Development is about rounded corners by James<p>Working with clients is called Enterprise Architecture, working for clients is called staff augmentation…</p>
<p>duckdown.blogspot.com</p>Peter Armstrongurn:uuid:0c8ab479-7e98-4074-aa30-5fd57f7106d92006-08-05T22:39:43-04:002006-09-05T22:12:50-04:00Comment on Dialogue-Driven Development is about rounded corners by Peter Armstrong<p>Heh, when I read this I thought “But you forgot gradient fills, the other essential part of Web 2.0!”. Argh, I need to get out more…</p>Robby Russellurn:uuid:ae0e4b88-98dd-407b-aca8-fa8258d16ba82006-08-05T19:39:15-04:002006-09-05T22:12:51-04:00Comment on Dialogue-Driven Development is about rounded corners by Robby Russell<p>Bryan,</p>
<p>I intend to go into more detail about the Product backlog in another blog post in the next few days. His blog post was good but I just wanted to discuss this point first as I don’t think he is wrong about the rounded corners. ;-)</p>bryanlurn:uuid:ce035575-f134-4f2a-8662-240a6e15a80e2006-08-05T18:02:49-04:002006-09-05T22:12:52-04:00Comment on Dialogue-Driven Development is about rounded corners by bryanl<p>Sensationlism makes folks read blogs. The quote you pointed out was one of the questionable quotes in the article. I think mechanismalley.com raises a valid point, and they do bring their point home:</p>
<blockquote>While programming is, in the end, applied mathematics, application development and operations are applied narratology. <strong><em>The “dialogue driven development” idea is an interesting one</em></strong>, I think, but <em>I’d hate to see them toss out a useful too</em>l like the backlog based on its misapplication.</blockquote>
<p>I think the bow shot at Ruby On Rails jaded your opinion of the rest the article.</p>Howardurn:uuid:e12e25f1-403f-4a69-a468-f2796042ea862006-08-05T17:38:04-04:002006-09-05T22:12:51-04:00Comment on Dialogue-Driven Development is about rounded corners by Howard<p>What makes you think that Scrum isn’t simple? ;-)</p>