Group Programming


Tackling a programming project as a group rather than as an individual changes the way the project is constructed. The group approach in my opinion creates a more successful outcome but adds new challenges as well. My experience with iteration one has definitely favored group work above individual work. In iteration one we had a few setbacks because of multiple people working on the same project but the benefits of group work far exceeded those challenges.

The first challenge that we encountered from group work was communication error. When working as a group my partner and I would sometimes interpret each other wrong or there would be a lack of communication. For example, sometimes we would work on the project at the same time and when we checked in our code one of us would get a code conflict. The solution to this problem was obvious to us. We just needed to communicate more. Whenever one of us began working on the project we made sure to inform the other. This was an easy problem to resolve and we haven't had a code conflict since.

Sometimes one of us would have a really good idea but explaining the idea to the other partner would be another setback. It can be difficult to express your ideas about code in words sometimes and this would delay our progress at times. Our response to this problem was to write pseudo code to the other partner to help them understand. Usually this was enough to at least convince one another to move forward with the code.

Our second challenge was the problem of conflicting ideas. We would find ourselves at a point where we both think our own idea would be the best and cannot decide which to use. In this situation we would pick one or more of the following options. We would just pick one, we would implement both of them and compare them, we would argue until the other was convinced or we would do both when applicable. As an example when designing our linked list I used the new operator while my partner used the malloc function. Our final result ended up using both the new operator and malloc function. I think next time we will just pick a single method for code readability but in this instance it worked out just fine.

This is one of the great things about group programming though. Having different perspectives on things can really help with difficult problems. I feel like most of our success came from having different perspectives. Rather than just taking the only idea available we were able to take the best idea from two minds. Additionally, there was the occasion where one of us was just wrong and it helped things go much smoother when the other had the answer. Everybody has different strengths and weaknesses. Much of the time if I am weak in a particular subject my partner can help me and vice versa. For our next iteration I will make sure to keep in contact with my partner more to take advantage of this. I found that when we code together we make much more progress.

My favorite advantage to group work is sharing the workload. I find it a great feeling when I personally do not have all the responsibility of the project. I can count on my partner to do his work without worry. Whenever I get stuck my partner can help me figure out the solution. When we were working on simpler parts of the project, such as enumerating the regular expression types, we could break it up in half and complete them separately. I find this a particularly effective strategy when dealing with simple coding tasks.


You brought up some really great examples of how there are challenges when working in groups. Some of those I haven't encountered yet, which is nice because now I know how to overcome it easier. I also completely agree with sharing the workload. Although some bits of code are trivial, it would be nice to split up that work because it can sometimes be very extensive. Any time saved is always a nice thing.

Scott Gee

I agree that it can be difficult at times to work in groups, especially when you are working from different locations. The benefit of multiple perspectives has to be balanced with communication. For instance, at work, we have meetings every other day, our workstations are all next to each others', and we are all on Skype. This way we can be consistent in our approach.

Caleb Ahlquist

I agree that communicating technical ideas can be a challenge. However it is extremely important to be able to do so. You also need to be able to tailor your explanation to your audience. For example, if you are talking with another programmer you can be more technical while if you are talking with a manager you probably want to give more of an overview of your implementation. Having these communication skills makes you a more valuable asset to a team and is essential to finding a job.

-Kevin Mehlhaff

You touched on many good points about the benefits as well as the setbacks of working on a team. I definitely agree that it is important to be able to communicate technical ideas with others, mainly because I struggle with this at times. The main problem I have is talking too fast and assuming my audience has a certain understanding of the problem when they might not. I hope to continually improve on this skill though to become a better communicator and a better team member. After all, being able to minimize the struggles of working on a team will help one appreciate how valuable working with others is.

Lars Anderson

I find it really important to effectively communicate technical ideas with different audience. This reminds of a Microsoft Interview question. They are asking you to explain a specific technical problem to your grandma. Being asked, I remembered I do have a struggle with how to deliver my idea. This is because I always assume that my audience has the basic understanding but actually they don't. Thus I will work on improving my communication skill as the semester progress and hope every of you get a e become a better communicator and team member with the development on communication.
-Yannan Wang

Leave a comment

About this Entry

This page contains a single entry by Nicholas Ellis (ellis348) published on October 14, 2011 10:00 AM.

Topics that I know, topics that I don't was the previous entry in this blog.

Source Control and Subversion is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.