Last year, (spring semester of my Junior year), one of my computer science friends convinced me to take CS501: Software Engineering. For those who haven’t heard of it, the purpose of this class is for students to form groups of 5 to 7 people, and then find a real client to build a piece of software for.
So our input was simple: personnel included my 7 group members, and the task was to organize and produce a piece of software. For tools and technology, we had Eclipse (a popular piece of software used for compiling and running Java code), but we also had a very useful piece of collaboration technology: Subversion (SVN). Our SVN allowed us to all edit the same project, somewhat like Google Docs, and when we uploaded our updates it would merge our additions together. It would also find conflicts between different team members’ uploads and alert us to them. So technically, whether we were in the same room or dispersed across campus, we would be able to work on even the same java file without having to crowd around the same computer.
Our output was also simple, we wanted to present our client with a completed piece of software that met the requirement, we wanted to all achieve good grades in the class, and we wanted to still all be friends at the end.
So technically, our SVN should have allowed us to work relatively well at a distance. In practice though, as we spent more and more time on the project as the semester progressed, we scheduled more and more group work time. Just as we noted in class, a close proximity made us more productive. Obviously the peer pressure made us contribute more and such, but one of the most notable factors was the increased coordination when we were all programming in the same room. Oftentimes we would change structure, or want to add or change some functionality. It was so much easier to make these kinds of changes when we could just turn around and speak to the group members involved in the piece of code, explain the changes we wanted to make, and then coordinate how it could happen.
Another notable factor that depended on proximity was the increased conformity when we were together. This was actually somewhat of a problem – when all seven of us were together and determining what some feature would be, we would quickly become tired of arguing with each other and conform to some minimally controversial solution even though it might not be the best one. A third of the way through the semester, we even ended up completely redesigning the architecture of the software, because we realized what we had started with was simply too unorganized to efficiently continue.
Subscribe to:
Post Comments (Atom)
Posts
I took CS 501 that same semester, and my experience was similar. We found it was just so much faster to coordinate in person for two reasons:
ReplyDelete- Major design changes could be dealt with and agreed upon on-the-fly (as you mentioned). This minimizes the risk that people continue with an old design without realizing the change of direction, which would create extra (unnecessary) work for the team.
- Different people on the team have expertise in different areas. At least in my group, completing a given task usually required knowledge from a bunch of those areas, so it sped up the process if you could ask questions to the appropriate person right away instead of firing an email or IM and waiting for a response.
My team last year utilized several pieces of software atop of SVN to help coordinate our efforts. Trac is a popular package that includes a bug tracker and a wiki that tightly integrate with SVN. With Trac, we were able to collaborate on documentation in the wiki, leave detailed reports on changes in the SVN integration, and track bug and feature requests and assign them to various team members. We did very little work in the same place, mostly because our software was primarily decoupled. We did, however, split into project teams occasionally - our software had three major components, and we worked on each one in pairs.
ReplyDeleteThe resulting software ran rush week this year.