As a residential education software company working with many different colleges and universities, Roompact designs its software in a way that can accommodate the range of approaches institutions can take to the learning process in the residence halls. One of the most interesting design challenges we have confronted is how to accommodate both residential curriculum models and category-based programming models in our software. At first glance, one may not think the processes would be that different. Programming models and residential curricula, however, are based on different sets of assumptions and practices. The chart below illustrates a few of these:
Whereas different programming and community development models in the past have been largely interchangeable, resting on a similar set of assumptions and practices, curricular models represent a departure from the past. One of these changes is a reduced reliance on programs as the main method of educational delivery. Curricular approaches utilize strategies that move beyond the program such as through community meetings, roommate agreement processes, intentional resident conversations, and attendance at campus partner events.
Because curricula take a broader view of programmatic efforts, the Roompact team made an intentional decision to name our “program-tracking” module “Events.” All programs can be considered events, but not all events are programs (at least in the traditional sense). By adopting the “Events” moniker, this allows individuals to think more broadly about what this module can be used for. As we expand and enhance it, Events will allow for an even broader array of educational initiatives that fall outside of the traditional notion of a program.
A deeper level issue that has given our software engineers a challenge, however, is the inverted logic flow of a curriculum versus a programming model. Under a programming model, student staff members propose programs to a professional staff member who reviews and then approves or denies the proposal. Under a curricular approach, however, this process is reversed. A learning plan is “assigned” to an RA. The approval process occurs through curricular planning and peer review before it is executed by a staff member.
This inversion has many implications for how one designs software to accommodate both approaches to student learning. Events, programs, and educational interventions need to be proposed and assigned bidirectionally: coming from either the student staff member or from the professional staff member. Program model categories and curricular goal areas also have different tracking needs and assessment expectations. Curricular efforts often require connections to other data sets and stricter consistency with set learning objectives as opposed to the assessment needs of programming models.
While this presents a software engineering challenge, it also highlights why there is so much dissonance when institutions change between programming model mindsets and curricular mindsets. The logic of both paradigms and the processes that support them, while similar on the surface, are vastly different. Without an appreciation for the philosophic differences between the two, approaches can become muddled and inconsistent. The same holds true in designing the software that enables it. The challenge is real.
