![](bg3.png)
our experience, reassuring a potential provider of a
student placement that there is minimal red tape in-
volved yields more interest in providing a placement.
The student project must be subject to scrutiny and as-
sessment for academic purposes, but this is achieved
through direct dialogue with the industrial supervisor
rather than supplying forms to be completed.
Building fruitful two-way relationships with in-
dustrial parties is not an easy task. The authors have
many years of experience working within the target
industry and, consequently, a wide network of con-
tacts which can provide a rich source of collaboration.
However these contacts are not taken for granted, and
we are constantly aware that our relationships now, as
academics, are different to what they were as indus-
trialists. It should be apparent from this section that
we take great care to treat industrialists with respect
and to demonstrate that we understand their priorities,
while ensuring the provision of an academically rig-
orous programme of study.
2.2 Hardware and Tools
A key feature of the case study course is that the
hardware and software tools employed by the students
during practical sessions are equivalent to those used
by the industry. A further key feature is that the use of
these tools is focussed on education rather than train-
ing - ii.e. the students are taught why the tool is use-
ful and how it provides that utility, rather than a more
straightforward guide to how to use a particular tool.
The intention is that this approach results in gradu-
ates who can take on a new tool with confidence as
they understand what it is for, and how it relates to
the tools with which they are already familiar.
A simple example is the use of source control for
all practical work. Any commercial software devel-
oper employs a source control system, and there are
many professional packages available. From the first
day of our course we issue each student with a source
control account, and instruction on how and, more im-
portantly, why to use it. This focus on the benefits of
using source control, and the mechanism by which it
is achieved, ensures that the choice of which profes-
sional source control package to use during the mod-
ules is almost irrelevant. When entering industry, the
graduate will expect to use source control as part of
the daily programming routine, and will understand
and appreciate the reasons for doing so; the specifics
of the particular solution will then be picked up within
a few hours of use.
Combining the use of industry-standard tools with
discussion of why they are useful, and how they work
for the developer (rather than focussing on how the
developer interacts with the specific tool) extends to
all aspects of programming during our course. This
includes the hardware itself (in our case games con-
soles, high-end PCs, tablets and smart-phones), and
the development environment (compilers, debuggers,
SDKs, IDEs, etc). The intention is that, by educat-
ing the student about why a tool is useful, and how it
works, the resulting graduate will be much more com-
fortable moving onto new development environments
or hardware, due to a better understanding of what the
new technology is actually doing.
2.3 Collaboration Not Competition
Working within a commercial enterprise is a collabo-
rative process, often involving work with developers
elsewhere on the planet (?). In the authors’ experi-
ence, the majority of students regard coursework and
practical sessions as a competition with their class-
mates. In designing our case study M.Sc. course we
have encouraged a collaborative atmosphere through-
out. This applies to the nature and openness of the
discussion and tutorial sessions, and the layout of the
desks in the practical teaching environment (desks
should face each other, rather than face a wall, to
encourage student interaction). Each student has a
workstation within the lab, which is where the en-
tire day is spent, as would be the case in a com-
mercial software development organisation. Lectures
take place within this space (i.e. the teachers come
to the students, rather than the students go to each
lecturer’s theatre). Students are encouraged to carry
out all practical work in the lab, rather than taking
it home. This approach is intended to imbue the class
with a sense of belonging (i.e. it is their lab), and give
the environment the feeling of a shared workplace.
It is important to note that the collaborative ex-
perience is not limited to the aspects of the course
which include a team project. We encourage discus-
sion and problem solving between students during in-
dividual coursework and practical sessions. While
working within a commercial software development
enterprise, one of the main tools available to a soft-
ware engineer is the developer at the next desk: many
problems can be resolved by a brief discussion with a
colleague.
Team projects are a feature of most computer sci-
ence degree courses, and are regarded as a crucial
step toward becoming a fully-developed software en-
gineer (?). While working in the software indus-
try, the authors interviewed over one hundred grad-
uate programmers from many educational institutions
over a number of years. Almost without exception,
when questioned about a team project, the response
AdoptingCommerciallyInspiredPracticesWithinanAcademicTeachingCourse-ACaseStudyofaComputerGames
EngineeringDegree
97