what worked and what needs work
Posted by Diane Tam on 2009/12/03
First off, thank you to Greg and all the profs and TAs that made this project course possible. It was definitely a unique and invaluable experience that I believe all students should consider in their undergraduate years.
I’ve been working full-time as a programmer for 3 years now and I wish I had taken this course during my undergrad as this course is extremely applicable to real life work practices. It teaches you about the importance of communication and coordination with teams across the world with respect to solving a problem. This is a very common scenario in the workplace, whether it be communication, design, integrating code, code reviews, etc…and this course helps set you in that mindset and find ways to work with it. Overcoming obstacles like timezone differences can be difficult but not impossible. With good planning and communication, teams can work very well together and produce results. This course definitely puts you in that perspective and forces you to realize the importance of planning and communication. Having this experience before setting out full-time as a programmer or any profession in fact gives you a great additional skill set!
What needs work:
Having said that, working ‘virtually’ with teammates really posed a challenge with respect to communication. I know this is something many teams posted about but I’m going to emphasize on the planning aspect of communication. A good plan could lead to a good design which in turn could lead to good direction. The code sprint was a great chance for teams to spend the time planning and designing their systems but after that, it was difficult to do any. As a result, no one actually ‘fully’ understood the entire system. It’s difficult to design out the whole system at first and many requirements can change along the way. I think implementing an iterative design and development process could have worked here. Rather than looking at milestones, look at perhaps shorter two week sprints. Dedicate a couple of days before each two week sprint to plan out what needs to be done in that period, address design issues for only those tasks and work on those specific items. After a sprint, address outstanding issues and move on to the next set of tasks needed. Taking on the system in appropriate chunks not only allows you to focus in on a specific area, but it allows you to understand how one part integrates with the next and realize what works and doesn’t work with the design early on. It also gives you more direction because you are not overwhelmed with the big picture. Communication with respect to these smaller iterative periods could be improved as well since everyone understands what is going on and what needs to be done in that two week cycle. Perhaps this is something that could be considered within teams to help the struggle of meeting deadlines, communication and direction.
Thanks again for the great experience everyone!