How can we increase the business perspective in software engineering courses? How can we balance the workload in project-based courses? This paper presents how we successfully teach market-driven software engineering with Robocode. We also found that a few mandatory lab sessions didn’t help weaker programmers to contribute more in the projects. The entire course is available on GitHub.

I have been involved in teaching an introductory software engineering course since 2010. Since 2015 I’m the course coordinator. The project component of the course has evolved for a very long time. Initially, the project was all about writing project documentation (boring). Later, it involved waterfall development of a bicycle garage management system (including code, but not very fun). When I took over the course, I removed the waterfall by reorganizing the development tasks in three iterations (but still a boring task). Since 2018, the development task is to develop a Robocode robot and convince other student groups to buy it (fun).

The goal of Robocode is to implement the behavior of a robot to compete against other robots in a battle arena. The contestants have no direct influence on the game, instead they write the AI of the robot telling it how to behave and react on events occurring in the battle arena. Robocode has been used in software engineering education before, but the market-driven setting we use is novel.

Challenges with project-based courses

Everyone agrees that software engineering education needs project courses with group work. Project-based learning in group settings combines “knowing” and “doing” as students together solve problems. At the same time, students practice “soft skills” such as leadership, communication, and planning.

However, designing good project tasks is not trivial. Poorly designed project assignments limit the potential for learning and increase the risk of student conflicts. With poor tasks, unfair work allocation follows, e.g., freeriding, social loafing, and domineering students. Students often have a very different motivation, i.e., different levels of ambition and commitment to the project tasks. In my course, the student cohort consists of an equal number of ICT engineering students and engineering management students. This makes things both interesting and complicated!

To motivate students with different interests, I redesigned the project assignment to include gamification elements related to both engineering and business. By designing a project task in a market-driven context, the course responds to calls for increased emphasis on business in software engineering education. And more importantly, making video pitches and marketing a product to others is fun. It also increases the stakes. Students tend to care more about “their” product and commit more to the development activities.

A market-driven SE course with Robocode

The course corresponds to 6 ECTS credits, i.e., 4 weeks of full-time study. Apart from the project task, the course consists of 7 lectures, 4 classroom exercise sessions, and 4 computer lab sessions. Each project group consists of six students with dedicated roles. All students are developers and testers, but also get one additional role: project manager, requirements engineer, software architect, quality engineer, configuration manager, or sales engineer.

Each group develops a robot using established software engineering practices. Furthermore, each group will compose a robot team to compete in a “LU Rumble” at the final lecture in the course. However, no project group is allowed to field their own robot at the LU Rumble – instead robots developed by other groups must be purchased on an open market. Consequently, each project group has two primary goals: 1) maximizing profit by selling a successfully engineered robot on the market and 2) winning the LU Rumble by composing a competitive Robocode team.

The development follows an iterative process with in three 2-week sprints with fixed deliverables. Each sprint ends with an executable robot that can be delivered to a customer group. We discuss specification, construction, and verification as the main activities and stress that all sprints contain a mix of these activities.

Why don’t we rely on an agile development method? Doesn’t everyone do agile nowadays? The primary reasons are a lack of teaching resources and the challenge to schedule sessions for two different engineering programs. To properly teach agile methods, there is a need for considerable teacher presence during the software development and management – this is costly and hard to schedule for diverse student cohorts. Instead, we supervise student development closely during lab sessions and particularly recommend a set of agile practices that we find valuable in our educational context: pair programming, continuous integration, code refactoring, test-driven development, and collective code ownership.

Mandatory labs didn’t balance the workload

The first edition of the course in 2018 was successful, the students enjoyed the setup and I’m sure they learnt a lot. However, there was still the issue of greatly different effort in the projects. We hypothesized that the main problem was that some student were way more mature developers and thus weaker students didn’t really get the chance to contribute. In an attempt to remedy this, we made all four programming sessions mandatory for all students. They used to be optional, but now our idea was to make sure all students could learn the basic development skills needed to contribute properly.

I decided to make a controlled experiment. I decided to fix as many parameters as I could and just make labs mandatory. This I refer to as the intervention. I used identical measurements in 2018 and 2019:

• All students reported time spent on a weekly basis (in hours)
• An intermediate course evaluation with ratings and free text answers.
• A retrospective analysis as a question in the final exam.
• The Lund University formal course evaluation.

Did it work? Did mandatory labs help the students to balance the work load? Unfortunately not. The quantitative time reports and the free-text answers both reveal that the intervention wasn’t successful. The figure below shows the distribution of total hours spent on the project before and after the intervention – there is barely any difference.

We found that the intervention was very well received among mature students, but not popular with students weak at programming. While the goal was to help novices learn fundamental development skills to enable more collaboration on the source code level, we instead found that weak programmers now struggled with the lab assignments and instead had even less time to contribute to the projects. Now they just struggled to survive the labs! Bummer.

Implications for teaching

• Market-driven contexts are useful to add gamification elements in teaching.
• More than mandatory labs are needed to balance the programming workload among differently skilled students.
• Design engineering programs in a way that software engineering courses follow after students have reached a minimum level of programming maturity.

Markus Borg. Making Programming Lab Sessions Mandatory - On Student Work Distribution in a Gamified Project Course on Market-Driven Software Engineering, In Proc. of the 32nd International Conference on Software Engineering Education and Training (CSEE&T), 2020. (preprint, code)

Abstract

Unfair work distribution in student teams is a common issue in project-based learning. One contributing factor is that students are differently skilled developers. In a course with group work intertwining engineering and business aspects, we designed an intervention to help novice programmers, i.e., we introduced mandatory programming lab sessions. However, the intervention did not affect the work distribution, showing that more is needed to balance the workload. Contrary to our goal, the intervention was very well received among experienced students, but unpopular with students weak at programming.