(Author’s Note: This is an old post from November 2008, restored from the old blog. Old comments were not transferred along with the content.)
I recently finished up my first real team software project. One of the classes I’m taking this semester is CS 2340 – Objects and Design. This is the first software project class at Georgia Tech, so it’s full of…well let’s just call them “learning experiences.” Most of the students have never really worked on a team before, and if they have it’s been in a more restricted environment. Technically I work in a team at CSI, but on a day to day basis I’m on my own. Most all of my tasks are delegated by my boss, and it was rare to work in sync with someone else. Needless to say, I approached this project more sure of myself than I should have been.
Our task for this semester was to develop our own version of The Oregon Trail in Smalltalk. No one in our class had any Smalltalk experience, and we’ll just say that it is “interesting” and leave the this-language-totally-sucks rants for another day. We split up into teams of Five, and were given a series of milestones and deadlines. Collectively, the milestones would represent 44% of our grade, leaving 16% for small projects and 40% for exams.
Our first milestone was due shortly after we were assigned to teams — we had to put together a rough outline of our Domain classes (a few scenarios and CRC Cards.) This milestone was no problem, but the next week we had to have our preliminary UML Diagram done. We worked to arrange a meeting, and this was where we hit our first roadblock.
Lesson one – People come and people go…
And sometimes there’s more going that coming. While we were trying to get our second meeting set up, we recieved an email from one of our group members in which she let us know she was going to be dropping the class for the semester. That was an understandable excuse, and only left us four-handed. Four seemed like plenty, so we arranged our second meeting for a night later in the week. This was the last time we heard from Teammate number four. He is still enrolled in the course, but we haven’t seen him in class and he hasn’t responded to our emails. Then there were three.
This was a real shock for me, I wasn’t expecting this sort of thing to happen. I got lucky in that the other two guys in my group have worked super hard and have been very accessible, but we could have been up a certain creek without a paddle. I realized that sometimes you just can’t count on everyone on your team. Sometimes people miss deadlines, sometimes people just up and quit, and there’s not much you can do about it. And, even though no one wants to admit it, that person could be you.
We had to scale back a lot of our plans because we were short-handed. This leads me to my second point…
Lesson two – If you can dream it, you can do it…
Given the proper amount of time and manpower, of course. This was a lesson that hit us fairly hard. We had some pretty extravagant plans for our Oregon Trail game: Markov Chains for realistic weather simulation, Procedural Generation of graphics (a la Spore), a hefty database back end, and some more all-around awesomeness. Unfortunately, when we lost team members, we realized fairly quickly that we had to adapt. We decided to scrap some of the “unessential” features. This translated to “just make the darn thing functional before demo time!” We had to scrap a lot of our cool features, but I do think we did something right here. Before we got knee-deep in late, half-finished special features, we laid out what these features would require. This made it easier to see what needed to be cut. Proper planning sort of saved us from digging ourselves into a hole this time.
The final product didn’t look quite as cool as we had hoped, but we prioritized. We managed to meet the requirements, and still had some time for bonus features.
Lesson three – Use the source (control), Luke…
Anyone who knows me will give me a lot of grief for even having to write this section (“Ryan, you ALWAYS preach the importance of adequate source control! How could you?”) and I probably deserve it. Normally I’m pretty good about source control. I try to set up a repository even for one-man personal projects. Yes, I have been known to complain about source control on other projects. But, in a moment of mass-foolishness, we decided we didn’t need a formal source control system. We set up a “repository” on Sakai, which pretty much just consisted of a Wiki with a “check out list” and a folder of the accepted “stable” Smalltalk source files. It worked just long enough to give us headaches in the end.
Initially, things were progressing slowly enough that the system worked fine. I might have the Wagon class checked out, and if a teammate decided he needed another feature in Wagon, he could just shoot me an email and have me add it while I had it in my possession. No problem. Problems began to arise the weekend before the due date when we were furiously working on features, trying to get things working (don’t judge, it happens to everyone) and we couldn’t always reach one another. Even though we knew better, we started modifying files that others had checked out. This resulted in one of my teammates having to do a (very messy) manual merge of source files right before the due date.
Even a simple setup of SVN would have saved time (and aspirin). Sometimes, it takes a little stress to reaffirm what you already knew.
Happy endings
Ultimately, everything turned out okay despite our problems. We met our deadlines, did fine on the milestones, and no one died of dysentery. My two remaining team members were great, and that was most certainly a factor. Working on a team is definitely a different experience. I have a feeling I’ll be shelving my Smalltalk knowledge after finals week, but the things I’ve learned about team work will follow me forever. Now my eyes are on next semester, where I can certainly look forward to more “Adventures in Teamwork”.