This is the title of a paper I delivered at the 2007 WCCCE (Western Canada Conference on Computer Education) at Thompson University in Kamloops, BC. For the talk, I decided to create a presentation in the same style as the presentation I gave to the High School back in March. I've included some of the sample slides.
<
Abstract
This paper argues that students can best understand the benefits of software design principles when they have to work on a project in which requirements change repeatedly in some substantial way over the course of a semester. This paper describes a semester-long game project in which change was enforced upon the students by making them develop for three different user interface platforms (text-based console, desktop Windows, and a mobile Pocket PC). By making the students plan and adapt for this change, the students were better able to truly appreciate the benefits of good design and were willing to take the extra effort to implement a design that reflects the principles taught in most object-oriented design courses. The key principle engaged by this approach was the importance of a layered architecture to software projects driven by change.
Introduction
“Observe always that everything is the result of change, and get used to thinking that there is nothing Nature loves so well as to change existing forms and to make new ones like them.”
-- Marcus Aurelius
Marcus Aurelius’s advice to himself to be stoic in the face of change is as relevant today for software developers as it was in the 2nd century AD for Roman emperors. Of course, today’s developers are generally less concerned with barbarian incursions and unreliable Praetorian Guards and more concerned with shifting requirements and fast-approaching deadlines. For if we replace the word “Nature” in Aurelius’s maxim with “Clients” we will then have some very sound advice for any practicing or prospective software developer. From this author’s own experience, clients very much do love to change existing (Windows or Web) forms and force developers to make new ones that are very much like the old ones but yet different enough to cause anguish to the project deadlines!
Many authors on software design have noted the ubiquity of change in the typical software project. Once high-profile study, for instance, showed that business rules for a typical software project changed at the rate of 8% per month; another study indicated that over 40% of requirements arrive only after development is well under way [12]. The ubiquitous nature of change in the software development world is the principal reason for the decline in commitment to waterfall development models and the concomitant rise in interest in iterative and agile methodologies. Indeed, the subtitle of one of the key texts in the field of iterative development is Embrace Change [4]. As one author has noted, rather than fight inevitable change, one should use a process that acknowledges “change and adaptation as unavoidable and indeed essential drivers” [13].
Yet despite the current wide-spread use of iterative approaches in real-world software development and the attempt by many teachers to integrate these more agile processes into computer science education [see, for instance, 9, 11, 14, and 16], the essential ingredient of change can be difficult to add into a typical one semester course (for an attempt at integrating change in a software project, see [1]). This is a particularly unfortunate shortcoming since the value of many of the most important object-oriented design precepts can only be appreciated in a project that is undergoing a certain amount of change.
This paper details this author’s attempt to integrate changing requirements into a semester development project. The project was a combat game and the change element in it was that it had to be implemented on three different platforms: text-based console, desktop Windows, and Pocket PC. In particular, this paper will examine what was perhaps the most lasting lesson learned by the students: the importance of a layered architecture to software projects driven by change.