[hand with pencil]
Stuff For Sale
2004 Summer Tour
Class Stuff
Email Me
In The Press
Veggie Van Gogh

© 2002,

[this is simply a banner and menu bar]

Please patronize sponsors of this page!

Bytesmiths no longer is involved in software consulting. Maintenance of this web site is currently subsidised by unrelated business activities. Please pass the word to other interested folks, so I can continue to host this page!
Your site could be listed here, for as little as $12 per month! Go to Bytesmiths Press for details.

This site has been selected by PC Webopaedia as one of the best on this topic!
This site has been awarded a Links2Go Key Resource Award in the Smalltalk category!

[ prev | top | next ]

Roles of the Developers

(This is a slide show. You really won't get 
anything out of it unless you have a graphical web browser with graphics turned 

The developer need not be the class owner. This role cannot be reassigned, so in mid-development of a new class that has not been versioned, another developer cannot take over and continue what the first one started. This means that copying another developer's image with editable classes in it, sharing passwords, and then concurrently working in the same class editions is a no-no. ENVY will not let either developer version the class until conflicts are resolved.


The manager of an application must communicate with the managers of the contained subapplications (there can be different managers for an app and each of its subs). The app manager can be made responsible for the integration of their application and its subs. They are responsible for documenting the application (yes, there are application and subapplication comments). They should test the loading and unloading of the application.

The manager of a configuration could be responsible for overall integration and satisfactory testing. This role could/should be rotated among team members. The days of the "guru" approach are over with ENVY. (Unless that is what you really want to do.)

A class owner should never release changes made to their class without first verifying them. Hopefully, this is obvious.

A class developer should give a recognizable version name to his or her version, then inform the owner of the reason for their changes and ask the owner to integrate their changes. It is counter productive to the team effort to routinely change another's classes and never tell the owner about how you think it should be improved. This applies to the development environment tools, too. With ENVY, the "my image is my world" attitude (e. g., I can change anything I want, even base classes) is obsolete. (Unless that is the team culture you really want.)

[ prev | top | next ]