Being a relatively mature two-person group, we have been helped greatly by Pair Programming. Since Alan and I know each other well and have worked together on a number of different projects in the past, we are able to communicate effectively and are not afraid to voice our opinions. Working together to solve problems has also led to more eyes on code and finding bugs that we might normally have glanced over, which could have come back to haunt us in future development.
That being said, pair programming may not be as effective as it is for our group when used with newbie student groups. We think that comfort and group interactions play the largest role in successfuly pair programming. When pairing new students together in an introductory lab, their comfort level may not be high enough to facilitate a high level of productivity.
Another major factor in pair programming is the environment, and how that shapes development. In our case, we're working in my room with dual monitors that can easily be seen by both team members. Often students may be working from one laptop or a single monitor, which can make it difficult for team members to have eyes constantly on code. Additional monitors, we feel, are necessary for pair programming to be successful.
One quote I came up with during one of our meetings was: "Incompetency can be alleviated through communication and comfort." This doesn't necessarily hold true for all projects, but I think that those two concepts (communication and comfort) can set projects on the right track. Of course there are other factors that can determine the success of a project; primarily, enthusiasm for the work. I won't delve into it too much, but if pair programming inspires the group to come together and solve problems than it certainly is a boon to productivity.
I posit that a pair of programmers is only as good as its weakest link. That is, if oen member expresses low interest, both members suffer. With a group of programmers that express high interest, their productivity is also high and could be multiplied.
There are some stumbling blocks to pair programming. I've highlighted a few of them: personality, comfort, work ethic, and interest. Another is the maturify level of the students or members undertaking the project. I posit that higher maturity levels will naturally increase productivity. The question is mainly how to inspire maturity in younger students, especially when they may or may not have met each other. Thoughts on this would be good.
Moving on to collective code ownership! Collective ownership essentially drives all programmers to contribute to all facets of the project. This is essential to many projects but is crucial for student projects. In the professional world, developers may have specialties and thus may be better suited prioritizing their work towards certain areas, reducing the need for collective ownership. Student projects may or may not have group members that have special talents, and thus collective ownership can result in an overall better project.
This is demonstrated to a good degree with Trivioid. While Alan and I do have different areas of expertise, we are certainly not discouraged from making changes to or improving each other's work. Unit testing can be a huge boon to collective code ownership. If developers create effective unit tests, a suite can be created that can make sure code changes still allow for proper building. Continuous integration can also be an essential tool, which, when used in conjunction with collective ownership, can make development more efficient.
No comments:
Post a Comment