Andrew Drinkwater
In a prior life, I was an enrolment forecaster at a top-ranked university. By March, I’d be looking forward to Senate approval. No rest for the wicked – time for a new and improved version for next year!
There are two key places where version control matters for your forecast:
- Data and model architecture: the structural part of your forecast such as database structure, model code, output visualizations, and so on.
- Within scenarios: these can be changed by parameters the user can control (such as intakes or retention rates) and those that the user cannot control (such as historical data or updates based on a schedule).
In this article I’ll discuss the architectural perspective. In subsequent articles, I’ll talk about scenario versions.
What is version control?
In a nutshell, version control allows you to track changes made to a file.
I’ve seen all manner of ways of documenting different version control: dates, version numbers, comments in code, variants of “final final edited final”, full version control systems, and, my least favourite, overwriting previous versions.
Why is version control important?
Version control is important many reasons. Some of these reasons include:
- It allows you to roll back changes if there has been a mistake.
- Documenting changes that have been made over time.
- Comparing different versions of a file.
- Ensuring that new changes don’t clash with other changes.
Can software support this?
Absolutely! In fact, many of the software tools you use every day were built using version control and support it themselves. For example, maybe you’re using macOS Monterey, version 12.2.1; this suggests that Apple has internal version numbers to correspond to features and bug fixes. Or maybe you’re using Microsoft OneDrive or SharePoint, which allow you to see prior versions of documents. These tools are extremely helpful as they offer version control functionality built into the software that creates a historical record of all changes with a timestamp and indication of which user made the change. This functionality allows the end user to view, delete, and restore a previous version if needed.
In the context of an enrolment forecast architecture, I recommend using software to support versioning. One of the most common of these is Git, an open-source version control system that tracks changes to code, files, and so on. There are many providers of Git version control systems, with GitHub being one of the largest. I’ve also used Atlassian BitBucket and AWS CodeCommit for some projects, while GitLab also offers similar services. There are other forms of version control including CVS (Concurrent Version Control) and Apache Subversion.
For example: Adding a new variable to your model
Enrolment forecasts are often large and complex models, involving information from databases, models, spreadsheets, and several other places. These models often involve thousands of lines of code if built from scratch, and there are many opportunities for human error.
As a result of our changing world, let’s imagine that we survey our students and faculty to figure out their preferences for online, hybrid, or in-person learning. We can then add an enrolment preference score to our data model, which may suggest that our balance of enrolments could swing to a greater proportion of online or hybrid than we’ve seen in past, non-COVID years.
To implement a change like this, we would make a new branch in Git. In software, many teams will name their branches in a similar format to “features/enrolmentpreferences”.
This will allow you to test out the code that incorporates these survey results. If it works well, great – you can then merge your revised code in the main branch. If not, you can diagnose the issue and determine if there are alternate approaches or if you should give up on this change to the code.
Perhaps everything about your change went as well as you hoped it could, and you merged it into the main branch. Your users now see it in production. Sure enough, you start getting questions about why the estimates have changed. To explain the changes, you can look back on your version control and confidently say “the new enrolment preferences feature was implemented 2 weeks ago. Our testing suggests that it is highly accurate, but it is different than what we’ve used in the past”. Hopefully everyone cheers. But if you have to roll back your changes, you can easily do so in only a few clicks.
Summary
Enrolment forecasts require continuous improvement to adapt to changing circumstances in higher education. Version control is a tool that can help improve your forecast architecture.
This will not only help you better catalog how improvements are made over time, but it will also make your work more transparent for others who may work alongside or eventually replace you, and will give you the flexibility to roll back when a change doesn’t work out as planned.