Shift Scheduler: Facing Adversity

As the first entry on this site, I would like to take a brief moment to explain how I ended up writing this neat little CRUD app.

Backstory

So, as the story goes, I was working an hourly job and I was grilling my boss as to why she scheduled me at 6AM instead of my normal in-time. She got mad and said "You know how hard it is to juggle everyone's changing schedules? Why don't you do it then?" And so that spawned an idea: I worked at Walmart ages ago and they had an auto-scheduler. The only issue is that employees couldn't reasonably change their availability because it wasn't user-facing, only management had access to it.

The Solution

So, using the skillset I've developed over the years, I've decided to write my own employee scheduling program. This is a simple project, and it will probably stay in MVP status. I host this and the rest of my portfolio here from now on.

I've chosen to use the Grails language here because I'd eventually like to have a job in either Ruby or Grails, I've enjoyed working with Ruby and the opportunity to take advantage of the JVM to run a server everywhere with syntax far cleaner than Java's is too appealing not to attempt.

Below I will list out a rough roadmap:

  • Users have two roles: Administrator and Employee. To this end, Employees cannot edit the schedule, and Administrators cannot edit the Employee's availability, but they can see it
  • Availability Interface - This is the crux of why Walmart's system was a neat concept but vastly inferior to how things could be. Before we run the algorithm to produce a schedule, we feed it Availability data from the entire database. This may not scale well, but for restaurants and smaller operations of 500-ish or less, this isn't a bad option and I'm sure it can be optimized. For larger businesses, it would make sense to have more than one instance running for each department.
  • The algorithm I'm going to write should generate a new Schedule and store it in the DB. A list of Schedules will be kept, the default is to keep 10 and wipe them sequentially.
  • Generate a PDF table of the generated Schedule. This might be my favorite part of the entire program if it works.
  • Allow Administrators to edit a Schedule. Edits will have red text to indicate modification.
  • Employees should be able to view the schedule but not edit it.
  • Shift covers - allow employees to cover shifts at will, likely this process takes place somewhere else in your organization because companies use 45 different apps when all-in-one solutions exist.

Potential Issues

I don't expect this to be used in production. If someone forks it and turns it into a proper FOSS Altametrics replacement or what have you, have at it hoss, I only ask that you respect the GPL and share the spoils with the next developer.

In regards to being used in a workplace setting, keep in mind that this app is simple because I want to facilitate effective communication. The decision to disallow administrators from editing availabilities directly is intentional, however a shift cover system will be available but is optional to use. A proper workplace would make it known that you need to set your availability, and that if the workplace is short-staffed, a cover rule should already be in place.

Conclusion

I'll be back as I start to deal with the MVC side of things. I need to learn Grails still, so some things here may not be immediately available to me, but that's okay. Ciao!