Re: Of disk swapping, database structure & project management..

[Jeff Kesselman <jeffk#tenetwork,com>]

At 09:00 AM 4/13/97 -0700, you wrote:

I've also worked on alot of group projects, both as lead and as one fo
ateam,  note hwoever that all my expreicne has been bsicly afce to face.
Everyone 'telecommunting' is a ngihtmare to begin with and you probably DO
haver to be stricter in those cases...

>    front.
>  Establish a set of agreed upon base principles up front.

Absolutely.

>  Have one guy be the boss.

Ild say "lead", im a bit more flexible. There has to be one guy who directs
the effort but I dont thin khe HAS to be dictator necc.

>  Have the boss'es final word be the final law without argument.

The lead shoudl be able to state how a decision will be reached, though
taht might be by vote or copncsensus or fiat.

>  *NEVER* attempt to work via democracy or concensus.

I disagree here.  Ahving worked in grousop where EVERYONE was an
expereicned lead, consensus CAN work.  It takes tiem however, and it only
works well face to face.  (The Americna indians did EVERYITHING by consensus.)

I agree a vote is bad befause there are "losesers" in almos tany vote which
is bad for morale and encourages project splits.  For this reason ,with
intelligent dynamic develoerps however, fiat can ALSO fail.

>  Assign responsibilities in clearly defined areas/boxes.
>  Attempt to minimise the extent to which those boxes overlap.
>  Attempt to minimise the extent to which those boxes inter-depend.

Ild say al lthis differently.  Do a true architectural design.  Have  chief
architectect whose job it is to hold the design (thsi is usually the lead),
witha  good architecture you will have moduiles and interfaces, assign one
or more modules to easch developer.  Let them be creative with implementation
but insist that they bring ANY wished for interafce mods back to the
entire group for dicusssion -- make inetrface mdos after design phase PAINFUL.

JK