OOPSLA 2006 Educators Symposium
The development of any piece of software begins with a set of specifications describing in some detail the problems to be solved. Almost invariably, the specifications change during the development of the software. Trying to anticipate all possible changes and write a program that does everything is a futile undertaking. However, it is not unreasonable to expect that programs be written in such a way that an “epsilon” (read “small”) change in the specifications will only necessitate a “delta” (read “manageable”) change in code.
Programming for change is a continual process in which software is designed over many iterations to capture the problem’s essence and express. At the heart of this process is the effort to identify those elements that can vary (variants) and delineate them from those that do not – the invariants. A properly designed software system should strive to decouple the variants from the invariants in order to facilitate the re-use of the invariants and allow modifications to the variants with minimal perturbation to the existing code.
To illustrate the importance of programming for change to students, we guide them through the development of a program that converts temperature measurements. The assignment consists of a series of small exercises, each of which imposes a small change in the requirements and forces appropriate modifications of the code. To promote code re-use, we apply the Janus Principle and require that the programs must be written in a way that supports multiple distinct user interfaces. For certain specification changes, we ask students to identify the variants and the invariants and make appropriate modifications to the code. In several situations, we require the students to modify their code in more than one way and discuss the pros and cons.