Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> 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
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |