Scheduling for the 2008 winter and spring semesters began last wednesday. This necessary event was far from running smoothly.

Those students who were in the first scheduling block experienced limited complications, an error message that informed them there were too many sessions currently in progress, and to try again later.

The later sessions experienced crashes and were forced to register manually with the Registrar. According to an e-mail sent by Chris Fulkerson, assistant vice president for technology, the system went down at 9:20 a.m.

Fulkerson sent an e-mail to students at 3:20 p.m. informing students of the situation and advising them to start registering manually with the Registrar and Academic Advising.

Why did it take six hours for this e-mail to be sent? The e-mail contained no information other than the OnTrack system was down and was experiencing malfunction. Most of this information was already known to students.

Furthermore, Fulkerson’s e-mail told students to do something they were already doing: register manually.

It was speculated that while upperclassmen were registering, some underclassmen took advantage of the chaos and got in line ahead of their registration period. The result is that valuable class space, that should have gone to upperclassmen, was taken by underclassmen.

While this instance is by far the worst in the last three years, it is by no means the first time that there was a breakdown of the system.

Every year, there is some complication with the OnTrack system. While a full scale crash has not happened, the system constantly experiences, slow downs and overloaded sessions. This is unacceptable.

While it is expected that OnTrack will slow down during peak operating events, such as registration week or drop/add day, the problems with OnTrack exceed minor inconveniences.

This system is built for the simple function of carrying out registration, as well as the storing of academic records and it is only expected to carry out this purpose twice a year. It is a tool meant for a specific purpose. But this tool barely passes muster.

When used for the sophomore writing assessment in the spring of 2006, it crashed, forcing students to use e-mail instead. When used for registration, it strains under the pressure. Neither of these functions are “acquired” tasks, they are the tasks that OnTrack was ostensibly created to fulfill.

The problems that plague the system appear astoundingly preventable. We were told that OnTrack strains because there are too many open sessions.

The remedy for this is simple; either we create the infrastructure for the system to support these sessions or we limit the number of available sessions.

The first option simply entails obtaining further resources, i.e. servers, space, etc., for the system to absorb the heightened level of traffic during registration sessions. These resources should be dedicated to OnTrack’s high traffic events and would therefore absorb the extra strain.

The other option is to limit the number of people using the system at one time. We know by simple human nature and personal experience that students will not rationally wait until later in the session to register for their classes.

Every student in a particular session will be online five minutes beforehand, waiting to register. Like a horse race, when the gate opens every student will charge to finish the form and submit their schedule.

Therefore if we are unwilling or unable to create more infrastructure to accommodate this trend, then we must further limit the amount of students allowed to apply at a certain time.

It is extremely simple to determine the number of students that fall into each category. If one block has a larger amount of students, divide it in two. The solutions to the problems that the system keeps experiencing are simple enough. Why has no one implemented any solutions yet?

Finally, the fact that these problems consistently occur gives the impression that whatever organization is responsible for OnTrack’s preparation is reactive instead of proactive. They are reacting to problems as they arise rather than preparing the system for the strain of registration.

Mistakes occur, as do unforeseen circumstances, but repeated error and the repetition of malfunction of a certain kind lead one to predict either a weakness in the system or fault with those responsible for it.

If the fault lies with the system, it should be refined or replaced. If fault lies with organizational action, thern those actions need changing.

There is no reason for there to be a presence of consistent error with the OnTrack system. It should be able to act under the expected constraints to which it has been tasked.

This repetition of error, either by the system, its administrators, or a combination of the two must be rectified immediately.

Staff: - 11/14/07