Systems Programmers

Let's have a change from ranting about problem students and instead rant about people who program the central university computer systems. Every university has such programmers: they do a very vital job maintaining various computer systems that allow students and staff to access university information, like timetables, course information, exam results, that sort of thing. The computer systems typically allow access via web pages, or from using software that everyone has access to.

I'm sure there are a lot of people who program these systems who do a very good job, and most of the work they do is unsung, because the rest of us in the university only notice when the systems go wrong. But sometimes, it can be very frustrating trying to communicate with some of the systems programmers and you feel like you are banging your head against a brick wall, because they just fob you off with excuses or give nonsensical replies to your queries and suggestions.

This is particularly frustrating on the occasions when you, as a computing lecturer, do know what you are talking about: often you are treated as if you are not a computer specialist and know no more than the average office worker. Don't get me wrong - I realise that they know about the internal workings of their systems and I don't, and in some areas of computing they probably do have a lot more practical knowledge than I do. I don't have this lofty ivory tower opinion of "I'm right and they are wrong", but I do get frustrated when their responses are unreasonable.

One sort of unreasonability I find is a view that is too programmer-centric and not enough user-centred. Time and time I see this in my students, too. When practising their programming skills they are much more concerned as programmers with what's easy to program, and when producing some software, they will value the easy-to-program route over the better-for-the-user route, even when a primary focus of the software is supposed to be that it's easy to use.

Yesterday I indulged in a mutual rant with a colleague about how unreasonable some of the systems programmers at our university can be. My current biggest pet hate is about how they structure the information in such a way that it takes much longer to get to it than it should. They have put all the information that I don't want to get to in an fast-to-access place, and all the information that I use 80% of time in a slow-to-access place. With all the accesses I make, this soon adds up.

I'm sure I'm not the only one, I found out my colleague yesterday thinks exactly the same thing, and I'll bet most of my colleagues find the same thing. Not only that, it's very easy to program a solution. You'd think it would be a clear-cut case, because the solution is easy to implement, quick to implement, and fixing this can improve access times without disadvantaging anything else. But have they done it since I asked them about it a year ago? Have they cocoa.

See, they have let-outs. The university computer system programmer's standard excuses:

• "That's just your opinion."
  No matter how much objectivity and fact there might be in my comment/request, they try and paint it as my subjective opinion. They try to imply that just because it might make my life easier it wouldn't necessarily make it any easier for anyone else in the university. Thus they dodge the issue, because I'm only one person pointing out the problem, rather than coming to them with a lengthy petition signed in blood by all the lecturers I can find.
• "It's too difficult/time-consuming to implement"
  Another standard let-out is that it's too difficult to implement, with the implication being because I don't understand their programs, then I don't know how difficult it is to implement, so therefore I'm in no position to say otherwise. It is true that I don't know the inner workings of their programming, but it's still irritating, particularly when I give them a concrete suggestion of an easy way to implement it, and they don't address my suggestion, either by saying why that's not possible or by explaining why it's more difficult than it sounds.
• "It's not possible because of ..."
  Standard fatuous reason, usually bringing in some other factor, some reason which you can't prove false. Typically with a reason like this you later discover that their reason can't possibly be right because they did something later on which contradicted it.
• "We have too much else to do."
  Again, I'm in no position to know whether this is true or not. However I believe them. They probably do have a lot to do on their plate. Which is why I try and provide constructive helpful suggestions which could help speed things up.
• "We'll put it on the list of things to do."
  The ultimate condemnation. That's like the in-tray which doubles as a rubbish bin, yes? When a year has gone by and still nothing's been done, somehow I don't believe you put it on a list of things to alter like you said you'd do.

Why do I somehow believe that they just think I'm a troublesome ignorant user who would just make their life easier if I never made suggestions to them? (And no, I do not bombard them with suggestions, we are talking about maybe two issues per year here.) Why can't there be a culture of welcoming constructive polite suggestions as ways to improve even better their systems?

Wish me luck when I try again to see whether they will do something about this issue of access speed...