The weekly bag– Jan 12
- Orcas Team Build Continuous Integration spec is now available- CI is finally coming to TFS– why’d they wait so long, man?
- Automation for the people: Improving code with Eclipse plugins- Paul Duvall elaborates on “big five” code analysis areas and how one can monitor them via Eclipse plugins.
- Introduction to Apache Maven 2 - IBM DevWork’s tutorials are so disco, man.
- Want Testable Code? Be Careful with Static State- Jeremy Miller’s got some disco points in this one.
- Testing database with NDbUnit - A disco tutorial on how to use NDbUnit!
- Code Quality in Eclipse- Levent Gurses points out two additional code analysis plugins for Eclipse.
- TFS Build Scripts- Best Practice- Accentient clears up some misunderstandings with the number of build scripts one may need for TFS. How many do you need?
- Effective Java Exceptions- Dev2Dev has a good article here– definitely worth a read, man!
- Debating the Merits of Pair Programming- InfoQ reports that pair programming “seems to promote mediocrity”– wow! What do you think?
| Related odds and ends | ||
|---|---|---|
Saturday 13 Jan 2007 | Weekly Bag
“InfoQ reports that pair programming “seems to promote mediocrity”– wow! What do you think?”
From Mike Arace, author of the original post to InfoQ:
“…I have heard people talk about Agile as a methodology of disciple, where you need to follow the rules all the time to get a benefit from it. Unit test everything, do all coding with others, that sort of thing… It’s just the thought of having someone sitting next to me analyzing my code as I write it sounds incredibly wasteful and annoying, and will result in opinions being shared that are totally inconsequential to task at hand…”
Clearly Mike did not had a chance to meet the right people in the Agile community. He also seems to have missed a few good books on the subject. I think his arguments are mostly baseless and therefore worthless of any further analysis.
Thanks for sharing Andy.
I knew you’d disagree, friend. I’ve had more than one client adopt the gamut of agile principles but eschew pair programming due to fears relating to resources, etc. What’s not clear to me is the comment that pair programming will “result in opinions being shared that are totally inconsequential to task at hand”– more often than not, opinions shared relate to the quality of the code (or related test) or the effectiveness of a chosen algorithm. I’m having a hard time thinking how these opinions wouldn’t be beneficial to the pair as well as the organization sponsoring them.