In the fall of 2013 a professor of our acquaintance taught a software engineering course with 24 students. He divided them into three teams of eight, and required each team to complete a substantial project using the Scrum agile methodology. He spent instructional time on an overview of software engineering in general and on Scrum in particular. He spent class time on the Scrum process as needed: for example, he gave teams fifteen minutes at the end of each class period for their daily scrum. But the professor still had time to cover topics in software engineering not directly related to Scrum. He wondered which were the best to teach. Which topics were truly essential? Which would benefit his students regardless of what methodologies they might use in the future?

As reported in the Google Research Blog, nearly all binary search and merge sort implementations are broken because of an integer overflow bug. The bug does not appear unless the array being searched/sorted is quite large (over a billion elements), which is why it has remained undetected for decades. There is a tendency to dismiss such overflow bugs as mere trivia, but this is a mistake. This paper reviews the bug, some common but incorrect solutions, and a correct solution. More important, it distills lessons to be learned from the bug, and provides specific recommendations for computer science educators to help their students cope with such bugs in the future.

Though most of our computer science curriculum is operating-system agnostic, Windows is installed on our lab machines and most of our students' computers, but we require Linux in our operating systems course. What is the best way to provide a Linux environment for students to use both at home and in our labs? We revisit the traditional solutions to this problem in light of recent trends in network security and virtualization, then explain our current solution, which is to provide a custom 768MiB Ubuntu JeOS virtual machine on a USB flash drive.

In the ACM/IEEE 2001 curriculum guidelines, computability and its limitations are required topics, but Turing machines are not. However, most undergraduate textbooks that cover computability base their discussion on Turing machines, so in practice it is difficult to cover the required material on computability without also including elective material on Turing machines. This paper provides simple, classroom-tested techniques for teaching computability rigorously without reference to Turing machines or other theoretical topics. Even instructors who choose to include elective material on automata theory are likely to find this presentation simpler and more intuitive than traditional ones.

We give a compositional denotational semantics for components of a small low level language. The semantics is given in a limited parallelism model with realistic assumptions about the execution environment. Among the modeling issues considered are: •  The semantics of the individual program segments. •  The number of physical processors. •  The relative speeds of the processors, i.e. local clocks. •  The manner in which processors are assigned to processes. •  Constraints on shared memeory access. •  Scheduling disciplines.