While software refactoring is considered important to keep a software system maintainable and extensible, it is often neglected in practice due to several reasons. Besides the associated costs, software developers often perceive refactoring as a difficult and risky activity. However, apart from textbooks that document rules and best practices for identifying bad smells and applying appropriate refactoring techniques, learning and teaching refactoring poses multiple challenges. The application of these rules and techniques to code examples requires (advanced) skills in programming as well as an adequate handling of the programming environment. These circumstances can distract the focus and set barriers to the introduction of refactoring. In this paper, we present REFACTORY, a nondigital multi-player card game for learning principles of software refactoring without the development-related complexities. In our game, the players simulate a software-development team confronted with bad code smells. The players learn to combine refactoring techniques to remove the smells and to balance costs and value of refactoring. We specify the game design and illustrate the game workflow. In addition, experiences and lessons learned from a first game-play study are presented, e.g. regarding game fun and mediation of competences. Finally, we discuss limitations and further potential for improving the game.
Card game, software refactoring, serious game, game-based learning
Issues in software artifacts such as code, design or architecture
can cause technical debt (TD) which can negatively impact a
software system’s maintainability and evolvability [
For refactoring a certain kind of code smell, often different
options and paths are available [
Educational games aim at fostering practical competences
and motivation by providing a playful and interactive
environment [
In this paper, we present a non-digital card game called REFACTORY for learning principles of software refactoring. In particular, the objective of the game is (1) to motivate the players for learning more about software refactoring and (2) to mediate basic refactoring-related competences in terms of being able to conceptually combine refactoring techniques to remove bad code smells as well as reflecting the balancing of costs and benefits of applying software refactoring. The proposed learning environment supports active and game-based learning, especially suitable for novices that have little experience in software development. By focusing on the conceptual level and certain aspects of refactoring, development-related complexities are avoided and the entry barriers are low. The basic idea is to confront players in the role of software developers with a software system that is affected by several bad code smells (technical debt). In multiple sprints, the players then aim at increasing the system’s value by realizing functionalities. The players then have to decide whether to realize a functionality, which is more time expensive, when the corresponding component is affected by smells, or to remove subsystems assigned to players smell cards assigned to components first set of refactoring cards given to players sub1
S
F sub4
S round (sprint) the smells beforehand by applying refactoring techniques. In particular, this paper provides the following contributions.
We present design and workflow of an educational card game addressing basic competences in software refactoring, such as combining refactoring techniques to remove bad code smells and strategic aspects like balancing costs and benefits of performing refactoring activities.
We discuss user feedback in terms of the observations and results of a short game-play study based on a prototype of the card game.
Fig. 1 illustrates the game constellation of REFACTORY. A
game board represents a software system consisting of
multiple sub-systems (each comprising multiple software
components in turn), which are assigned to players at start (see 1 in
Figure 1). Goal of the game is basically to increase the value
of the given software system by realizing new functionalities
assigned every sprint [
The remainder of this paper is structured as follows. Section 2 discusses game approaches related to the proposed card game. In Section 3, our game REFACTORY is explained in detail, including the targeted objectives (e.g. competences and learning context), the game design (e.g. concepts and mechanics) as well as the workflow and variants of game play. Then, we report first user feedback in terms of the results of a small game-play study (see Section 4). Section 5 reflects the approach’s limitations and further potential. Section 6 concludes the paper.
In recent years, several (educational) games have been
proposed in the field of software engineering such as approaches
for game-based learning, serious gaming and gamification;
see e.g. [
For the sub-field of software refactoring, only very few
approaches of (educational) games can be identified. Based on
the systematic literature reviews [
In recent years, several card games have been proposed in the
field of software engineering; see e.g. [
In this section, we introduce our card game REFACTORY. In particular, we describe the game’s objectives, detail the game design in terms of the basic game concepts and game mechanics and, finally, describe the game-play workflow and exemplary game variants.
Objective of REFACTORY is (1) to motivate players for learning more about software refactoring and (2) to mediate basic competences, which are explained below.
The game aims to motivate players by providing a playful
simulation of the challenges in handling technical debt in software
systems expressed as concrete bad code smells. The aesthetic
aspects [
In addition to fostering motivation, the game also aims at
mediating principles in software refactoring, which can be
described in terms of target competences (a.k.a. learning
objectives). For specifying competences (especially in engineering
and computing), Bloom’s revised taxonomy of educational
objectives [
At first, the game addresses the application of a combination of refactoring techniques to remove certain smells, which can be classified as processing conceptual knowledge at the cognitive levels of application, analysis, and evaluation (i.e. II, 3/4/5, B).
Moreover, it also addresses applying and analyzing metacognitive knowledge aspects in terms of strategies for refactoring expressed as balancing the time/costs and benefits of performing refactoring (i.e. IV, 3/4, B).
The game can be seen as a complement to other learning and
training activities and environments (didactic mix), which are
discussed in the section on related work (see above). The game
can be described as a concepts-first approach to introducing
software refactoring. It addresses students or even
practitioners (related to software projects) that are, however, novices
in the field of software refactoring. In particular, the game
especially focuses on players without programming-related
experiences or that are more oriented to project management.
For example, the game could be used in the framework of a
university course on software design, maintenance or agile
development. Based on the addressed competences specified
above, a competence-oriented learning path can be described,
in which the game represents a starting point guiding.
Learners can be guided from there to higher levels of competence,
e.g. via tutoring systems [
The development of the game is oriented to a process model, which includes the use of a domain ontology for games in software refactoring. Fig. 2 depicts the model in terms of a UML activity diagram representing the key development steps, which are elaborated in the further Sections.
ad game development
Game Ontology User and Context Analysis
Competence Levels DOenstoiglongOyp-btaiosnesd Game
CUosemrspeatnednces [re-ideation necessary] GCaomep.OLnetvoelolsgy GaCmoemOp.nLtoelvoeglys
Game Ideation Selected DSeesilgencteOdptions
Design Options Game Mechanics
Game Dynamics Game Aesthetics
Analysis Tools
Design Options
Designing the Game
Game Design [re-implemen[traeti-oimnpnleecmeesnsa-ry] tation necessary]
Further details on the ontology-based analysis and design of
games and the included process model can be found in [
In the following, we give a conceptual overview of the game and explain the basic game mechanics and components.
Fig. 3 shows an overview of concepts applied in REFACTORY
in terms of a class diagram of the Unified Modeling Language
(UML2) [
The Game Play is based on a Game Board representing a software system consisting of multiple Sub-Systems (including multiple Software Components in turn; see Fig. 3. Each subsystem is assigned to a Player (in the role of a software developer). In a Game Play, multiple Players strive for increasing the Value of the software system. A game play consists of multiple Rounds representing agile sprints, during which functionalities are assigned to be realized, smells can be removed by applying refactoring and additionally events occur, which can impact each players’ value. These aspects are realized by the following four kinds of Cards (see Fig. 4). Event Card
* Card Deque * * uses
Game Play * 2..* based * involves on 1
Game Board (System)
0..1 Functionality Assignment *
a ected by Card
0..1 0..1 (DePvlaeyloeprer) 1 1 Score Sheet
* * Sub-System related to 1 Round (Sprint) *
assigned 0..1 to * Component 0..1
* *
Turn *
Move
God Class Feature Envy
removes Smel Card * * RefaCcatordring *
Move Method Extract Method *
applies todo* Functionality
Card * * done
* * * Time Points * * Value Points *
Points consumes * Functionality Realization
Smel Removal (front)
(back) FeatureEnvyrOetfiaocntsorfoinrg: A method accesses data of another class more than its own data (front) (front)
(front) MoveMethod Code Review
Functionality Move a method to a class that uses it mostly.
in the next
round
Reduce the value
of the player with
most smells by
10 points
e ort: 2
value: 3
(a) (b) (c) (d)
Figure 4. Exemplary cards of (a) bad smells, (b) refactoring techniques,
(c) events, and (d) functionalities.
(c) Event Card: representing events that impact the
software project and the strategies of balancing the removement
of bad smells and realizing functionalities (see (d) in Fig.
4). In particular, the following four kinds of events are
distinguished:
– Code Review: representing a review of the code
quality with the consequences of reducing the value points
of the player with the most smells.
(a) Smell Card: representing a bad code smell that
negatively impacts the maintainability and extensibility of the
affected software component (see e.g. [
- MoveMethod or - EctractMethod e ort: 1 – Feature Check: representing a check of the current state of functionality realization from the customer (or product owner) with the consequence of reducing value points of the players with the most functionalities todo (i.e. not yet realized). – Time Check: representing a check of the time not used by the players with the consequence of reducing the value points of the player with the most available (i.e. unused) time points. – Training Session: representing a session dedicated to training techniques for software refactoring resulting in additional refactoring cards drawn by the players. The training can be applied to all players or just the player who draws the card.
The events take place immediately or in a future round, as noted on the front of the card (see (c) in Fig. 4). (d) Functionality Card: representing a certain functionality of the software system. The details of the functionality are hided in the game, i.e. that only the effort (in terms of time points) to realize the functionality (todo) and the value (also in terms of points) of the functionality (in case it has been realized; see below) are noted on the front of the card (see (d) in Fig. 4).
In every Round, Time points are given to each player, in terms that they are noted into a player’s Score Sheet. The sheet also gives an overview of the player’s functionalities todo (for which the target components are noted) and done as well as the achieved Value (as the sum of functionalities done). Moreover, a set of new Functionality Cards (todo; taken from the product backlog) are drawn from the card deck and assigned to the players’ components by dicing. Each round, one player (rotating) also selects an Event Card that impacts all players or only the acting player (see above). Per round, each player then moves in turn. At first, she draws new Refactoring Cards. Functionality and Refactoring Cards are then taken in player’s hand. Each player then basically can decide how to invest the Time points for performing the following two kinds of Moves.
Functionality Realiziation represents a player’s move to realize a functionality, which is at the player’s hand (todo; previously drawn). By realizing a functionality, the player’s time points are reduced by the corresponding effort points and in turn the player’s value points are increased by the functionalities’ value (in the score sheet). The functionality card is then placed at the corresponding component on the game board. In case a component is affected by a bad smell, the costs of realizing the functionality are doubled. While realizing a functionality, new smells can be introduced potentially (by dicing a certain number). For this purpose, then the corresponding cards are drawn from the card deck and located at the corresponding component. Smell Removal represents the combination of refactoring techniques to remove a certain bad smell located at a player’s component. For this purpose, (1) the effort points of the refactorings must be available (and are consumed) and (2) the combination must be appropriate for removing the smell (see Table 1).
Further details on game play are explained in the following Section.
Table 1 presents exemplary applied mappings between bad
code smells and corresponding refactoring techniques, i.e.
options and combinations to remove the smells. The mappings
are based on the documented knowledge provided by [
Based on the game design explained above, game-play aspects such as how to prepare a game session as well as scenarios and variants of game play are described below.
For playing the game, a game board, score sheets and game cards 1 as well as a traditional dice (i.e. faces one to six) and a pen (to fill the score sheet) are required. Before game play, the subsystems (with included components) have to be assigned to players. Moreover, for each subsystem, smell cards are allocated to components by random (diced) and each player also receives a starter set of refactoring cards (see 1 in Fig.1).
As shown above, the game provides strategic challenges, demands for applying conceptual knowledge and contains a certain degree of chance (e.g. dicing). In the following, exemplary game-play aspects are detailed in terms of scenarios. For instance, for managing the technical debt items (concretely expressed as bad smells) located in their sub-systems, the players can select between different strategies that are very close to the options actually used in refactoring practice.
At first, a player can realize a functionality in a smelly
component by ignoring the bad smell, which can be motivated by
different reasons, such as inexperience or unawareness on
the one hand, or driven by the assumption that this
component won’t be often modified. However, every modification
of a smelly components can become quite cost expensive
(cf. technical-debt interest [
A second option for the player is to remove the smells just
before realizing funtionalities, which is referred as ad-hoc
or floss refactoring [
The third option is to remove (all) smells in anticipation, even if no concrete extension by functionalities is planned.
In this strategy, the player/developer runs the risk to prevent 1The materials of the card-game prototype (e.g. game board, score sheet, game cards) are available for download from http: //refactoringgames.com/cardgame/. issues in terms of debt interest that will never accrue, since the affected components will eventually never be touched by developer.
The game design and game constellation specified above allow for describing multiple game variants, which differ regarding the user interaction and at the level of detail in the rules of the game. Three exemplary variants are shortly described below. (A) Competing Players: The players compete against each other in collecting value points. Each player is only responsible for their subsystems. This variant represents the base for the following two game variants. (B) Competing Groups: In this variant, multiple groups compete against each other. In contrast to (A), the members of a group support each other in several regards, such as for combining refactoring cards or realizing functionalities of each other. (C) Collaborating Players: The third variant describes a team of all participating players that aims at optimizing the value of the software system. In this, the players can support each other in exchanging refactoring cards and balancing the players’ time for realizing the assigned features. A possible reference for comparing the team’s value could be the value achieved in previous sessions (when applying other strategies) or achieved by other teams.
We investigated user feedback on the game via a two-stage process (1) by performing a pilot to identify obvious issues and to refine the game and (2) via a user study with 19 participants, which are both explained in the following.
In order to test the game functionality of and gain first feedback on game play, we conducted a short pilot with three software developers playing a first version of the game. We observed the game play and discussed the experiences with the players afterwards. The players gave generally positive feedback and confirmed simplicity as key for learning principles in software refactoring. In addition, a few suggestions to improve the game have been collected, such as adding more elements of chance to increase game fun and to improve the game theme to increase the acceptance, especially by a younger audience.
Based on improvements of the game design (such as introducing event cards; see above), we conducted an additional small user study with 19 voluntary participants, consisting of 7 software developers and 12 students of the Information Systems bachelor studies, of which 8 indicated to have at least some experiences in software engineering, while 4 had little/none; all with low to medium knowledge in software refactoring. The players were instructed into the gaming rules before game play. Game sessions (of each 8 rounds) have been performed in five groups, each consisting of 3 to 4 players, which took about 20 to 40 minutes to complete. Every group has explored two game variants, i.e. at first (A) competing players and then one of the group-oriented variants (B by two groups, C by three groups). After that, the participants have been asked to specify the level of agreement to 8 given statements (see Table 2) via Likert scales (1=no to 6=full agreement), which can be structured by the following 3 blocks. (1) general impressions of the game, (2) fun and motivation of game play (first objective), and (3) the game as mediator of competences (second objective)
Fig. 5 shows the results on statements regarding the general impression of the game. Almost all participants (i.e. 16) agreed to the statement that the game supports in learning principles in software refactoring (1.1). In addition, most (63%) indicated that playing the game helps better understanding the value of refactoring (1.2). Interestingly, many participants (i.e. 13) have experienced problems in following the game rules (1.3), which can be induced by the explanation of the rules or by the complexity of the rules themselves (also see the discussion in the following section).
1 2 4 5
6 3 4 6 6
3 7 3 8 3 2 2 1.3 1.2 1.1 0
Fig. 6 reports on the answers to statements regarding fun and motivation in playing the game (first objective). In general, 63% of the participants indicated that playing the game is fun (2.1). The statement that the game motivates to learn more about software refactoring (2.2) finds overall weak support. Moreover, almost all participants stated that the group-oriented variants (i.e. competing groups and collaborating players) were more fun to play (2.3). 3.2
2 3.1 1 2 3 4 6 8 10 12 14 16 18 20 22
Fig. 7 depicts the results on statements regarding competence acquisition (second objective). Most participants (i.e. 79%) indicate that the game can support acquiring competences for software refactoring. In detail, most participants agreed on the statement that the game supports improving the knowledge on how to combine refactoring techniques to remove bad smells (3.1). Moreover, almost all participants (i.e. 15 out of 19) agreed that by playing the game they reflected on balancing costs and benefits of refactoring (3.2).
5 7 0 2 4 6 8 10 12 14 16 18 20 22
In addition to these closed questions, the participants were also asked for potential game improvements, which mainly dispersed over the game’s appearance/theme and the gameplay rules. Some participants have indicated that the game could be visually and haptically more appealing and that the theme of the game needs to be revised. Moreover, some noticed that the game is a bit too complicated and –correlating to this– that the manual should be revised. Among other aspects, these points are discussed in the following section.
The short game-play study indicates that the developed card
game supports in acquiring basic competences for software
refactoring and also motivates the participants to deal with
software refactoring. In the following we reflect on limitations
regarding the user study and the game approach as well as
on potential for further improvement. At first, the study is
5 1
2
6
4
3
based on a small and heterogeneous target group consisting
of developers and IT students differing in terms of knowledge
and experience, who can be seen as typical card-game
players. However, a potential threat to the internal validity can
be seen in the kind of questions asked to the participants in
the sense that the intention behind the study is transparent to
the participants, i.e. they can probably recognize that their
agreement with the approach presented is desired. Thus, the
participants can be seen as biased to some extent. To overcome
these limitations, further experimentation and refinement is
required, which is planned in future research. In particular, it
is intended to perform further user studies with more
participants in the framework of university courses and by measuring
the competence acquisition via exemplary tasks that relate to
competence levels [
In general, the proposed card game focuses on certain conceptual competences (see above), which can be seen as a starting point to learning software refactoring. For the player, this means that it remains to be explored, for example, how to actually perform an EXTRACTCLASS by performing code modifications (in a larger code base). However, we believe that the card game can also foster other skills, such as problemsolving, team work, or communication (e.g. resulting from face-to-face interaction and immediate social feedback), which could be investigated in further research.
The realized non-digital card game was motivated by the
benefits of lower entry barriers and the potential to focus on
selected conceptual aspects of software refactoring. However,
the proposed game design could also be realized as a digital
game, which would come with some advantages, such as an
automated assessment and game processing. In addition, there
is certainly a lot of potential in improving the visual
appearance of the game, which could correlate with a refinement
of the game mission. For instance, within a battle narrative,
the bad smells could by represented as enemies that can be
beaten by deftly applying refactoring weapons. Building upon
this, the cards could be visually improved, e.g. oriented to the
popular fantasy card game Magic: The Gathering [
In this paper, we have introduced REFACTORY, a non-digital
card game for teaching basic concepts in software
refactoring. The short user study indicated that the card game can (1)
motivate for learning more about software refactoring and (2)
support learning refactoring principles (i.e. combining
refactoring techniques to remove bad smells and of applying and
reflecting strategies for balancing costs and benefits). For
future work, we intend to apply the game within university
courses and to perform further user studies. In order to
improve the user experience, we also plan to revise the game
layout (as discussed above). Another possible direction could
be to transform the presented non-digital into a digital game,
by which the assessment of actual code modifications could be
included (integrated editor) and which would also allow a
combination and integration with other training/gaming activities
and environments (see e.g. [
This work was partly funded by the Department for Economic Affairs, Labour and Statistics (MA23) of the City of Vienna (Austria) through the research project "New Work – New Business" at the UAS BFI Vienna.