<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Rails, Twitter and the 800lb Gorilla in the Room&#8230;</title>
	<atom:link href="http://warrenseen.com/blog/2007/04/16/rails-twitter-and-the-800lb-gorilla-in-the-room/feed/" rel="self" type="application/rss+xml" />
	<link>http://warrenseen.com/blog/2007/04/16/rails-twitter-and-the-800lb-gorilla-in-the-room/</link>
	<description>freelance software developer</description>
	<pubDate>Sat, 06 Sep 2008 05:36:32 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Bruce Clemson</title>
		<link>http://warrenseen.com/blog/2007/04/16/rails-twitter-and-the-800lb-gorilla-in-the-room/#comment-1537</link>
		<dc:creator>Bruce Clemson</dc:creator>
		<pubDate>Fri, 20 Apr 2007 14:32:07 +0000</pubDate>
		<guid isPermaLink="false">http://warrenseen.com/blog/2007/04/16/rails-twitter-and-the-800lb-gorilla-in-the-room/#comment-1537</guid>
		<description>I think you're confusing some points.    Being in that 1% doesn't mean you're "successful"  it means you're popular or maybe you just have heavy load in your particular problem domain  (I work on a portal that enterprises use,  it's not uncommon for us to get a few thousand SSL logins over a fairly short period of time (10 to 15 minutes)  and it's not always an easy problem to have with a single box software product that usually runs on off the shelf hardware or some old box they had lying around,  if we don't solve it, they don't pay.)  If you're in that 1% you're also probably in a sitation where your success is dependant upon solving that problem also,  if you  don't you will most likely not be "successful."


As for the other 99% that's true,  scale is usually never an issue but if there is any single truth about software and its production,  it's that applications almost  always outlive the expected life at the start and it's never a good time to rewrite something.    The way it works for those 99% (and probably a lot of the applications in the 1%) is that they work fine, they do a job, the author moves on to other problems and maybe entirely different applications and then once people start relying upon the program and really start using it, the scale problems show up.   Almost universally, fixing the scale problems will be a larger effort than the initial construction and that's time not adding new features and if you've got customers it might be time that you simply do not have to really think through all of the problems, they want a solution and they want if fast.  

At the end of it, it's just risk.   Will you have that problem?  Most likely not, but having it doesn't always equate to being a "good thing."

If twitter starts going down once every 15 minutes and you routinely start seeing error pages, how long do you think they have to fix that before something else takes their community away?   Seriously?</description>
		<content:encoded><![CDATA[<p>I think you&#8217;re confusing some points.    Being in that 1% doesn&#8217;t mean you&#8217;re &#8220;successful&#8221;  it means you&#8217;re popular or maybe you just have heavy load in your particular problem domain  (I work on a portal that enterprises use,  it&#8217;s not uncommon for us to get a few thousand SSL logins over a fairly short period of time (10 to 15 minutes)  and it&#8217;s not always an easy problem to have with a single box software product that usually runs on off the shelf hardware or some old box they had lying around,  if we don&#8217;t solve it, they don&#8217;t pay.)  If you&#8217;re in that 1% you&#8217;re also probably in a sitation where your success is dependant upon solving that problem also,  if you  don&#8217;t you will most likely not be &#8220;successful.&#8221;</p>
<p>As for the other 99% that&#8217;s true,  scale is usually never an issue but if there is any single truth about software and its production,  it&#8217;s that applications almost  always outlive the expected life at the start and it&#8217;s never a good time to rewrite something.    The way it works for those 99% (and probably a lot of the applications in the 1%) is that they work fine, they do a job, the author moves on to other problems and maybe entirely different applications and then once people start relying upon the program and really start using it, the scale problems show up.   Almost universally, fixing the scale problems will be a larger effort than the initial construction and that&#8217;s time not adding new features and if you&#8217;ve got customers it might be time that you simply do not have to really think through all of the problems, they want a solution and they want if fast.  </p>
<p>At the end of it, it&#8217;s just risk.   Will you have that problem?  Most likely not, but having it doesn&#8217;t always equate to being a &#8220;good thing.&#8221;</p>
<p>If twitter starts going down once every 15 minutes and you routinely start seeing error pages, how long do you think they have to fix that before something else takes their community away?   Seriously?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: RubyPanther</title>
		<link>http://warrenseen.com/blog/2007/04/16/rails-twitter-and-the-800lb-gorilla-in-the-room/#comment-1526</link>
		<dc:creator>RubyPanther</dc:creator>
		<pubDate>Thu, 19 Apr 2007 18:15:27 +0000</pubDate>
		<guid isPermaLink="false">http://warrenseen.com/blog/2007/04/16/rails-twitter-and-the-800lb-gorilla-in-the-room/#comment-1526</guid>
		<description>The metaphor you're using is supposed to be "elephant in the room," an "800lb gorilla" is a totally different meaning.</description>
		<content:encoded><![CDATA[<p>The metaphor you&#8217;re using is supposed to be &#8220;elephant in the room,&#8221; an &#8220;800lb gorilla&#8221; is a totally different meaning.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
