-Collaborative learning activities have become a common practice in current university studies due to the implantation of the EHEA. But the COVID-19 pandemic has led to a radical and abrupt change in the teaching-learning model used in most universities, based on a face-to-face model. A rapid and unexpected adaptation to a new model of nonpresential teaching has been required, which has been able to be implemented, even in an improvised manner, thanks to the effort of teachers and students. Given this new scenario, our interest is mainly focused on discovering to what extent our students of the Computer Engineering Degree have approached the group programming tasks, which they must perform in a large number of subjects. For this purpose, we have carried out an experience aimed at finding the strategies and software tools they have used to address these tasks. The results of the study indicate that students have adopted a programming model based on work division or distributed peer programming, and very few have chosen to make use of synchronous distributed collaboration tools.
Keywords— Group programming, Peer Programming, groupware, COVID-19
The implantation of the European Higher Education Area
(EHEA) has led to group activities becoming a common
practice for university students [
Pair Programming is the term used to describe the process
followed by two programmers working in the same computer,
performing a particular programming task or the design of an
algorithm. In this scenario two roles are defined: the driver,
who controls the programming activity and is responsible for
writing the source code; and the observer, who gives
indications to his/her partner about the development being
carried out, the existence of possible syntax errors, etc. Both
roles can be exchanged, alternating the control each team
member during the programming activity. Several studies
have proved that the use of the PP technique improves the
process of solving programming problems, the productivity of
the team, and the quality of the programs generated [
Pair Programming also requires working face-to-face in
the same location. When it is carried out in a distributed
environment, it is called Distributed Pair Programming
(DPP) [
In the second half of March 2020, the confinement due to
the COVID-19 pandemic forced a shift from a face-to-face to
an online education model from just one day to the next [
Within this process of improvised and rapid adaptation, the UCLM decided to maintain the usual platform of online communication with students (Moodle1) and the institutional shared information repository (MS OneDrive2), as well as to provide the university community with video conferencing applications (MS Teams3), and video creation and playback (MS Stream4). The combination of these tools allowed to solve the problems of teacher-student communication in a more or less satisfactory way. However, as teachers of the GII, and in view that online teaching has come to stay (to a greater or lesser extent), our interest is focused on knowing how the student-student communication was approached in the context of group programming tasks, which our students have had to perform in most of the subjects. It is clear that, in the context of the imposed confinement, students at all universities had to make use of new strategies and work tools to move from a traditional PP-based model to a DPP or CP approach.
Therefore, this article describes the research experience carried out at the Escuela Superior de Informática de Ciudad Real (ESI-CR) of the UCLM, which aims to know the mechanisms, tools and difficulties of the students of the GII, 1 https://moodle.org/?lang=es 2 https://www.microsoft.com/es-es/microsoft-365/onedrive/onlinecloud-storage 3 https://www.microsoft.com/es-es/microsoft-365/microsoftteams/group-chat-software 4 https://www.microsoft.com/es-es/microsoft-365/microsoft-stream as well as their subjective perception, to address the group programming tasks they performed during the state of alarm, in the period between March and May 2020. Section 2 describes the details of the experience carried out (questionnaire designed, results and discussion); and section 3 comments on the conclusions drawn from this work and the work to be undertaken in the future.
In an effort to find out how the students of the GII of the ESI-CR carried out their group programming tasks during the decreed state of alarm between March and May in Spain, an experience was carried out with the voluntary and anonymous participation of a total of 112 students (14 in the first year, 49 in the second year, 35 in the third year and 14 in the fourth year). The experience took place during the first half of June and consisted of collecting information of interest by means of a questionnaire, displayed through the MS Forms5 tool, and described below.
Given the objective of this research, a questionnaire was designed to find out the following aspects: Need for group programming activities in a distributed way. This item asked whether they had to perform group programming activities during the confinement period. Size of the programming groups. Although in most cases the groups consisted of two members, it was asked whether the groups were made up of two, three or more members.
How they have approached group programming tasks. This item inquired about the solution adopted to perform group programming tasks when the members of the work team could not meet face-to-face. Several answer options were provided (Table I), and several of them could be selected. In the case of choosing one of the last four options, an additional question was enabled to indicate which tool/s they had used. Note that option (d) is the one that best aligns with the PP approach, but in a distributed (online) format: the videoconferencing tool allows sharing the development environment (IDE 6 ) (for instance, Eclipse 7 ) so that the members of the couple can alternatively take turns to adopt the roles of driver and observer. On the other hand, option (e) refers to the use of a groupware programming environment, which would allow the application of a CP approach. Subjective perception about different strategies for group programming. This aspect was integrated by three items in which three possible strategies for group programming were presented (Table II). Each of the possible response options was ranked by means of a 5level Likert scale, which allowed to indicate the degree of agreement (value closest to 5) or disagreement (value closest to 1) with each one. I have chosen not to do group practice. I have chosen or changed (if the subject allowed it) to the modality of individual work We have distributed the practical work of different subjects so that each member of the group can work individually on each one of them, and not have the need to work together on the same project/program We have used version control systems (e.g., Git, GitHub, ...) to work on the same programming project, but asynchronously (not both at the same time on the same project/file) We have made use of video conferencing tools (e.g. MS Teams or similar), sharing the screen or the IDE We have made use of a synchronous collaborative software development environment We have made combined use of some of the above options
Statement I believe that it is better to divide the work when it is necessary to program in group in the same practical project, i.e., that each group member works in an independent way in a certain component (ex. package, file, class, ...) and, then, the contribution of each one is integrated to the final result I think that group programming is best done in an asynchronous way (each member of the group working on the same code/project, but at different times), taking turns not to "step on" the work I think that group programming is best done in a synchronous way (both partners working at the same time on the same code), using additional channels of chat, video or audio to get organized and make decisions together
The first scenario proposes the division of work and the progress in programming autonomously, in different sections of the final program or project. In other words, a cooperation strategy was presented, in which it is possible to work in a synchronous or asynchronous way, but in different parts of the code. The second one suggests working on the same code but in different moments of time, that is, it describes a collaboration scenario, based on the assignment of shifts and, therefore, asynchronous. The last scenario corresponds to a purely collaborative and synchronous group work.
Need for tools to support distributed and synchronous group programming. This section asked about the need for tools to support collaborative synchronous work, which matches the last scenario described in the previous question.
Features and functionalities needed to support synchronous distributed programming activities. Based on a hypothetical scenario of synchronous distributed programming, a series of features and functionalities that could be considered desirable, and
even necessary, for effective and efficient group programming are presented. total) answered positively. Most of these students belonged to 2nd and 3rd year (Figure 1).
Participants were asked to rate the usefulness/need for
each of these features or functions on a scale of 1 to 5,
with the lower end of the scale (1) representing that it
would not be necessary or useful at all, and the upper
end (5) indicating that it would be very necessary or
very useful. Table III shows the list of features, which
includes the main communication tool (text-chat,
audio and video), coordination and access control to
the shared workspace (blocking of code sections,
version control) mechanisms, as well as aspects related
to awareness (connected users and visual highlighting
of access to the shared area) [
Finally, an item in which students could indicate any feature or functionality not listed that they considered necessary or useful was included.
The preprocessing of the data provided by the participants in the questionnaire reduced the sample size to N=111. The subsequent analysis of the responses provided yielded very interesting results, which are described below.
Regarding the need to perform group programming tasks during the confinement, 98 of the 111 students (88% of the
As for the size of the groups in which they participated, 52 of the 98 students indicated that they programmed in pairs, 16 in groups of three and 13 in groups of more than three. Another 17 indicated that they were part of several groups of different sizes.
The solutions adopted to deal with group programming (Table I) consisted, mostly, in the combination of various strategies, highlighting the use of some videoconferencing system (being MS Teams and Discord 8 the most cited) together with an asynchronous version control system (GitHub9 was the most outstanding). Figure 2 also shows the percentage of students who chose to use only one tool.
Among those who combined several strategies, five participants from the third and fourth year indicated that they used a synchronous collaborative development environment.
Table IV shows the main descriptive statistics (mean, median and mode) of the answers related to the participants' subjective perception about the convenience of applying the three group programming scenarios described in the previous section (cooperation, asynchronous collaboration and synchronous collaboration) (Table II), the need to have tools to support the last of these three scenarios, in a distributed context (synchronous distributed collaborative programming), and, finally, the functionalities and features they considered most necessary or useful in a tool to support this programming strategy (Table III).
As far as the different strategies proposed (Figure 3), the best evaluated was synchronous collaborative programming (µ=4.00), while asynchronous collaboration modality was the worst valued (µ=2.74). Most of the students considered that having tools to support synchronous distributed programming scenarios should be necessary (µ=4.00). The features they considered most useful for the software supporting this programming strategy (Figure 4) were that the collaborative functionalities should be integrated in a known IDE (e.g. Eclipse) (µ=4.05), and that both version control support (µ=4.29) and the recording of individual contributions made by each team member to the final result should be included (µ=4.23). With respect the communication mechanisms that should be incorporated, the best rated was audio (µ=4.21), followed by chat (µ=4.07), with the video signal being the one they considered the least useful (µ=3.26). adopted, in which only 30 out of 98 students have selected the use of version control tools (GitHub, for the majority), among which there are no first-year students and 68% are third year students.
The results obtained show that, despite the fact that
students positively valued synchronous distributed
programming (CP), they have opted, as a first option, for a PP
(driver-observer roles) programming model, but in an online
mode (DPP) during the confinement period. Most of them
have made use of MS Teams or Discord, sharing the
development IDE (Eclipse for Java; MS Visual Studio10 for
Visual Basic, RStudio11 for R and Visual Studio Code12 for C
and ADA) and changing turns alternatively to code. In the
same way that teachers have opted to transfer the face-to-face
magisterial class model to online support, in what has been
referred as remote emergency teaching [
Among the desirable features included in a software for group programming, at the same time and in a distributed way, they considered that having an audio channel can be very useful and, possibly, the most agile method to communicate. The video signal is not considered as very necessary, being in many cases rather a source of distraction, while textual communication through a chat, that they are very used to, is also well valued.
Version control and the possibility of recovering previous
states of the practical projects were highly appreciated by
students, for their obvious usefulness [
On the other hand, those who best value version control tools also consider it necessary to record the individual contributions of each team member to the final result. This feature, in order to evaluate and justify the personal involvement in the deliveries, is very useful for both teachers and students.
The incorporation of awareness mechanisms was considered very necessary (µ=4.36), although the possibility of having visible information about the users connected or their availability at any given time (µ=3.88) was considered not very useful.
Finally, we analysed whether the assessment of each of these features depends on some factors, such as the course in which the student was enrolled or the size of the groups in which they had worked. The ANOVA of the data reflected significant differences at 95% (p-value=0.003) only in the version control tool when considering the student's course as a factor. The subsequent post-hoc revealed that these differences occur between students of the 1st and 2nd courses with respect to those of the 3rd and 4th courses. These results are in line with the data reflected in the section on the solutions 10 https://visualstudio.microsoft.com/es/vs/ 11 https://rstudio.com/ 12 https://code.visualstudio.com/ 13 https://colab.research.google.com/notebooks/intro.ipynb 14 https://visualstudio.microsoft.com/es/services/live-share/ 15 https://atom.io/
In our research group (CHICO 16) the support of group
programming has been, for years, a topic of interest [
In this article we have described an experience conducted with more than a hundred students of the Computer Engineering Degree of the ESI-CR of the UCLM, whose objective was to know how they had approached the practical tasks of group programming during the state of alarm decreed in the second quarter of the 2019-2020 academic year.
The results obtained show that, although the students considered interesting the use of synchronous collaborative programming tools, that is, to apply a CP approach, they mostly opted for a DPP model (in which they share the IDE with their colleagues, making use of videoconferencing applications). The division of programming tasks in different parts of the program or project was the second most used option. Possibly the lack of knowledge of support tools for distributed synchronous programming influenced the choice of these strategies.
Our research group has developed several environments that implement the three programming approaches (PP, DPP and CP). Outstanding among these systems is COLLECE 2.0, which we plan to introduce in several programming subjects during the next academic year. This system incorporates many of the features considered most useful by the participants in this study (it is integrated a widely used IDE, such as Eclipse, incorporates a version control system, blocking of code regions, a very rich set of awareness mechanisms, ...). Even so, some of the features that have also been positively valued by the students could be added to this system, such as the incorporation of an audio channel between the team members. Similarly, we plan to continue studying the tools that support CP through a systematic literature review, which allows us to know the state of current research in this field.
This work has been funded by the Ministry of Economy, Industry and Competitiveness and by the European Regional Development Fund, with reference TIN2015-66731-C2-2-R.
The authors would also like to express their gratitude to the students who volunteered to participate in this experience. 16 https://blog.uclm.es/grupochico/ 17 http://blog.uclm.es/grupochico/proyecto-iapro/collece-2-0/