When I went to university, I found myself studying Physics at the
University of St Andrews in Scotland. This
worked out very well for me: I can wholeheartedly and unreservedly recommend
St Andrews as a place to study. The
School of Physics
is chock-full of great teachers and researchers, and my understanding is that
the rest of the university is at the same calibre.
Unfortunately, the University also uses a marking scheme that I have chosen to
call The World’s Most Confusing Marking Scheme. It is so complicated that
I have devoted an entire section to trying to explain it to you. If you aren’t
interested in the absurd complexities of the University of St Andrews’ marking
scheme, skip to the section entitled Mitigate The Problem.
How Hard Can Grading Be?
Most universities grade individual modules and items of work on a percentage
scale. This system is easily understood, and makes it simple to evaluate the
relative differences in achievement between individuals and modules.
St Andrews, however, only takes the brightest of students, and it attempts to
challenge them in every possible way. This means using the The World’s Most
Complicated Marking Scheme. Allow me to explain it to you.
Let’s begin by considering examinations. Each department (or ‘School’) sets
its own examinations. These examinations are marked out of some number,
defined by the School. The more sensible Schools (cough cough Physics) mark
exams out of some number that goes into 100 nicely, like 50 or 100. The less
sensible Schools mark out of some weird number, like 72.
The examination mark is converted into a percentage. At this point it would
be perfectly possible to report this percentage to students and then call it a
day. However, the next stage is actually to convert this percentage grade to a
grade on the so-called ‘20 point mark scale’. This scale is a number between
0 and 20 inclusive, with a single decimal point allowed (so isn’t that a 200
point mark scale?).
So far it’s complex, but not complicated. It’s easy to establish a linear
relationship between a percentage mark and a 200 point mark scale. However,
what happens next is utterly bizarre. Rather than use a linear conversion,
a non-linear conversion is used. This means that the difference between 30%
and 40% is different on the 20 point scale to the difference between 80% and
90%.
This is absurd. What is more absurd is that, as far as I can tell, these
conversions are not the same from School to School. The School of Physics
publishes their conversion rates (though the table is buried deep inside a PDF
document), but I’ve been unable to find a published version of any other
School’s conversion. Additionally, many of the Schools in the Faculty of Arts
don’t do the percentage grading, but instead grade straight onto the 20 point
scale! This makes it impossible to determine accurately what it means for a
student to have gotten a 16.
It gets worse, though. In the UK, most degrees are what are known as
honours degrees.
This definition of ‘honours degree’ is not the same as that used in some other
countries (e.g. Australia), by the by. Anyway, the crux of that meaning is
that, upon graduation, your degree is given one of the following
classifications: First Class Honours, Upper Second Class Honours, Lower
Second Class Honours, Third Class Honours, and Pass.
In Universities with sensible marking schemes, a percentage grade is set as
the boundary between one classification and the next. At the end of the degree
you take an average of your modules (weighted by how many credits they were
worth), and wherever you fall defines your classification.
In St Andrews, you do that too, except you take a credit-weighted mean of your
20 point scale grades. Additionally, the university defines 0.5-point-wide
‘border zones’ where your degree classification depends on your median grade.
And not just any median, your credit-weighted median.
Needless to say, this mathematics rapidly becomes something that is not easy
for students to do. Lots of students assemble spreadsheets that do the mean
easily, and then struggle with the median. Later in my university career, an
Excel spreadsheet started doing the rounds that could do the median, but was
using macros (Macros! In this day and age!) to do it. This seemed absurd to
me. People who weren’t familiar with Excel struggled with the spreadsheet, it
looked like ass, and needed to be emailed around the student body. It had to
be possible to do better.
What’s The Worst That Can Happen?
It occurred to me that I have just enough knowledge to be dangerous on this
front, so I went ahead to try to build a web app that would help. The result is
here. The name isn’t exactly snappy, but it’s
fairly attractive and works pretty well.
This was my first introduction to Javascript: before beginning to write this
app I had never written a line of it. This blog uses only Javascript written
by others (namely Google and Disqus), and so I didn’t really know the first
thing about it. Still, I knew that I wanted there to be a dynamic number of
modules, and short of forcing the user through an extra web-page for them to
POST a form telling me how many modules they did, I would have to manipulate
the DOM, and that means Javascript.
With that in mind, then, I decided I should aim to scale as well as possible
while keeping costs as low as possible. This means a static site using one
dyno on Heroku, which makes my hosting cost zero. I
used a sub-domain of my blog domain, which means no domain registration fee. I
hosted the single minified CSS file on S3, which costs almost nothing to host
and serve. The only other way I could think of to improve scalability would be
to cause all the calculation to be client-side, in the Javascript itself.
The user would already have to download some JS, which means they’d already
have to hit S3 twice, so the only cost increase would be bandwidth and storage
of a larger JS file. Because the calculation is client-side, my Heroku dyno
can process requests incredibly quickly, as it will only ever take a single
request from a given visitor.
The only downside is that Javascript isn’t usually all that fast. However, it
turns out that, for this relatively simple calculation, Javascript is ‘fast
enough’. Neither I nor anyone I’ve spoken to has noticed any lag with the JS,
even on mobile devices. Altogether, Javascript is probably faster for the user
than having to POST onto the server and have it do the calculation!
All that I needed to do then was wrap the static index.html page in the
thinnest Heroku-suitable client I could find (in this case,
Sinatra) and viola! A fully functioning web app,
from conception to completion in about 8 hours.
Mitigate The Problem
Why bother? Well, the app has some major
advantages over the Excel spreadsheet. For one, it’s a lot more approachable
for non-technical users, especially those who are unfamiliar with Excel. It’s
also easily available, without requiring an installed copy of Office, and
works on mobile devices. This makes it widely usable by the student body.
This wide usage base is important, because, and I cannot stress this enough,
this should not be a problem students face. The fact that I was able to
identify a problem and build something that actually helps in 8 hours suggests
that the university has made a serious faux pas with the grading system. In
the event that a university official swings by this blog (unlikely, but
possible), it’d be great if you’d drop me a line to explain why you use a
system this apparently-braindead.
More importantly, though, it gave me an opportunity to mitigate the problem.
I have personal experience of students, myself included, being irritated by
attempting to work out what class of degree they can expect. I can’t fix the
issue, because I don’t work for the university, but I can contribute something
that makes peoples’ lives a little bit better. This gives me the warm fuzzies,
so that alone was worth it.
Finally, several personal firsts for me. I wrote the CSS entirely from
scratch, which I’ve never done, and so I now have a much better idea of what
it’s like to write CSS. I now have some limited experience with Javascript,
which is great, although I’ve still got work to do on this front. In
particular, I want to write some tests and clean up the Javascript: it looks
ugly to me. This is also my first Ruby app (although, honestly, it barely
counts, as it only uses Sinatra as a thin shell over the index page).
All-in-all, I’d call the development of this app a productive use of 8 hours,
wouldn’t you?