Stephen Barncard wrote:
It would probably then be necessary to spit out
details of ALL properties for each object (472 last
time I looked) which would be both silly and involve a
lot of redundancy . . .
1. who cares about redundancy?
2. The entire list of properties in an object can be made into an
array (and saved as a single prop set)
3. Only non-stock differences in a created object need to be logged.
True. I don't do much with textual descriptions of objects any more, but
back in the days when I used to play with such things I stored only the
deltas from the default state of template objects. If you reset the
template objects after use this is a simple and efficient way to
recreate objects from the smallest descriptions possible.
But stepping back to look at the bigger picture, I've not yet understood
the practical benefit of focusing on this fine level of granularity for
team development in Rev.
My own experiments with textual descriptions were to craft a 5GL for
rapidly creating objects using an ultra-lightweight "markdown" syntax in
the Message Box. Fun at the time, but I can't say I've been motivated
to refine it in many years. :)
For actually sharing objects among team members it's hard to beat the
efficient, compact binary representation you get naturally in a stack file.
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:
If the code in a dialog is so complex that it takes two programmers to
work on it, how did it become so complex?
- Is there anything in it which might be useful elsewhere like a library
so it could be used by other parts of the system, or perhaps even
similar systems in the future?
- How does that window interact with the rest of the system?
- Were the gozintas and gozouttas (inputs and outputs) of the window
clearly defined during the architecture phase?
- Are the connections between this window and other parts of the system
defined well enough to support both unit testing and extensibility?
- If two programmers are each working on a different button in the same
window, what do they do if they need to add something to the card or
stack script for all buttons to use?
- If they're working independently, how would they even discover such
common needs?
- Does the project management system support a level of granularity down
to the handler level?
- Down to the line of code?
- Down to the token?
As granularity increases, so do the questions about managing the workflow.
In his book "Rapid Development", Steven McConnell cites stats from the
ACM and elsewhere about the relationship between productivity and team
size. The exact measurements will of course vary based on many factors,
but he feels that a good general rule of thumb is that a second
programmer will add only 50% more productivity to the effort, a third
adds roughly 30%, etc. This is because of the high overhead involved in
coordination and communication among team members (not to mention the
dreaded weekly status reports, which he has a lot to say about also <g>).
Of course there's much to be said for "Xtreme Programming" practices,
but even then this rule of thumb generally holds true, with the
difference being that the productivity unit being measured isn't a
single programmer but a pair of programmers. The key to this
measurement is people per module; even in an XP shop, you'll see lower
per-person productivity as you add more human resource units (paired
programmers) to a given module.
Sometimes a module is simply big enough that it may need that. But more
often, when it gets that complex it can be broken down into multiple
modules even more easily, simplifying not only team management but also
the code itself.
McConnell's stats seem to reinforce the usefulness of architecting
modules as "black boxes", so that each team member (or pair in XP) is
essentially building a discrete subsystem, its own "mini-program" if you
will, with well-defined gozintas and gozouttas.
In Rev, this translates most naturally to stacks, whether UI windows or
code libraries. With 50 libraries, 10 backscript, and 10 frontscripts
available at runtime, there are many ways to divide functionality into
discrete logical units.
Chipp, Ken, and the others here who regularly employ multiple team
members to deliver commercial products seem consistent in their use of
stacks as work units. The correlation between their prolific output,
ROI, product quality, and the use of stacks as the shared work unit may
be more than coincidental.
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
