Team Development / Exporting stuff to text files

[Richard Gaskin]

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