Despite our best efforts and intentions as educators, student programmers continue to struggle in acquiring comprehension and analysis skills. Students believe that once a program runs on sample data, it is correct; most programming errors are reported by the compiler; when a program misbehaves, shuffling statements and tweaking expressions to see what happens is the best debugging approach. This paper presents a new vision for computer science education centered around the use of test-driven development in all programming assignments, from the beginning of CS1. A key element to the strategy is comprehensive, automated evaluation of student work, in terms of correctness, the thoroughness and validity of the student’s tests, and an automatic coding style assessment performed using industrial-strength tools. By systematically applying the strategy across the curriculum as part of a student’s regular programming activities, and by providing rapid, concrete, useful feedback that students find valuable, it is possible to induce a cultural shift in how students behave.

This paper describes the pedagogical implications of the GREWPtool (the Groupware Research in Education and the Workforce Project), a same time different place groupware tool built to support synchronous, collaborative coding among small to medium sized groups. GREWPtool exploits the educational benefits of paired programming while extending the model to allow students synchronous control of the same code. This effectively drops the constraints of turn taking, and allows for a richer interaction. The result was a powerful tool that can be used to provide interactive lectures, structure classroom activity, and facilitate paired programming during labs. In this paper we present the design and use of GREWPtool with an emphasis on how it enhances the classroom experience. In particular, we give a qualitative analysis of how this tool has been used in six lab courses over the past two years. 1

A new approach to the design of the computing curriculum for a Bachelor of Arts degree is described. The approach relies extensively on problem-based instruction and computer graphics. The novelty arises from the magnitude and origin of the problems to be integrated into the curriculum and the breadth of the impact across the curriculum. Results from a trial course, the first experiment with the new approach, are described. The course, Tools and Techniques for Software Development, is a sophomore-level course in programming methodology. Construction of a ray-tracing system (for generating synthetic images) was the vehicle chosen for the instruction.

Abstract. Successful qualitative analysis of pair programming requires a terminology (such as a set of concepts or a coding scheme) that represents the observed phenomena on an appropriate abstraction level. On the one hand, different analysis goals will require different specialized terminology, on the other hand it would be helpful, if different studies used common terminology so that comparing and combining their results will be easier. We suggest to define terminology in layers: a PP foundation layer that is common to all analyses and more specialized study-specific layers on top. The present article presents this foundation layer which we have derived from audio/video analysis of pair programming sessions in Grounded Theory investigation style. Its concepts describe the individual observable human-to-human utterances and human-to-computer activities that occur during pair programming. 1

Abstract. Lab courses are an integral part of higher education in engineering sciences. In this paper, we report about a blended learning approach for such courses in computer science education. We show how the project method for co-located learning can be translated into a blended CSCL setting for a lab course on distributed software development, and how the resulting learning scenario can be supported with the collaborative virtual learning environment CURE. Experiences from the application of the didactical approach in two courses indicate benefits but also highlight the need for further technical support.

This article discusses issues related to the inconsistency between requirements principles and the need for faster and faster ways of developing software. Requirements principles are related to the purpose of the system and to the appropriateness of requirements that correctly describe what is necessary for the system to fulfil its objectives. I argue that the quest for speed in software development may have the undesirable effect of weakening these principles. Since the beginnings of software engineering, there is a search for faster ways to develop software. Many techniques and development models have been proposed that contribute for shortening development time, although the reduction in time comes almost as a side effect, as a result of improving some key aspect of software development. Agile methods are the first to place time-to-market as the prominent feature. The risk is to view other quality features as secondary.

This paper describes the pedagogical implications of the GREWPtool (the Groupware Research in Education and the Workforce Project), a same time different place groupware tool built to support synchronous, collaborative coding among small to medium sized groups. GREWPtool exploits the educational benefits of paired programming while extending the model to allow students synchronous control of the same code. This effectively drops the constraints of turn taking, and allows for a richer interaction. By recording user activity we were also able to ameliorate the issues of accountability and individual assessment common to group work. The result was a powerful tool that can be used to provide interactive lectures, structure classroom activity, and facilitate paired programming during labs. In this paper we present the design, implementation, and deployment of GREWPtool with an emphasis on how it enhances the classroom experience. In particular, we give a qualitative analysis of how this tool has been used in six small lab courses over the past year. We also discuss the use of the GREWPtool as a platform for studying pair programming and we provide some preliminary findings of a controlled experiment to test the effectiveness of pair programming among novices. 1

This experience report describes lessons learned using first generation tablet PCs to support active learning in an undergraduate computer science laboratory course. We learned that tablet PCs are poorly matched to typical CS laboratory tasks: writing, compiling, and testing programs. Pen-based input is inadequate for typical program editing tasks, and a pen is less effective than a mouse when typing at a keyboard. Students show a clear preference for desktop computers in this environment. Nearly three quarters of our students preferred a lab supporting wireless connectivity, however. Students also believe that the use of movable, reconfigurable furniture allows them to work in arrangements that are more natural during lab. Overall, students preferred the flexibility provided by wireless network access, freedom from cables, and movable furniture, but felt tablets were ineffective for programming tasks.

We attempt to automatically detect student frustration, at a coarsegrained level, using measures distilled from student behavior within a learning environment for introductory programming. We find that each student’s average level of frustration across five lab exercises can be detected based on the number of pairs of consecutive compilations with the same edit location, the number of pairs of consecutive compilations with the same error, the average time between compilations and the total number of errors. Attempts to detect frustration at a finer grain-size, identifying individual students ’ fluctuations in frustration between labs, were less successful. These results indicate that it is possible to detect frustration at a coarse-grained level, solely from coarse-grained data about students ’ behavior within a learning environment.

In side-by-side programming, two programmers (typically working on related aspects of a project) move their computers so close to one another that they can effortlessly change between working alone and working together, where working alone is the primary mode. The technique was proposed in order to obtain some of the advantages of pair programming at much lower overhead. As a first step towards understanding how and when to use side-by-side programming, the present study aims at describing when and for what purpose side-by-side programmers get together to cooperate. The main result is a classification of the cooperation episodes by purpose and content into different types: Exchange project details, Exchange general knowledge, Discuss strategy, Discuss step, Debug work product, Integrate work products, and Make remark. These types were derived via the Grounded Theory method and are described conceptually in terms of the types of events of which they consist. All concepts used in these descriptions are grounded in actual observations.