Turns out that making useful software is surprisingly tricky. Take "Magic Marker", the program that we used last week to help out with the marking of the first year coursework. It was simple enough to write, it just finds the coursework from a archive downloaded from the university learning environment, sets up a spreadsheet for the marking process and then puts all the comments back into the correct format for upload. I made it last year and it worked fine. For me.
This year I built it out a bit for use by five markers working in parallel. My plan was to slightly extend the program to merge back all the marked work. This turned out to be surprisingly tricky. Not because of the difficultly of the task, I had the code working in double quick time. The thing that caused the grief was that if you introduce more moving parts into a system the number of ways it can fail goes up exponentially.
This is something I've experienced before. It takes you ten minutes to code up the bit that does the work, and a day to cope with all the fiddly ways in which the program can go wrong. For example, at one point in the assessment process you have to copy the mark from the spreadsheet into the marking took. Of course I forgot to do this for a couple of folks and so my program got upset as a result. So I had to figure out how to mitigate this and then build it into the workflow.
The good news is that having lots of students provides a great way to shake down the solution, and I now have a solution that will be useful going forwards. But this took a bit more coding than I expected. Remember, when you are writing code that the "Happy Path" will probably take you around 10-20% of the development time.
When you are designing the workflow for a system you need to identify all the ways that it can go wrong and then specify what should happen in each. This is something that I tell everyone on the Systems Analysis course, and perhaps I should have followed my own advice a bit more at the start of this job.
