Software development models, pair programming, agile, team rooms, etc.

[ijstokes-/2FeUQLD3jedFdvTe/nMLpVzexx5G7lz at public.gmane.org (Ian Stokes-Rees)]

> One of the things I love about the agile group I'm on the board of
> (http://www.agilebazaar.org (soon to be http://www.agilenewengland.org))
> is that we are officially flavor-agnostic, and feel that different
> environments require different solutions.  So I don't feel "Thou Shalt
> Pair Program", but I do feel "Thou Shalt Somehow Promote Code Quality
> And Knowledge Transfer".  That may be through executable requirements,
> code reviews, or show-n-tells.

Interacting with other people can certainly be hard, but I feel it is an
essential part of an effective organization.  Non-work related
interaction is part of building a context to *facilitate* work-related
interaction, not just an excuse to use company money to see a movie,
play paintball, or drink beer.  Yes it is somewhat contrived, but
getting to know the people you work with is part of working together better.

In my opinion both sys admins and programmers could benefit from a lot
more of this.

I can only specifically comment on pair programming as part of the XP
agile strategy -- the teams I worked on that did this really struggled
to make it stick.  We came up with a hybrid system where people would
voluntarily pair if they were stuck or thought it would benefit their
work, and other times when I would (as the engineering manager) assign
pairs if I thought someone was stuck, if I thought some piece of work
needed multiple people to understand it, or if I perceived that someone
was deviating from our coding standards and needed to be "kept honest"
by the "continuous peer review" of pair programming.  We found pairing
worked well when it was easy to split (i.e. second computer immediately
available), as this aided with "parallel programming" where one person
codes and one person looks up some reference, API, documentation, bug,
email, etc.

All that said, there certainly seems to me to be something about
programming and system administration (which require overlapping but not
identical skill sets) that seems to attract people who are generally
*less* socially inclined.  Unfortunately for programming I think it
leads to lower quality code, and for system administration I think it
perpetuates the image "average" computer users have of the poor "bed
side manner" of the people they have to turn to for help.

Ian

_______________________________________________
Discuss mailing list
Discuss-mNDKBlG2WHs at public.gmane.org
http://lists.blu.org/mailman/listinfo/discuss