Teams

Richard Gaskin ambassador at fourthworld.com
Tue Aug 5 13:03:01 EDT 2003


Troy Rollins wrote:

> On Tuesday, August 5, 2003, at 12:26  PM, Richard Gaskin wrote:
> 
>> In the meantime, I've worked in teams of four or five with Rev stuff
>> and we
>> did it with no special tools at all.  We used a modular aproach with
>> multiple stack files, having defined a few rules about how the parts
>> fit
>> together and what's expected from each.  Each module had an owner, and
>> the
>> modules were prioritized according to how commonly they are used
>> throughout
>> the system.  Only two of us lived in the same city, and with nothing
>> more
>> than an FTP repository, email, and a good long-distance rate it seemed
>> to go
>> well.
> 
> Well, sure. At the stack level that works. I can't figure a good way to
> do this any deeper in Rev.
> 
> RB's promise(not yet fulfilled) is to allow such modularity at the
> control level. e.g. I place the button, you code it, I modify it, yours
> gets modified.
> 
> Even in small groups of two to five, this could have a lot of
> advantages. I find that each developer has a natural inclination to
> certain types of routines, so with such a system each specialist can
> focus on their specialty. Since my team is all in-house, the verbal
> communications are a non-issue - the real-time synchronization is.

In our workgroups those specialties were given expression in libraries,
separate stacks incorporated with "start using".  Not only does keeping
things at the stack level allow greater modularity in development, but it
also keeps overall code size down and facilitates maintenance -- to deliver
a new feature to a client can be as simple as an automated HTTP download of
a relatively small file.

I agree that object-level version control is desirable, if only for the
theoretical perception of completeness.  But from a real-world workflow
standpoint, I haven't seen practical benefits from having that many cooks
working on the same control layout simultaneously. That last word is key:  I
have had many cases where a programmer will do an initial layout and build
functionality, and then hand it off to a UI specialist for fine-tuning.  But
if both were wrestling with the same layout before either is done I can only
imagine a slower overall workflow.

Well-crafted libraries can include objects, such as a table widget I built
for a team recently that is used in nearly every stack.  The object is a
group, and the lib contains its own creation and property editor which is
available only in the dev enviroment.  Folks working on other stacks simply
use the UI I provided to create the table and modify its contents, and any
bugs or enhancement requests are sent to me, I incorporate them into the
master lib, and everyone's stacks benefit from the update immediately.

In all fairness there may benefits to allowing simultaneous object-level
development of a given layout that my aging mind simple hasn't considered.
If you could describe such a scenario it would be helpful for my
understanding of the task of building such a version control tool.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge: Publish any database on any Web site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc




More information about the use-livecode mailing list