3greeneggs

This summer, I’ve been involved in the process of creating a new undergraduate curriculum essentially from scratch. I was reflecting back on this process, and I realized the development of a robust and relevant curriculum shares many attributes with the process of developing robust and functional software.

Modern software development is a largely modular process. Each component of a system interacts with every other component through a defined interface. I see this same behavior in a degree program - each course has certain incoming requires and defined outcomes. Students navigate through a narrative of courses that must fit together to equal a bachelor’s degree.

Unit testing is the practice of separating out each module in a software system and insuring that it functions correctly. The final system is will contain many modules interacting together in potentially unforeseen ways; by testing each piece repeatedly throughout the development process, we can reduce the number of problems that creep in when everything is integrated.

If we continue the metaphor of courses as modules and curriculum as software system, we find that students will create an arrangement of these sets of courses, based on simple rules given in the course prerequisites and degree requirements. The arrangement must function to make certain that a student doesn’t end up in a course that they aren’t prepared for, while also making certain that any given legal arrangement of courses provides a degree program that meets the program outcomes.

Just as we must assess students’ mastery of material, we must also evaluate the effectiveness of each course to make sure that it is actually supporting the written course outcomes. This process is required for a University to remain accredited, but can also yield useful “debugging” information to help refine course sequences.

The need for evaluation brings us to security. As odd as it may be to think of an educational program being “hacked”, we need to make certain that the rules are arranged such that any legal sequence of courses meets the degree program outcomes. It’s also important to make sure that a course taught by one faculty member has largely similar learning outcomes as the same course taught by another faculty member.

Finally, software and curriculum share the odd trait of generally being created by people who are not the typical audience. Creating usable software generally involves gathering data from the community and directing development and testing accordingly; we see the same thing in educational programs. The community of “users” can be roughly divided into three major constituencies: University administration, students (and parents), and employers or graduate schools, each of which have different priorities and different priorities than the faculty or administrators creating the course. It is impossible to satisfy them all without doing some usability research.

Thinking of curriculum design as software engineering is more than just a cute metaphor. Software engineering is the discipline of delivering complicated systems that function as designed. We can take some of the well-understood tools and processes of software engineering and apply them in curriculum design. For example, unit testing teaches us to define both incoming requirements and outgoing interfaces for each module in a system. If we define both outcomes and “incomes” for all courses, we can create a map of all legal sequences involving that course and, by matching the various sets of outcomes to incomes, make certain that students will be best prepared to perform in the course at the time that they take it.

By adapting the tools of software engineering to curriculum development, we can make the entire process easier and more likely to succeed, while providing more reliable objective data on the success of the degree program!