<?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: Scale of Process</title>
	<atom:link href="http://web-graphics.com/2007/08/07/scale-of-process/feed/" rel="self" type="application/rss+xml" />
	<link>http://web-graphics.com/2007/08/07/scale-of-process/</link>
	<description>Web development concerns, usually revolving around implimentation of designs into graphics, CSS, and HTML.</description>
	<pubDate>Thu, 24 Jul 2008 06:49:16 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Shawn Oster</title>
		<link>http://web-graphics.com/2007/08/07/scale-of-process/#comment-17467</link>
		<dc:creator>Shawn Oster</dc:creator>
		<pubDate>Tue, 14 Aug 2007 06:54:22 +0000</pubDate>
		<guid isPermaLink="false">http://web-graphics.com/2007/08/07/scale-of-process/#comment-17467</guid>
		<description>Personally what I've found hardest when working on a 200 person team isn't really the tools, there are some good ones out there, it's getting the team to switch to them and use them.  A small team is much more open to trying something new than a large one.

One combination that I find works well for all sizes of teams is Basecamp + Highrise + Subversion + Trac.  It scales well and is very human-friendly.  For small projects I may just put a single milestone in Basecamp, "Finish Project" while for a larger one I'll have that broken out into many milestones, tasklists and I'll also make it the primary place to find specs, notes, latest revs, etc.  Of course this only works if everyone else uses it.

Another way I've scaled projects is to change the workflow.  As an example I was working with a client that was using Dreamweaver's built in publishing features and that was a *mess*.  People would step all over each other and it just became unwieldly.  I changed the workflow and instead of a direct FTP people had to commit their changes first to source control, which in turn would automatically push their changes to the server.  This was a simple change but helped prevent stomping on each other.

I'm curious what applications got your juices flowing on this, which ones don't think about scale or how you're approaching a project?  "Development tools" is a pretty broad subject and I'm sure my toolset is different than yours since I'm on the programmer side of the fence.  For me what scales the best are using seperate tools that each do their job well, gluing it all together with workflow and supporting tools.

Really the best way to combat scalability issues is knowing a lot of little, easy to use tools vs. trying to find the one master program that can shape-shift.</description>
		<content:encoded><![CDATA[<p>Personally what I&#8217;ve found hardest when working on a 200 person team isn&#8217;t really the tools, there are some good ones out there, it&#8217;s getting the team to switch to them and use them.  A small team is much more open to trying something new than a large one.</p>
<p>One combination that I find works well for all sizes of teams is Basecamp + Highrise + Subversion + Trac.  It scales well and is very human-friendly.  For small projects I may just put a single milestone in Basecamp, &#8220;Finish Project&#8221; while for a larger one I&#8217;ll have that broken out into many milestones, tasklists and I&#8217;ll also make it the primary place to find specs, notes, latest revs, etc.  Of course this only works if everyone else uses it.</p>
<p>Another way I&#8217;ve scaled projects is to change the workflow.  As an example I was working with a client that was using Dreamweaver&#8217;s built in publishing features and that was a *mess*.  People would step all over each other and it just became unwieldly.  I changed the workflow and instead of a direct FTP people had to commit their changes first to source control, which in turn would automatically push their changes to the server.  This was a simple change but helped prevent stomping on each other.</p>
<p>I&#8217;m curious what applications got your juices flowing on this, which ones don&#8217;t think about scale or how you&#8217;re approaching a project?  &#8220;Development tools&#8221; is a pretty broad subject and I&#8217;m sure my toolset is different than yours since I&#8217;m on the programmer side of the fence.  For me what scales the best are using seperate tools that each do their job well, gluing it all together with workflow and supporting tools.</p>
<p>Really the best way to combat scalability issues is knowing a lot of little, easy to use tools vs. trying to find the one master program that can shape-shift.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jared Christensen</title>
		<link>http://web-graphics.com/2007/08/07/scale-of-process/#comment-17201</link>
		<dc:creator>Jared Christensen</dc:creator>
		<pubDate>Tue, 07 Aug 2007 18:58:39 +0000</pubDate>
		<guid isPermaLink="false">http://web-graphics.com/2007/08/07/scale-of-process/#comment-17201</guid>
		<description>Great post, I totally see it now that you point it out. Dreamweaver is very scalable compared to say Coda. Both great apps but coda payed way more attention to interface design. I still have not picked witch one I like better. Coda is fun to use but Dreameaver is fast(just because I'm use to using it).</description>
		<content:encoded><![CDATA[<p>Great post, I totally see it now that you point it out. Dreamweaver is very scalable compared to say Coda. Both great apps but coda payed way more attention to interface design. I still have not picked witch one I like better. Coda is fun to use but Dreameaver is fast(just because I&#8217;m use to using it).</p>
]]></content:encoded>
	</item>
</channel>
</rss>
