[opensource] Group Dynamics
gorse.1 at osu.edu
Tue May 23 00:58:25 EDT 2006
560 is not a very academic "learning" course. It's a "get shit done
that works" course, with enough structure to define software needs,
but not enough to warrant the "in-the-box" thinking that most courses
and labs merit.
My advice for the Lord of the Flies groups where everyone has a say,
is that you let your stars shine, the mediocre do easy stuff, and
minimize the damage of the negative hitters with waving your hands at
the smoke and mirrors. Don't be afraid to make people responsible for
support roles and not coding. Not everyone can code well or quickly,
so if you have people that can, use them for coding, not group
management or other things which distract them. For example, have a
person learn how to use Makefiles, a person to learn how to use
Automake, a person to learn Doxygen, a person to learn CVS or
subversion, etc. and then have them teach the relevant commands to
the rest of the group with examples. I wrote a total of no more than
100 lines of code the entire time I spent in the labs with my
groupmates, but don't think for a second I wasn't contributing. I
debugged, I taught people most of the tools, I supported the tools,
and I was always there to assist anyone who needed help. I was Tech
Support. =) We were fortunate to have a professional Java coder, so
the design and group management was directed well by him. Overall I
thought it was a good experience and I will take with me forever the
concept of documentation first. Documentation is easier than
implementation, and it makes short cuts a lot more obvious.
One last bit is just a piece of coding advice: code half as clever as
you are, because debugging takes twice the cleverness to understand
the code you're reading.
On May 22, 2006, at 11:19 PM, Drew Yates wrote:
> This "560 group" talk brings to mind a mystery that I've never
> quite been able to puzzle a decent heuristic for...
> What are all of your experiences with group projects with strangers
> and how do you, by default, treat your teammates and what do you
> expect from them?
> What are the best methods to participate in a group where everyone
> is "equal" and has a equal stake in the reward, but may have
> unequal capacities or expectations?
> How do you maximize project quality, minimize aggregate work,
> minimize personal work, minimize risk, or achieve any combination
> of these goals?
> To Start (just a couple of scenarios I've come across...)
> The Rambo: (++)Simplicity (*)Risk (*)Quality (--)Personal Work (+)
> Aggregate Work
> You do the entire project yourself without contribution. The Risk
> and Quality is equal to exactly your personal capacity. Total
> project work is usually less than normal because there is no
> overhead, but, of course, total work is equal to personal work.
> Dueling Rambos:
> In my experience, there can only be one Rambo. If two people are of
> the Rambo mindset in a group, while there may be some initial
> cooperation, one of the two (usually the more competent one) will
> eventually grow impatient and take over and/or one will defer to
> the other and instead claim ownership of a small piece of the project.
> Opensource mailing list
> Opensource at cse.ohio-state.edu
More information about the Opensource