Project Work SEG is Done, Even with Members Dropping Out

SEG IS OVER!

For the uninitiated, SEG stands for our Part II Software Engineering Group project, where we spend a whole semester working on a piece of software while embracing the trials and tribulations of group-based software development. It all started when we were told our group allocations. The groups were randomly chosen, so if Lady Luck was having PMS at the time, you could’ve been stuck with your arch nemesis for the rest of the semester. Luckily for me, my group mates turned out to be people I’ve known anyway so we didn’t have much trouble getting it together. In the beginning, we had 6 people in our group but from Day 1, one guy never turned up. We suspected that he dropped out, so we reported it to our course supervisor.

So the five of us continued our passage through the treacherous paths of our software specification. Hartley Library became our usual meeting space, with Tuesdays 10am-12pm being permanently marked on our calendars. It was not unusual for us to book meeting rooms a week in advance. Leaving it late meant that we would be greeted by the small, cute paper clock on the reception desk telling us that the next available meeting room is from 9pm onwards 😛

Three weeks into our SEG, the unthinkable happened. Another group mate dropped out.

And then there were four.

Most groups had 6-7 people to complete the project so we were understandably nervous. However, we did a good job coping with the extra workload. There were 5 deliverables overall and we scored pretty well for the first two. For our interim demo, we explained about our group process and showed the examiners our software prototype. We did particularly well; we arrived early, we had set up our slides even before the examiners came and we delivered a finely rehearsed presentation. Everything was perfect. So it was quite a given that we thought our final demo today would be a piece of cake.

How wrong was that? Everything that could turn out wrong just did.

We wasted a whole 5 minutes out of our 20-minute slot trying to set everything up. We attempted to copy our slides onto the labs’ PCs but they couldn’t detect our thumb drive. Our backup laptops(!) decided to take the most opportune time to crash right there and then so we had to wait for one of them to recover before we could even start. We never truly recouped from that bad start; everyone was out of their element even though we had rehearsed countlessly. To make things worse, since we were on Plan C, i.e. we used one of the lab PCs to load the software, we had to take a couple more minutes to look for our test data set which was stored in some obscure folder in the depths of my filestore. Then one of our functions didn’t work ( see: http://www.phdcomics.com/comics/archive.php?comicid=821 ) before getting completely blindsided by a question that we weren’t prepared for. The whole demo was a nightmare!

However, despite the setbacks, we were able to deliver our product’s functionalities across to the examiners. We succeeded in meeting the requirements of our software. After the demo, they commented that we did a good job even though we were short on manpower. Thank God! I don’t know how we survived that ordeal, but we did. It’s a miracle.

Moral of the story? Prepare for the unexpected 😀

P/S: Somebody thought I was a PhD student! He said it was because I was involved with the WWW conference last year. I was very flattered, and I’m going to ignore any connotations that I look older than I should.