Team Development / Exporting stuff to text files

[Richard Gaskin]

David Bovill wrote:

 >> On Tue, Mar 4, 2008 at 11:58 AM, Richard Gaskin
 >> > I've thought about the type of scenarios described here, in
 >> > which two or more programmers may be assigned to work on the
 >> > same stack, but to be honest to me that seems less a technical
 >> > challenge than an architectural and human resources one
 >>
 > On 05/03/2008, Chipp Walters <chipp at chipp.com> wrote:
 >> Agreed 100%.
 >>
 >> Key word in the below sentence is "architectural". IMO, a properly
 >> designed architecture can handle multiple programmers, each working
 >> on their own stacks.
 >
 > Agreed as well - but in the context of your own or a relatively small
 > groups productivity. That is it is not worth going down the path of
 > svn or finer granularity for your own productivity, unless perhaps
 > you and your team are already familiar with such tools and working
 > practices based on other languages.

If you're bringing in developers familiar with other languages, the 
learning curve for something as simple as Magic Carpet is trivial 
compared to the time to learn how to use Rev itself effectively (not to 
mention the additional time needed to figure out a scheme for 
integrating Rev with something like SVN, and the day-to-day overhead 
inherent in using such a scheme).

Rev isn't just another language. It's also an object model and file 
format, all bound together to create a unique way of working.  I'm not 
sure tools designed for other languages can always be expected to 
integrate gracefully well a Rev workflow.

Admittedly my own experience is perhaps limited, having managed 
xTalk-based projects with only 25 developers at most.  But that's a fair 
number of developers, for a project whose budget was well over a million 
dollars.  Projects of that scope are rare, but it's worth noting that it 
was done with a stack-based check-in/check-out, with significant cost 
savings to both our team and the client.

That said, I suppose if we look at all possible scenarios we could find 
circumstances for which a finer level of granularity may have a positive 
ROI.  We've found no significant limitations with stack-based 
check-in/check-out thus far, but in the infinite range of all 
possibilities I can't rule out that we might be able to lower our costs 
even more with a different way of working.

Chipp's Magic Carpet is a very capable stack-level tool available now, 
and being such a with-the-grain way of working with Rev it's not too 
hard to craft on of your own if you need to.

If tools supporting a finer level of granularity exist and are 
demonstrated to provide a higher ROI than the many projects delivered 
with stack-based tools, I'd certainly be interested in checking them out 
(if you'll pardon the pun).

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com