Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> One of the things I love about the agile group I'm on the board of
> ( (soon to be
> 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.


Discuss mailing list
Discuss-mNDKBlG2WHs at

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /