A while ago, I attended an HEA event with the title of “Student-Run Software Houses”. This is a topic which is both personally interesting and relevant to one of my departmental employability brief; it fits nicely both with the narrative that a University should be empowering its students to learn and live well, and with the positive noises about the Digital Economy that a Computing department should be supporting.

The day opened with the customary introduction by a senior academic, in this case Professor Palmer-Brown, Dean of the Faculty of Life Sciences and Computing. Typically, these introductions are hilarious because the senior academic has no idea what the event is, who the speakers are and why they should care; they might have had the introduction in the diary for ages, or it might have been sprung on them, but in either case they're almost certainly unprepared. Usually they'll therefore depend on the speaker schedule and titles to give them a sense for what they should say; in this case, the schedule was laconic, and it was mildly embarrassing to see the resulting flailing. Maybe the moral is for the local organizer of the event to write a script for their senior colleague? (Or else, skip the pointless welcome).

The morning sessions included a number of short(ish) talks from a number of practitioners: people helping to run their own take on student software development. The talks were interesting, not least because of the breadth of approaches, and how those approaches were often dictated by particular facilities or lack of them.

For example, Amit Chopra's Studios in Lancaster's Software Engineering programme was particularly distinguished, in my notes at least, by having their own dedicated studio space for their students. With 24-hour access. For the students. Space. My mind was blown, particularly when I also heard about the low enrolment numbers for the course. Liz Coulter-Smith's experience at Worcester was a litany of institutional dysfunction, fighting not to fall between the cracks (is student software development teaching? research? industrial engagement?) At the opposite extreme was Graham Roberts' experience from UCL, where the description of institutional support had some of the group drooling: having “2 to 3” full-time members of staff just to manage relationships between the CS courses and potential collaborators was my favourite data point. With all that, maybe the most painfully hilarious unintended consequence was the result of Apple's policy that there should be only one App Store developer account per insitution: bad luck to the student software team if the University marketing department has got there first...

One common thread among the presentations: they weren't about student-run software houses. In all cases, the organizational aspects where handled by academic staff, whether within the context of a credit-bearing module, running a digital agency on a consultancy basis (as our host Yanguo Jing from London Met does) or coordinating volunteer effort (as Elaine Major does at Greenwich). I can see why this happens: there's a natural assumption that continuity is essential, and managing reputational risk is important; on the other hand, it ought to be possible to expose students to more of the reality of running an organization as well as participating in it, to give them an appreciation for all the “other stuff” – and also to allow the non-developers among the students a chance to be substantially useful.

There was an interesting point about competition. One problem identified by academics in smaller towns is that setting up a consultancy or digital agency for coordinating student work runs the risk of competing with local business, and undercutting both through cross-subsidy and through the use of under-market-rate student labour. This is obviously not ideal; it's even worse if the competition is primarily made up of companies formed by the University's own graduates. The obvious answer is to aim to do things that are substantially different from local businesses; on the other hand, doing things that no-one else is doing introduces risks, because possible reasons for no-one doing things include “they're too hard” and “no-one wants them”. Still, there might be valuable lessons there for students too.