The motivation behind the work lies in a persistent gap between what software engineering courses teach and what the software industry actually needs. The researchers note that professors often adhere closely to traditional expository lectures and tests, leaving students unmotivated in a subject whose learning is achieved primarily through applying content to practical projects. Citing earlier work, the authors point out that a newly graduated individual typically needs between two and three years to gain professional experience in software engineering, and that companies frequently have to supplement graduates’ knowledge to promote both technical and non-technical skills. Software’s intangible and malleable nature compounds the problem, because students who can apply theory to classroom exercises still need more experience when faced with real projects and ambiguous specifications.

ConES, whose name derives from the Portuguese terms for Construction and Software Engineering, is a role-playing game built around building blocks and inspired by established systems such as GURPS and Dungeons & Dragons. Players are placed in a team hired by a king to rebuild a castle, and each participant assumes a role that mirrors a position in a real software project. The game master plays the Customer, who knows the business rules and validates deliveries, and the Manager, who removes obstacles for the team. Players choose between the Architect, who designs structures in the LeoCAD modeling tool; the Builders, who implement the design with physical blocks; and the Tester, who monitors construction and fills out a compliance checklist comparing what was built against what was requested.

The game’s mechanics translate software engineering practices into explicit, auditable rules. Each player fills out a character sheet distributing attribute points across three categories: soft skills, hard skills, and scope mastery. Action cards, usable once per turn and tied to specific roles, grant benefits if the player passes a skill test, a dice roll in which the action succeeds when the result is less than or equal to the sum of the attributes involved. Demand cards carry the Customer’s requirements together with acceptance criteria, while event cards represent random requirement changes that force teams to adjust mid-turn. A Customer Requested Changes Sheet tracks corrections across rounds. The researchers mapped the game’s rules to the Software Engineering Body of Knowledge, so that demand cards operationalize requirements engineering, LeoCAD models simulate architectural decisions, the compliance checklist operationalizes verification, and physical construction operationalizes implementation.

A full match unfolds across five phases: Introduction and Character Creation, Turn Planning, Turn Execution, Demand Delivery, and Retrospective. In the Retrospective phase, players gain an experience point and reflect on difficulties and strategies for future turns, a structure the authors link to Kolb’s Experiential Learning Cycle. Before the classroom application, the game went through a systematic literature mapping and the validation of two prototypes. For the case study itself, the Player’s Manual was distributed a week in advance through Google Classroom, and the session was planned under the guidance of two software engineering professors, with a game researcher conducting the play.

The classroom session began an hour late because not enough students had arrived at the scheduled start time, a delay the authors acknowledge may have negatively affected the study by forcing an early finish. Once underway, the 20 students were divided into four teams of five, each with one Architect, three Builders, and one Tester. The narrative placed them at Medieval Solutions, an organization hired by a king whose castle had been attacked by orcs. The first demand was a wall, built under a 10-minute timer, and none of the teams met all the requirements on their first attempt, which the professors had anticipated given the players’ inexperience. By the second round, involving a moat, teams began using action cards effectively: one Builder from Team A passed a skill test to access four additional blocks, and Team B’s Tester passed a test allowing him to assist a Builder.

The third and fourth rounds introduced event cards and a tower demand, and the professors observed behaviors that echoed real project dynamics. Teams A and D tried to discard an unexpected event card through skill tests; Team D’s Architect succeeded while Team A’s failed, forcing that team to continue with the disruption. Team C, having missed the moat criterion of a distinct color, prioritized correcting that fault before starting the tower. As the timer ran down, players increasingly abandoned their defined roles, with Builders, Architects, and Testers overlapping in function. By the final evaluation, all teams built their structures satisfactorily, and one team even met the tower’s window criterion using unexpected blocks, suggesting that success improved as players gained experience.

The quantitative results were detailed and consistently favorable. In the background and motivation questionnaire, the three knowledge areas of architecture, construction, and testing were rated important, with means between 3.60 and 3.70, while motivation to learn software engineering showed the highest dispersion, with a standard deviation of 1.00. In the feedback questionnaire, the nine items obtained means between 3.25 and 3.95, and all nine were significantly above the scale midpoint with p values below 0.01 and effect sizes between 0.71 and 1.00. The Friedman test confirmed the differences among items were informative rather than random. The fun and challenge of the dynamics rated highest, with 95 percent of participants giving the top score, while the amount of building blocks ranked lowest, with 80 percent positive ratings. Notably, the three lowest-rated items concerned time constraints, block quantity, and complexity level, suggesting that reservations targeted the operational conditions of the session rather than the game’s design. The game master’s presence earned a mean of 3.75, and no participant produced a predominantly negative evaluation.

The collective SWOT analysis revealed both strengths and friction points. Participants praised the game’s playful presentation of the software development process, its encouragement of creativity, and one noted that its phases resembled the steps of the Agile Scrum methodology, while another described the character sheet as a form of self-assessment. Weaknesses centered on communication failures with the Customer and Manager, the absence of a planning stage, the short 10-minute time limit, and the isolation of Testers and Architects during rushed final rounds. The study also documented a revealing divergence: some participants asked for reduced complexity while others requested more complex challenges, a pattern with a standard deviation of 0.82 on the complexity item. The authors connect this to gamification research showing that player profiles, such as the Bartle archetypes or the Hexad typology, moderate responses to game mechanics, though they emphasize that the study measured Kolb learning styles, not player profiles, and could not distinguish between experience-based and motivation-based explanations for the divergence.

The authors are explicit about the study’s limits. The instruments were ad hoc questionnaires and a SWOT analysis rather than validated scales such as the System Usability Scale or the Intrinsic Motivation Inventory; no objective learning measures like pre- and post-knowledge tests were collected; the sample of 20 students from a single institution was small and homogeneous; and the anonymous questionnaires could not be linked across instruments. A controlled experiment was deliberately avoided because randomly withholding the activity from part of a single class raised pedagogical objections and would have yielded subgroups too small for statistical power. The findings therefore indicate the direction and consistency of participant perceptions, not generalizable estimates of learning gains. Future work outlined by the team includes replication across multiple institutions, adoption of validated scales, objective learning measures, incorporation of a player-profile instrument such as the Hexad scale, and extension of ConES to other software engineering knowledge areas, building on evidence that the game’s cooperative, face-to-face format surfaces difficulties, such as role isolation and communication breakdowns under time pressure, that individually mediated educational games cannot observe.

Subject of Research: A role-playing game for teaching software product construction in software engineering education

Article Title: A case study on the application of a role playing game to support the teaching of software product construction

Article References: dos Santos Guerra, A., Oliveira, S. R. B., & Furtado, J. C. C. (2026). A case study on the application of a role playing game to support the teaching of software product construction. Discover Education, 5(1), Article 1220. https://doi.org/10.1007/s44217-026-02258-3

Image Credits: AI Generated

DOI: 10.1007/s44217-026-02258-3

Keywords: software engineering education, role-playing game, ConES, gamification, case study, software construction, Lego building blocks, Kolb learning styles, SWOT analysis, computer science students, Brazil, Discover Education

The study rests on a theoretical foundation drawn from three pillars of learning science. The first is cognitive load theory, developed by John Sweller, which describes how sensory memory, working memory, and long-term memory interact when learners process new information. According to this framework, the difficulty of learning a programming paradigm depends on the level of abstraction and the number of interacting elements a learner must juggle simultaneously. When a developer trained in object-oriented thinking encounters functional programming, the unfamiliar constructs must be integrated with existing mental schemas, a process that can easily overload working memory and slow early progress. The second pillar is transfer learning theory, which explains how skills acquired in one domain can either help or hinder learning in another. Prior experience with object-oriented interfaces may ease the adoption of similar constructs in Java, for example, while deeply ingrained imperative habits can actively interfere with understanding functional programming’s insistence on immutability. The third framework, expertise development theory, describes how knowledge accretes over years of practice, with rapid early gains followed by plateaus as learners refine their conceptual understanding, a pattern that maps directly onto the classic shape of a learning curve.

What makes programming paradigms such a compelling subject for cognitive research is that they are not merely syntactic conventions. Each paradigm encodes a distinct cognitive organization of the problem space. Object-oriented programming encourages learners to model systems as networks of classes and objects that communicate through message-passing, emphasizing encapsulation and modular design. Functional programming demands immutability, higher-order functions, and declarative reasoning that resembles mathematics more than step-by-step instruction. Logic and other declarative paradigms ask learners to specify desired outcomes rather than explicit control flows. Because these mental models differ so profoundly, switching paradigms forces developers to reorganize how they represent problems internally. The study highlights a phenomenon the literature calls paradigm adherence or transfer interference: developers anchored to their first-learned paradigm tend to reach for the wrong tools when working in another, searching for solutions based on residual knowledge from a previous approach. This not only impedes comprehension but can measurably slow the rate of learning, which is precisely why the author argues that paradigm acquisition is neither uniform nor linear and deserves empirical measurement in its own right.

To capture these trajectories, the researcher adopted a cross-sectional, survey-based design combining quantitative and qualitative methods. A structured online questionnaire collected data on years of experience per paradigm, self-rated proficiency at six time points from the start of learning through the present, perceived difficulty on a five-point scale, motivation, and hours of study. Seventeen developers responded, a small but diverse group that included students, researchers and academics, and professional developers, with bachelor’s degree holders making up roughly 52.9 percent of respondents. The questionnaire was content-validated by two academic researchers in computing education and piloted with two developers before distribution. Responses were anonymized, exported, and analyzed in Python, with descriptive statistics, Pearson correlations, and a paired t-test forming the quantitative core, while open-ended responses were subjected to a six-phase thematic analysis following the framework of Braun and Clarke. The author is candid about the limitations: with such a modest sample and retrospective self-reports, the results are descriptive and hypothesis-generating rather than generalizable, but they offer a structured operationalization of paradigm learning that larger studies can build upon.

The experience data revealed a pronounced hierarchy among the paradigms. Object-oriented programming showed the highest mean prior experience at approximately 3.15 years, followed by functional programming at about 2.32 years and procedural programming at roughly 2.21 years. At the bottom sat the reactive/event-driven and concurrent/parallel paradigms, with mean experience of only about 1.82 and 1.47 years respectively. This distribution suggests that object-oriented and procedural styles remain the default foundation of most developers’ education, while reactive and concurrent approaches are treated as specialized or advanced domains that many practitioners simply never encounter in depth. The pattern, the study argues, reflects curricular biases and structural barriers in computing education rather than any inherent order in which paradigms should be learned, and it hints at a potential misalignment between what universities teach and what the modern software industry increasingly demands.

The learning curves themselves told a story of steady, if effortful, progress. Average self-rated proficiency began at a baseline of roughly 3.71, climbed to about 4.0 by the three-month mark, and reached approximately 5.18 by the time of the survey. A paired t-test comparing starting and current proficiency produced a statistically significant result, with t equal to negative 4.47 and p below 0.05, indicating a measurable learning gain across the group. Difficulty ratings, however, skewed heavily toward the difficult end of the scale, with only a minority of participants describing the learning process as easy or moderate. The author attributes this to two non-exclusive factors: the intrinsic complexity and abstraction of the paradigms themselves, and the particular demographic composition of the sample, which included many learners still embedded in academic settings. Correlation analysis added further texture, showing a positive relationship of about 0.45 between general experience and current proficiency, positive correlations between experience in related paradigms such as functional and object-oriented programming that suggest foundational knowledge transfer, and a positive link between total hours invested and final proficiency.

Perhaps the most vivid findings came from the qualitative strand. Thematic analysis of the open-ended responses surfaced three dominant motivators for learning a new paradigm: academic and curricular drivers such as university courses and degree requirements, employment and project needs including job requirements and freelance work, and intrinsic motivation rooted in personal interest and self-growth. Participants who learned with a definitive practical goal in mind, such as capacity building or project demands, reported the highest average proficiency levels, reaching up to 7.0 on the self-rating scale. One participant observed that most paradigms are intertwined, noting that understanding the basics of procedural and object-oriented programming makes learning other paradigms easier. Another described a slow learning trajectory attributed to self-directed study, while a third reported learning far more after joining a team, underscoring the value of collaborative and structured support. A word cloud of recurring terms placed academic and course above all others, with job, project, and personal appearing as secondary drivers.

Taken together, the results paint a picture of developers leaning heavily on self-directed learning, including documentation, tutorials, and hands-on experimentation, to acquire the more advanced paradigms that formal instruction leaves uncovered. The study frames this as a quiet failure of the traditional educational model: learners are well prepared for conventional tasks built on procedural and object-oriented foundations, but the cognitive strain of abstract or concurrency-focused paradigms, combined with limited early exposure and weak pedagogical scaffolding, slows their progression precisely where industry needs them to be fluent. The author recommends diversifying paradigm exposure at early learning stages, providing more robust scaffolding for abstract concepts, and integrating real-world, project-driven learning into curricula. The findings also connect to broader educational research suggesting that structured bridging activities, critical thinking exercises, and algorithmic problem-solving approaches can shorten learning curves in programming and related domains.

The study’s limitations are acknowledged plainly and are worth keeping in view. Seventeen respondents cannot represent the global developer population, retrospective self-assessments capture perceived rather than actual learning trajectories, and the cross-sectional design rules out causal inference about how proficiency develops over time. Recall bias and subjective interpretations of proficiency are inherent risks of the method. The author calls for longitudinal designs that track real proficiency changes, larger and more diverse samples spanning multiple institutions and regions, and experimental studies evaluating specific interventions such as visualization tools, AI-assisted learning systems, and project-based modules. Even so, the work makes a genuine contribution by treating paradigm acquisition as a measurable cognitive process with comparable learning curves, rather than a vague matter of pedagogical taste. As software systems grow more concurrent, reactive, and distributed, the gap between what computing curricula emphasize and what developers must master is only likely to widen, and studies like this one provide the empirical footing needed to close it.

Subject of Research: Empirical study of learning curves and how developers acquire proficiency across five programming paradigms

Article Title: Learning curves and programming paradigm acquisition in developer education

Article References: Bob-Manuel, A. A. (2026). Learning curves and programming paradigm acquisition in developer education. Discover Education, 5(1), Article 1035. https://doi.org/10.1007/s44217-026-02124-2

Image Credits: AI Generated

DOI: 10.1007/s44217-026-02124-2

Keywords: programming paradigms, learning curves, developer education, cognitive load theory, object-oriented programming, functional programming, concurrent programming, computing curricula, self-directed learning, transfer of learning, thematic analysis, software engineering education