Title: From the Academic Coalface

Please note that even if you think you can guess the author of this item, please do not speculate. I think all can agree that confidentiality is important for items such as this one.

Six-week student project in Java; myself and five others. First two weeks meant to be formalising the spec, dividing into modules and specifying each module. Manager says "we don't need managing", no agreement reached and no spec produced. I write one up just before the deadline and everyone agrees to use that.

Next two weeks supposed to be implementation and unit test. I'm assigned to do testing, code walkthroughs and generally making sure it's all right. Attempts to communicate fail, then everyone dumps their code on me at the last minute, saying things like "I wasn't sure how to implement it because your spec didn't tell me". Most code has syntax errors; plenty of magic numbers, lack of OOP understanding and plain unreadability (at least, not good enough for me to fix it all in the time I have). I try to give detailed reports but they're mostly unread. UI designer's code is better (it actually compiles) but he'd worked to his own spec because he didn't know which parts of mine to read.

Week 5: I explain the spec to everyone, write them pseudocode where necessary, explain some OOP, etc. Things start moving. I do some implementation myself. We spot mistakes in my spec and I hack around them. Most people aren't interested in what's wrong with their code as long as I can fix it. I compromise some of my ideals to fix things fast enough.

One week left. I read up on Yourdon's Death March projects and try to give morale-boosting talks, emphasising triage. We switch to surgical team with myself as surgeon, and all get together for an afternoon to get it integrated and working come what may. I don't know what's going on behind me; someone says "you'll find out when you have to check it". Sometimes people work on their own copies of code I'd fixed, creating version problems (they're not all confident with RCS). But we succeed in getting it working and fulfilling minimum requirements, with not too much depression and under the suggested per-person-hours budget.

In the demonstration session, someone runs an old version by accident, then locks the workstation and walks off. When we get around that, we hit a cosmetic bug in the GUI and I fix it while nobody's looking. I offer to explain it to the GUI person but he's had enough. Then I do a 5-minute presentation to the whole department (nobody else wanted to), emphasising the fact that we'd pulled off a DM project under budget. We get our marks, but one or two are disappointed that we weren't voted best project.

Finally a quote from the Doctor: "Since we moved to Java, students' projects have improved tremendously - much better graphics..." The idea of making students work in teams is excellent, but it needs to be monitored. At the very least a team should be required to keep an activity log. The overall performance of individuals can be tracked and credit given to good team players. I would welcome articles from both students and lecturers/tutors on how such activities can be better managed. .