Software Development isn't a Field for Loners

Preview image from us.123rf.com, "Collective Problem Solving", copyright Stanislav Komogorov

A young friend of mine, a first year student studying to become a computer engineer, recently sent to me a copy of his school's 3rd year curriculum, asking me for comments. Now, on the one hand, I'm no curriculum expert, not having really looked at a college catalog for computer science in many a year. But, on the other hand, it's a rare topic that leaves me without an opinion when I'm asked to look at something.

On the plus side, the curriculum was packed full of technical courses. It was quite different from my own experience at Cornell U. where every semester in Cornell Engineering had room for at least one elective. My recollection is that the catalog's requirements at Cornell actually demanded that your courses not just be in "Your" school. That requirement was sometimes annoying to comply with, but in the long run, I do think the University succeeded in exposing me to more diverse backgrounds by forcing me to get out and about in more than just the engineering school. Far as I can tell, at my friend's school everyone in his major is expected to work through the same heavy technical course load in their 3rd year.

In my opinion, the weakest aspect of the curriculum I was looking at today was lack of team or group projects. Why do I think that is so important? Well, software development isn't really a field for loners. Programmers may get mocked at social events for not fitting in, but software development is most definitely a team activity. Where do we go wrong at social events? I think it is just a tendency to be so darn focused on the challenging problems at hand at work that keeps us from adequately noticing that the techy stuff is of no interest at all to the Muggles at the party.

Contemporary programming methodologies (e.g. Agile, Scrum, Extreme programming) pretty much mandate that you be able to work with and communicate with other people. Now I concede that it is remarkably difficult to build "collaboration" into an engineering curriculum. First the programming language has to be taught, and then algorithms, and the rudiments of collaboration tools (e.g. git, code review tools, ...) before you can even think about springing a team effort on to some subset of a class. Getting students to actually work together, especially at a non-residential college, can be difficult. To be interesting, the project has to be big enough that splitting the work up across the team has to make sense, but it still has to fit into a semester of mortal efforts. Figuring out how to fairly give grades in such a course where maybe some of the team has done more than the rest of the team is doubtless a hard problem, one that I have no real solution for here.

I do remember some group projects from my undergraduate days. In our OS class, the assignment was to create an OS. My recollection is that we had some reasonably bright people on our team, but the semester ended without the OS really gelling into a working whole. We had managed to run into some really interesting problems in our software and we passed the course, perhaps on the strength of our war stories that showed we'd indeed really tried to think it through.

And not quite a group project, but scarily close to the real world: I remember a class in file processing. We'd been given an assignment and were told to bring in the runnable decks of punch cards as part of what we had to turn in. The professor collected the assignments and then gave them back out again, but you didn't get back your own program - You got someone else's program. The next assignment was to modify that someone else's program to add a new output report to it. I'm not sure which was more painful: modifying the crappy program I'd been handed without taking the time to rewrite it entirely, or looking at how someone else modified my program to add on the new report routine. Most definitely one of the more educational software assignments in the many software assignments I worked through as an undergrad.

So that's the problem as I see it - lack of collaborative software development in engineering schools. Has anyone got real world examples of a curriculum that in fact teaches collaborative software development at an undergraduate level? If you've got an example or counter-example, please add a comment to this article to tell us about it.

I tried to design a collaborative software development course to suggest for a local community college here. In the end, I decided that wasn't going to work. Junior college has to nominally fit in a mere 4 semesters. They are barely able to introduce C in their curriculum. I believe you'd want a much higher-level language, like Python, as the basis for any large scale group project. Python libraries and modules, object oriented programming patterns, ... Too much to cover before you could even start to talk about working as a team on a larger scale project. I'd have no objection to swapping out their C course for a course that instead introduces Python, but I think that'd be a tough political battle with the opposing forces arguing that C is a much more commercially important programming language than Python.

So I dropped back and punted: the 4-semester problem was fitting in programming, software development techniques and collaboration. In my opinion, the crucial new material is the collaboration, so I've been sketching out a course on how to be a member of a work team. I believe it wouldn't even be specific to the computer science department, but could be offered within the school's communication department. My organized collection of links to web pages I dug into while working on the idea of such a course are available on Pearltrees.com: rdrewd collaboration pearltree. Ironically, I couldn't find a collaborator to work on the project with me, so it's somewhat fallen to the wayside. If you'd be interested in a possibly long-distance collaboration on the design of such a course, please contact me. My email:Drew's mailbox (no spam, please).