One of the key indicators for testing code quality is the level of modularity. Nevertheless, novice programmers do not always stick to writing modular code. In this study, we aim to examine the circumstances in which novice programmers decide to do so. To address this aim, two student groups, twenty each, were given a programming assignment, each in a different set-up. The first group was given the assignment in several stages, each add complexity to the previous one, while the second group was given the entire assignment at once. The students' solutions were analyzed using the dual-process theory, cognitive dissonance theory and content analysis methods to examine the extent of modularity. The analysis revealed the following findings: (1) In the first group, a minor increase in the number of modular solutions was found while they progressed along the stages; (2) The number of modular solutions of the second group was higher than of the first group. Analysis of students' justifications for lack of modularity in the first group revealed the following. The first stages of the problem were perceived as rather simple hence many students did not find any reason to invest in designing a modular solution. When the assignment got complex in the following stages, the students realized that a modular solution would fit better, hence a cognitive dissonance was raised. Nevertheless, many of them preferred to decrease the dissonance by continuing their course of non-modular solution instead of re-designing a modular new one. Students of both groups also attributed their non-modular code to lack of explicit criteria for the evaluation of the code quality that lead them to focus on functionality alone.

In this study, we describe Information Systems students' decision making along their engagement with their final project regarding the complexity and innovations of their projects, and the technology they selected for the implementation. Data was gathered from projects' documentation; a questionnaire handed to the study participants, and from in-depth interviews conducted with representative group of them. Analysis of the data revealed that high achievers tend to develop innovative and complex final projects using major extensions of technologies learned in class while low achievers tend to develop simple and basic final projects using merely technologies learned in class or a minor extension of them. Surprisingly, some of the average and low achievers and none of the high achievers tended to use completely new technologies to gain relative advantage when applying for jobs, although this choice necessitated them to cope with large knowledge gaps.

This study examines the understanding of various aspects relating to the concept of interface class by Management Information Systems students. The examined aspects were: definition, implementation, class hierarchy and polymorphism. The main contributions of this paper are as follows: we developed a questionnaire addressing the above aspects; we classified and analysed the students' responses to determine the students' understanding of the above aspects and to highlight common faulty solutions. The results obtained reveal that majority of the students demonstrated understanding of definition and implementation of interface class, however, only two- thirds of the students demonstrated understanding of interface class in the context of class hierarchy and only one third of them demonstrated understanding of polymorphism in the context of interface class. The students’ utterances from the interviews shed light on their difficulties.