Over the past few months in IS SSP we have been working on two major SITS projects: UG Paperless and Direct Paperless Admissions. Both projects have come out of the push towards moving away from paper applications and doing all of our admissions processing online. The UG Admissions project was first implemented last year and is now in its second iteration. Direct Admissions will be released for the first time this fall.
When work first started on Direct Admissions, the idea was that this would use the same framework as UG Admissions. At the time this was thought to be a good solution since that meant that some of the files and tasks used in UG Admissions could be re-used/re-purposed for Direct, following the golden rule of DRY (Don’t Repeat Yourself). As we went along, however, we discovered that this created more problems than it avoided. For example:
- Overwriting each other’s changes by accident
- Changing the way something is done/referenced without updating it in the other project
- Being forced to implement a ridiculous lengthy workaround to make something for the other project work in your project
- Performance hits from pages loading extra, unneeded files or other config
Part of this was due to the unique challenges of working with SITS (no versioning, for one thing), but the main problem was that we were treating UG and Direct Admissions as two separate projects . This is true from a business perspective. They have different requirements, and a completely different set of users. However, the projects use a partially shared code base so it isn’t true from a technical perspective. In that sense they are actually just two sides to the same coin, and we should have developed them this way.
The development process became easier when we realised this and started working more closely together. Recently, it was decided that the two projects will be released together and we have been collaborating on a combined implementation plan. This will let us manage the changes easier and make sure we aren’t conflicting with each other. We also realised that, in some cases, repeating yourself is actually the right solution. Many of our problems were solved when we started to separate out our files from each other.
This experience also forced us to take a closer look at how we detect conflicts between projects and realise that we need to do this a lot better. Recently we’ve started developing some new tools for our CMS (Config Management System) page which will let us detect conflicts and track changes more accurately than we could before.
If we were to do these projects again, we would choose to work together from the very beginning. For example, a shared HipChat room would have really helped us keep track of each other’s changes. We tend to think of each project as being its own separate entity, but when they overlap with each other that isn’t necessarily true. In this case, better collaboration would have solved our problems.