System Design Project (SDP)
Response to 2016/17 survey feedback for SDP.
Summary of key issues
While some students recommend the course, considering it challenging but ultimately rewarding, others recommend against (noting that for many students it is compulsory). The main reasons given against are i) the workload or amount of time it consumes ii) stress induced by the workload and dealing with team mates (though again several mention that learning to deal with both was a positive outcome of the course) iii) that the robotics-oriented task was not of interest to them.
Regarding improvements, we note that some of the comments are purely technical or relate to very detailed issues about the marking or robot match scoring or the provided codebases. As the task will be changed in the coming year we do not address these further. The main substantive issues discussed are i) group vs. individual marking ii) the format of the course (e.g. lack of lectures, inclusion of sprint week, amount of support available) iii) perceived lack of responsiveness to problems raised.
Several students have expressed concern about the workload of SDP. We recognize that one issue is that by its competitive nature it was difficult for groups to assess when they had done enough. This could lead to groups spending excessive amounts of time on SDP. In this years course we have taken away the competitive element, as each group will (with guidance) set their own goals, and they will be judged with respect to those goals. This does mean that the sporting element has been removed from the project --- no football or basketball or hockey this year. We will also provide additional guidance on time management and project management, with focus at the start of course on creating a detailed and realistic plan that takes account of the resources available (i.e. 200 hours work over the semester) from each team member.
We hope this will also help to reduce stress induced by either self-imposed workload or problems with the team dynamic. At the same time we note that the learning objectives of this course concern project planning and monitoring, and working in teams; which we believe can most effectively be learnt through direct experience with a challenging team task, not abstract lectures or strong external guidance by course staff. Nevertheless we plan to provide some additional class meetings to complement the video lectures and other linked support material.
Regarding learning objectives, we re-emphasise (as was done throughout the course) that SDP is not a robotics course. A robot-based task is chosen because it is large and complex enough to pose challenges in project planning and team work, including the kind of unpredictable problems that arise in dealing with a system that has to operate in the real world, while still having a variety of elements (e.g. software and interface design, efficient coding, communications, etc.) that should enable students with a variety of interests to engage. The ability to deliver such a combined project requires a range of skills in project planning that are highly valued by industry, and the industrial representatives who attended the final day (from companies such as Amazon, Google, Skyscanner, KAL, Freeagent, etc) were hugely enthusiastic about the course and impressed by what the students had achieved. Similarly, we note, many of the students valued this experience.
Given that working as a team is a learning outcome for the course it is natural that assessment is focused on the team or group. However, we are conscious that some students will contribute exceptionally, whilst others will fail to fully participate. This is why there is a mechanism that allows some adjustment for these cases, but we made a deliberate decision not to use a scheme by which team members would feel they were competing with each other to claim individual credit, but rather would see their best strategy would be to work together to improve the team mark. We also believe it is a fallacy for students to be completely oriented towards maximizing their individual mark as the only important outcome of their education. Unfortunately very few students took up the opportunity we offered to participate in a guided session on how their SDP experience could be used in their CV or job interviews; we hope that this can be more successfully run in the coming year.
The course organizers are passionate about this course (both volunteered to take it on) and keen that it runs as smoothly as possible. We made a major effort this year to streamline the task requirements and be transparent about what was involved from the outset; and also to align the assessment more closely with the learning objectives. We also gathered a mid-term feedback survey, gave immediate feedback to the entire cohort and met with student representatives to explain what was being done to resolve issues that had been raised, so do not think it fair to suggest we flippantly shrugged off the concerns of students. Finally, we note some of the comments are simply untrue. For example the criteria for the marking of reports were available from the beginning of the course, and reports were marked by the course organisers, not unqualified undergrads or postgrads; the plan to have a sprint week was announced at the start of semester and was clearly listed in the timetable on the website before the course commenced (and had been officially approved by teaching committee as an appropriate use for this week for year 3 students, however, we have decided not to repeat it this year); and changes in task requirements was an extremely rare occurrence, especially in comparison to previous years, and only made in direct response to student requests for clarification.
Jane Hillston and Barbara Webb, September 2017