Troy Rollins wrote: > I'm curious if anyone on this list actively develops software in teams > (more than actively coding developer, plus other support people), and > what techniques you are employing for maintaining a synchronized > modular team project - ideally through a server. > > This functionality is pretty important if you have more than one > developer on a team. > > Anyone doing anything in this way? > > (NOTE : The "RBPM" mentioned above works (if it worked) much like > WebDav, with the ability to log in to a project, check out specific > items for editing, and maintain synchronization of the latest versions. > Like CVS but more simple and seamless.)
Amen to that. WebDAV is a mess. Given Rev's capabilities it wouldn't take more than a couple days to have a basic version that provides a check-in/check-out mechanism at the substack level, which should be sufficient for most projects. I've been daydreaming of this as an open source project, but when I snap out of my Walter Mitty moment I realize I don't have the spare non-billable time right now myself. :) 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. It may sound primitive and indeed it was, remembering that the root of "primitive" is "prime". The coordination among less than half a dozen people is usually just simple enough to allow this sort of flow to work well. If you have a project with maybe a dozen or more developers it may get out of hand, but even then tools will only do so much: as Steve McConnel points out in "Rapid Development", if a single programmer has a productivity we can quantify as X, the second will add .5X and so on. The generic overhead of communication/coordination between team members is increased disproportionately as team size grows, and every project has a theoretical limit after which you have a case of diminishing returns. I'm a big fan of keeping teams as small as possible given constaints on the timeline, and for small teams you may not need any specialized tools beyond FTP, email, a telephone, and an occassional white board. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
