Serious applications

Richard Gaskin ambassador at fourthworld.com
Wed Feb 25 19:49:54 EST 2004


Graham Samuel wrote:

> I guess we Revvers should be able to answer the question
 > "can RunRev cut the mustard in an industrial-scale context?
> Would RR be suitable for a development involving 10, 20 or
 > more staff?".

Case in point: this afternoon I'm building a stack-based content-editing 
system for a 20-person team to work on one set of stack files from 
locations on three different continents.  This is for a very specialized 
audience for a very specific type of content, so it also shows off how 
easy it is to make custom GUIs in Rev.  Even the tools these contributor 
use to manage the system update themselves on the fly as I release new 
versions, keeping them up to date without breaking their workflow.

There's been a lot of discussion about how hard it is to manage team 
efforts using CVS, but most of that seems caused at least in part by the 
difficulty in mapping the C or Java workflow (hundreds of tiny text 
files) onto the Transcript workflow (usually a small number of stack 
files).  There may be value in allowing every team member to modify 
every property of every object in real-time, but if you could work at a 
broader level of granularity, at the stack file level, you can craft a 
native solution and get 80+% of the practical benefits with less than 
10% of the overhead of attempting to coerce an alien model from other 
systems.

I've used WebDAV when I was tech-editing a book on GoLive, but I've 
never used it in practice.  So there may be some sort of 
can't-live-without-it value that just eludes my ignorance.  In my 
limited work I found it cumbersome, but I know a lot of people love it 
and probably for good reason.

My point is not whether WebDAV or CVS are worthy, but whether they are 
worth the unsual effort needed to coerce an unusual development system 
like Rev into working with them.

The question becomes compounded by the tremendous ease of crafting any 
number of stack-base check-in/check-out systems.  Scott Rossi built a 
fun one in probably 0.001% of the time spent developing WebDAV, and it 
provides the basics of stack-based check-in/check-out.  He showed it 
here at a RevDevCon last fall and it was way cool (and almost as 
attractive as his custom editing palettes).


There's another advantage to supporting of group workflows at the stack 
level as opposed to the script or object level that goes beyond the 
obvious technical merit from the ease of doing so: it helps enforce 
healthy factoring along dividing lines based on groupings of application 
functionality.

One of the results of following good practice in any language is to 
minimize potential complexity by keeping code in discrete modules and 
separating it as much as possible from data and interface objects.  Each 
element then acts as a sort of black box, like libURL, and can be 
maintained along parallel but separate tracks from other project components.

A stack-based approach allows one person to work on the Preferences 
window while another works on document-handling and a third works on a 
toolbar.  The dividing lines of stacks usually involve discrete 
functionality, and working on them separately helps keep their 
interconnections to a minimum, greatly reducing overall complexity.


A simple stack-based check-in/check-out may not serve the needs of 
100-person teams, but how many projects really require 100-person teams? 
(esp. condering the diminishing returns McConnell describes in his 
discussion of team size in "Rapid Development")

For the types of small-team projects Rev may be ideally suited for a 
stack-based solution is a practical alternative that can be used today. 
  It solves the most common problems immediately, and lays the 
foundation for enhancements to something more well-suited for 100-person 
teams down the road.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com


More information about the use-livecode mailing list