Team Development / Exporting stuff to text files
ambassador at fourthworld.com
Wed Mar 5 15:34:29 EST 2008
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).
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the Use-livecode