OOPSLA 2006 Educator's Symposium: Nifty Assignment

Temperature Calculator

Programming for Change

Dung “Zung” Nguyen, Mathias Ricken

Rice University, Houston, TX USA

Website with Applets and Updated Materials

A version of this document with working applets and updated materials is available at:



What is programming for change?  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 fluctuate and change during the course of development of the software.  Trying to anticipate all possible changes and write a program that does all and covers all is a futile undertaking.  However, it is not unreasonable to expect and even demand 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.  Though "small" and "manageable" are software characteristics with subjective interpretations based on differing software engineering metrics, at some basic level they can be expressed in terms of lines of code and "big Oh" analysis.

Programming for change is a continual process in which a software system is designed and re-designed over many iterations to capture the essence of the problems at hand and express it in code.  At the heart of this process is the incessant effort to identify those elements that can vary —the 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 programing for change to the students, we guide them through the development of a program that converts temperature measurements from one unit to another.  The programming assignment consists of a series of small exercises, each of which imposes a small change in the requirements and forces some appropriate modification on the implementation code.  To promote code re-use, we apply the Janus Principle ([1]) and require that the program at each phase must be written in such a way that it can support at least two distinct user interfaces: a GUI interface and a command line interface.  For certain specification changes, we ask students to identify the variants and the invariants and make appropriate modifications to the code.  In many situations, we require the students to modify their code in more than one way and discuss the pros and cons.  The programming assignment is summarized in the following.

What makes it so nifty?

Target audience

This project is intended for students in the second semester of an objects-first curriculum where they have already seen polymorphism, design patterns and component framework systems (see prerequisites below).

Ideas and Skills Involved

The Temperature Calculator is not really about converting temperature values to different units. Instead, it teaches students some of the bigger concepts in software engineering, such as:

Length of time students typically work on it

We have a 1.5 hour lab to help students get started on the assignment.  We expect students to spend from 6 to 8 hours on the project.  We give them a week to complete the project.

Prerequisite material

This project assumes the following material has been covered in class:

It is important that this assignment be given in the context of a comprehensive instruction on object-oriented programming that stresses abstract decomposition.

Difficulties to watch for

Instructional Materials


1. J. Adams, OOP and the Janus Principle, Proceedings of the 37th SIGCSE, March 2006, 359-363.