How to clone Jobmine in a year

So the replacement of Jobmine, known under a number of names, all of them too horrible to reproduce on an esteemed blog like this one, has been scrapped. Students disapproved and several resolved to write their own, one uttering the words “startup idea.”

Of ways to annoy me, proposing a startup as a part of solution for a problem you don’t understand well is near the top of the list.

Similar sentiments have been expressed previously during the project’s lifecycle; when first announced, several declared they could get it done within a four-month co-op term. This week, I was asked to explain why a Jobmine replacement is unrealistic for a year’s work. I had some procrastinating to do, so I jumped on the opportunity. (The title of this post is inspired by How to clone Delicious in 48 hours, which was written in response to similar reactions in December 2010.)

For those not in the loop, Jobmine is the online system supporting the co-operative education program at the University of Waterloo (UW hereafter). UW claims, with some justification, to operate the largest post-secondary co-op program in the world.

Jobmine was first introduced in 2004 and although an improvement over the previous incarnations, is generally agreed to be a horrible, horrible web application. Much of the blame lies with the horrible PeopleSoft software on which Jobmine was based hacked together. PeopleSoft promptly got itself acquired by Oracle next year. The horribleness was too much even for UW to handle and soon there were plans to do it all over again, but ourselves and better.

Disclosure: I was part of the project in the heady days of 2007 and early 2008. In 2007 I was prototyping and exploring and in 2008 I worked on a part deep inside the designed system. I haven’t been in close contact with the team since, and I have no insider information on the cancellation. I’m almost certain none of the prototype code is still active and although I’m not sure it wouldn’t surprise me if the latter code got axed or at least heavily reorganized since. That being said, I’d like to think that with the experience I understand what Jobmine actually is a bit better than the average student.

Here’s a brief guide to what a Jobmine replacement actually needs to do. Unless otherwise noted, this is the bare minimum to merely replace Jobmine, not improving on it much, presumably excluding the UI.

Student-facing components

You’ve probably seen this. Basic requirements are searching for, filtering, and applying to jobs. There are some caveats.

Specific students are allowed to see specific types of jobs. Co-op jobs are different from summer jobs are different from graduating jobs are different from alumni jobs. Some programs have their own separate postings: co-op pharmacy students can see jobs other co-ops can’t see, and then graduating pharmacy students can see jobs co-op pharmacy students can’t. You’ll want both positive and negative individual job filtering, the equivalents of today’s shortlist and a “I’ve seen this job and it doesn’t interest me, please don’t show it to me in any searches again” filter.

When can you search for jobs? When can you apply to these jobs? Is this calendar hand-entered by CECS every term?

You’ll want to devise a method of storing resumes agreeable to both CECS (representing employer interests) and students. Jobmine’s HTML solution has been much maligned, and not entirely without reason, as most students will find authoring HTML somewhat challenging and the Jobmine HTML processor was not written very well. PDF is a popular option in discussions, but it complicates things for those who don’t know how to print to PDF. PDF will also complicate the creation of ‘application packages,’ the combinations of your resume with co-op history and the academic transcript, which CECS and the employers like. You will probably want to at least accept a number of word processing software formats (.doc, .docx, .odf, .pages if you’re feeling generous) and convert them to the format you’ll end up using.

In the early plans of the project there was an initiative to do away with student formatted resumes and have students provide specific information on a section-by-predefined-section basis; this has advantages for employers (consistency of formatting, reordering sections to put the ones the employer feels most relevant to them near the top) and is more of a mixed bag for students (your resume won’t look terrible but it won’t stand out just based on formatting either). If this is still on the table, you’ll either have to implement this (likely along with a complimentary import from a number of file formats of your choosing) or convince CECS not to do this.

Have fun convincing CECS of anything.

You’ll want to devise a method for storing a number of resumes per student – more than Jobmine’s three would probably be a good idea – managing them, and linking resumes with applications. (What happens when a student deletes a resume they used to apply to a job?)

You need to handle interviews. You will want to notify students when they have been listed for an interview. Email is a good start but you will want to make this modular and expandable and seriously consider making SMS notifications part of 1.0. Selecting interview slots is the baseline, as is deselecting; because this is 2011, you might want to have a method of requesting and arranging slot swaps between students for better scheduling.

You need to handle rankings; nothing new here, you’ve probably seen this in action. This part is very heavily driven by CECS mandated functionality, so chances are you won’t have to change much from Jobmine.

Jobmine has functionality to submit comments about a work term evaluation; I don’t think this is heavily used and you could probably not implement this.

What happens after a work term? In some cases, you will be able to search for and apply to jobs while on a work term. In others, you will be on a school term but not able to apply. There is several dozen different possible streams of study-work sequences at Waterloo, and people fail or switch streams for other reasons. Do you have CECS employees do busywork keeping track of this, or do you decide to implement a complex mechanism to keep track of everything while still allowing for overrides and customizations?

Employer-facing components

The basics. Submitting a job posting for approval. When can you post jobs? Reviewing candidates once applications close, potentially with several passes – one to screen out the obviously unqualified, another to further cut down to candidates to interview. Come up with a snazzy but configurable way of displaying resume packages from applicants. Support both online reviewing and generation of some sort of printed packages – not all employers live in 2010s.

Submitting interview date and time preferences (day of week? AM/PM?). If you want to be good, submitting location preferences (interviewing in TC basement, I mean lower level, anyone?). Piggyback on previously created print functionality to allow for printing resume packages of the interviewed. Submit rankings.

After the work term, submit evaluations. Store and display evaluations on both student and employer-facing sites.

Oh yeah, somewhere between the student and employer sections, implement a method for returning to a previous job without it being posted and reapplying.

CECS-facing components

Approve job postings. Disapprove job postings. Will you ever have a situation in which a job posting has to be disapproved after it’s been approved? Cancel job postings. Repost job postings. For all of these cases, create appropriate views and displays in student and employer views. When can employers view applications their jobs might have? What is the defined behaviour of the students’ application limit, source of a Frankenbug/Frankenfeature in Jobmine?

CECS has to be able to enter text comments on essentially everything, starting from job postings, through interviews, to student and employer accounts in general. Students will communicate with CECS and CECS needs a ‘paper’ trail of these communications. Employers will definitely communicate with CECS and CECS definitely needs a paper trail of these communications. Do you want to be fancy and integrate or half-integrate the system with on-campus email servers so that, for example, CECS staff can send email to students or employers from within the system and have it show up in the paper trail? What about potential email replies from the students?

CECS field co-ordinators currently use a hodge-podge of systems to do their jobs, many of them home-grown by individual co-ordinators and nearly all of them duplicating data. They need to be able to keep track of students and employers, both existing and potential, in their coverage area; enter student evaluations, which will be visible to the students; enter their own comments on these evaluations, which will not be visible to students but may be visible to some other CECS staff; enter notes on general interactions with employers (expressed interest in hiring more next year, would like help attracting a different profile of students, etc). This role is actually being split into separate parts by a CECS reorganization, but your system will still have to do be able to do most of this, regardless of who’s going to be using it. Still, better have access control done up really nicely.

If you’re feeling fancy, design in methods for co-ordinators to access the data other than online via a website. Keep in mind the sensitive and private nature of the data in question. Can it be cached? Should it be encrypted?

How do students sign off jobs after their interview, how is this represented within the system, where are the notes about the reason stored and who can see them? If you’re feeling fancy, provide a way for students to sign off jobs before the interview as long as the employer hasn’t screened. Should CECS have to approve the latter? How is the necessary paper trail represented within the system?

How are interviews scheduled? How much assistance should a system built in 2011 give the CECS staff creating the schedules? What are the algorithms? What are the variables (again, TC basement)? How exactly do you handle the students that haven’t selected an interview time? How are you supporting multiple interviews per job (group interviews, flip/slide schedules), probably in different rooms and possibly on different days?

What happens when a student misses an interview? What happens when an employer misses an interview? Can interviews be rescheduled, what are the conditions in which they can?

Can CECS support staff assume the role of a student when accessing the system? How is this implemented?

Some students will need a certain amount of successful work terms before they can graduate. How will you keep track of the requirement? What happens when students switch? What is the format to provide this information to other on-campus systems?

Internal and systems driven components

How do you keep track of time? What defines when students can apply to jobs, when employers can screen applications and schedule interviews, and when employers and students can rank? Will each date be have to be entered manually or will you allow for rules to allow event X happen three business days after event Y?

You will have to get data from other on-campus systems. Student name and academic information from Quest is the obvious example. What’s the format of that data? Are there specifications? Is there sample fake data you can use while developing and testing, or will you have to create that? How often will the data change, are there modified flags or will you have to compare everything each time there is an import? Bonus: how do you handle name changes, including possibly username changes?

You will have to feed some data back to the network. At the very least, Quest needs to know students’ credit status for co-op terms. How is this data passed in? Does Quest have a testing area you can use to develop and test?

How is the student being “employed” defined? When is a student defined to have satisfied the co-op requirements of their degree, and who keeps track of this?

The matching algorithm will also have to be implemented, but luckily for you it’s very likely to be dictated by CECS so all you’ll have to do is implement it. Still, you’d better hope CECS has thought of absolutely every corner case.

Technology questions

How do users log into the system? It’s 2011, so you’ll probably want to use a centralized login for UW users. It’s UW, so you’ll probably want to make this modular to be able to swap login methods when the centralized login du jour changes (last I heard it was Kiwi, this has apparently changed since). How are employers handled? Can each supervisor at each employer have their own account so they can input the evaluation online? Is there a central manager at an employer who can add and delete these accounts? What happens when that supervisor account is deleted? What happens when the contact person for that account changes? For non-UW users, do you enforce password standards, which ones, and how?

In your web interfaces, do you handle multiple browser tabs/windows, and how? Do you handle the back button, what is the defined behaviour for precisely each possible case in which the user might use the back button, and how do you implement this?

Do you allow access via any non-web interfaces? What is the defined API for these? How is it secured? Will you allow only applications created by you, or third-party access as well – and if the latter, should you enforce data security, and how?

How does information flow out of the system other than the web interface? Automated email notifications? SMS/IM notifications? How does information flow back into the system?

What is your system design? Does everything run on one virtual server, one physical server, one HTTP server, or is there more? How is system communication handled? Is the system redundant? Does it hot swap? Can it handle a hardware failure? Can it handle 10,000 students applying en masse hours before the applications deadline?

What data storage method are you using? I’m not even interested if you ORM, that’s low level. How is the data backed up? Is it redundant? Does it hot swap? Can it handle 10,000 students applying en masse hours before the applications deadline?

You will be dealing with IST a lot. Who decides how the infrastructure for this project is connected to the rest of UW and the world? Who decides how it’s secured? Who is responsible for audits?

So yeah. Are you using Rails or Django for this?

Fine print

The above describes the co-op information system as it is imagined now. The majority of the functionality is probably necessary one way or another, but you might be able to convince CECS that some parts don’t have to included. If you decide to go that way, prepare to spend a lot of time in meetings. It’s not a very agile way, but it is what any project replacing Jobmine will have to deal with. (Jesse Rodgers reckons it might have been in part what killed the replacement.)

It might be nice if you’re able to just put a new interface on the student and employer-facing parts of the system. I have little idea how feasible this might be, but if thinking about this, remember that you are dealing with PeopleSoft software. Think what you have to go through to get your marks or your transcript out of Quest, another fine PeopleSoft product. Then consider taking the easy way out and riding the social bubble hoping to cash out on your .ly startup before the burst.

Because software engineering takes time.