<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://www.developerdotstar.com/community" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>developer.* Blogs - &amp;quot;Sneaking&amp;quot; Ruby into production? - Comments</title>
 <link>http://www.developerdotstar.com/community/node/570</link>
 <description>Comments for &quot;&quot;Sneaking&quot; Ruby into production?&quot;</description>
 <language>en</language>
<item>
 <title>Agreed on Sneaking</title>
 <link>http://www.developerdotstar.com/community/node/570#comment-1475</link>
 <description>&lt;p&gt;After reading your comments, Edward, I went back to check out that part of the &lt;a href=&quot;http://on-ruby.blogspot.com/2006/08/author-interviews-hal-fulton-ruby-way.html&quot;&gt;interview&lt;/a&gt; again. Here is the passage:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;I&#039;ve always used the trickle-up method. Start using it for one-off scripts. Then use it for little convenience scripts and tools. Then use it for glue code. Then start using it in testing. Then web development. Then less-important production code. Finally one day you are using Ruby in mission-critical apps in production, and your bosses may not even know. It&#039;s easier to get forgiveness than permission.&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;I&#039;m in favor of the trickle-up method, and I&#039;m not down on Ruby or Hal Fulton at all, but I must agree that Hal probably crosses a line in advocating a &quot;sneaky&quot; approach to introducing Ruby into one&#039;s work environment, especially as uses of the language get closer and closer to production usage.&lt;/p&gt;
&lt;p&gt;Edward, you wrote:&lt;/p&gt;
&lt;blockquote&gt;&lt;p&gt;&quot;Part of programming professionalism includes self-discipline and creating solutions with tools that the corporation knows about.&quot;&lt;/p&gt;&lt;/blockquote&gt;
&lt;p&gt;I&#039;ve worked in environments in which programmers were afforded a certain amount of freedom in solving problems in ways they saw fit, and management was smart enough to give them room to do so. I worked on a project where a programmer used YACC to shave a few weeks off of a large testing effort. Management was thrilled, and the programmer was rewarded. Because of the limited scope of the solution, and because the programmer was tacitly working in a situation where this kind of freelancing was OK, there was no discussion about whether the programmer had made an appropriate technology choice or taken too much initiative. But above a certain level in the system, no such freelancing was allowed, and everyone knew to respect that. I&#039;ve also worked in shops where not only tool choice, but also choice of design patterns and techniques, were critical maintanence factors, and the people in charge had to regulate programmer freedom in these areas closely. In either case, the professional programmers working in those shops worked within the limits--which is not to say that people did not try to push the limits a little, which sometimes led to innovation for the organization.&lt;/p&gt;
&lt;p&gt;Edward, you may not agree with my equivocation, but I think sometimes it *is* better (or at least easier) to ask forgiveness than to ask permission, especially when the stakes are the success and failure of a project with which you have been tasked, and especially when the nature of the environment is such that seeking permission would surely lead to failure. But there are definitely lines that when crossed give way to sneakiness and passive aggressive maneuvering.&lt;/p&gt;
&lt;p&gt;Dan&lt;/p&gt;
</description>
 <pubDate>Mon, 04 Sep 2006 08:01:27 -0700</pubDate>
 <dc:creator>Daniel Read</dc:creator>
 <guid isPermaLink="false">comment 1475 at http://www.developerdotstar.com/community</guid>
</item>
<item>
 <title>&quot;Sneaking&quot; Ruby into production?</title>
 <link>http://www.developerdotstar.com/community/node/570</link>
 <description>&lt;p&gt;I stopped reading Hal Fulton&#039;s interview when he said it was a good idea to &quot;sneak&quot; Ruby into production. Part of programming professionalism includes self-discipline and creating solutions with tools that the corporation knows about. Not, passive aggressive technical games. Passive aggression merely makes actual social change, and even corporate change, that much more difficult.&lt;/p&gt;
&lt;p&gt;&lt;a href=&quot;http://www.developerdotstar.com/community/node/570&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <comments>http://www.developerdotstar.com/community/node/570#comment</comments>
 <category domain="http://www.developerdotstar.com/community/taxonomy/term/20">Software Development</category>
 <category domain="http://www.developerdotstar.com/community/taxonomy/term/23">Ruby</category>
 <pubDate>Sun, 03 Sep 2006 20:34:25 -0700</pubDate>
 <dc:creator>Edward G Nilges</dc:creator>
 <guid isPermaLink="false">570 at http://www.developerdotstar.com/community</guid>
</item>
</channel>
</rss>
