An Inconvenient Truth

This page written circa New Year's Eve, 2011.

A priest never reveals secrets heard in the confessional, even ones that morally ought to be divulged. A doctor cannot be compelled to reveal what he hears from his patient without their permission. A lawyer's conversations with his clients are priveliged. An engineer, on the other hand, is ethically obliged to tell if he encounters, say, dangerous practice in the course of his work. I may lament my failure to have become a suit, and I admire and empathise with the magnificent Rake, but let's face it, my personality is better suited to transmitting information than concealing it. I would have been more likely to wind up like Cleaver than Harvey. Hence the ingenuous of the title.

Last year I spoke to Hugh Durrant-Whyte, lately of Sydney U and now CEO of Nicta. He remembered a conversation we had walking down Glebe Point Road. It was around the time I left Sydney U many years ago. I told him that I was not going anywhere else so much as leaving the EE department. That line conveyed a lot about the state of the place, a pretty candid summary, if not a detailed one. I think it is time for some candid tales of engineering at Waikato.

Story 1

On Friday November 25th last my PC died catastrophically. To be precise the HDD failed and the PC blue-screened and refused to reboot. Cardiac arrest, mid sentence. David came down and gave the last rites on the spot. He told me he'd start on the problem on the Monday.
It took the Computer Services Group (CSG), fielding David, two weeks to tell me that
(1) there had been an oversight and I had been omitted from the routine backup list, so CSG had no backups of my data or my system;
(2) the HDD was unreadable, so all the data was lost;
(3) they could find no record of the serial number of this PC in their database, though bought new for me when I arrived and still carrying its stickers, so even at 6 years and due for replacement in 2012, this would be a problem because it did not officially exist.
It is now almost January, and the best CSG has done is an old PC---I mean OLD, it has a floppy disk drive---fitted with an old HDD from a scrapped laptop, and running Windows 7, albeit staggeringly slowly. Not an acceptable solution.
The CSG mess has become a matter of common discussion amongst engineering (and other) academics, as this has been the level of service for at least the last year. This should not be my problem, but I have looked into it. My understanding, hearsay only, provided unofficially yet consistently by several employees and ex-employees, is that the problems reside in the two layers of command between David and the Dean, that they have remained unsuccessfully addressed for some time, and that there is a lot of nasty politics involved---caveat provocator!

Behind the scenes, I asked one of my marvellous grad students to look at the old drive and he was able to mount and read it on his Linux-PC right away, so I got my data off it, better than my personally-paid-for and personally-executed offsite backup that is a month out of date. When I returned from my travels just before Christmas, I went downtown, bought a reconditioned disk drive (Thai floods, HDD shortage), loaded a copy of XP and although several attempts to clone the old system failed, at least I have a system running and the data intact (and the "failed" drive mounted as a non-system volume). When David sorts the network specifics, I will be able to rebuild. Several weeks of unnecessary delay, several days wasted that should not have been wasted, let alone the work I am not doing for lack of my PC. I cannot see myself being back to productivity real soon.

(Postscript, Feb 15 2012: My new PC arrived in the building a week last Friday, and it arrived on my desk today. It also turned out that David had sweated hard in December and had copied the files from the old HDD onto the scrapped-laptop HDD. I missed that, and I apologise, but then I was not expecting them to be there. Still, 90 days to fix a problem that should take 90 hours must be some sort of record. It is to be hoped that the visit an academic colleague and I paid to HR last October will prevent David being used as a scape goat.)

Post-postscript, March 2012: I am not alone.

A colleague had similar service:
My old laptop was being replaced a couple of years back. Something happened and [the CSG person] said he couldn't transfer some files as the machine had some problem, so he decided to take out the drive and transfer them directly but then he couldn't get any data from it. Fortunately I had copied some recent and very important files on a external drive but some were lost for good. It was only then I realised not all files were being backed up. It happened quite some time back so I can't recall the details.

Another incident:
[Colleague] requested assistance from the helpdesk with software installation, the job was assigned incident number 89326, and the request was redirected to our man in FSEN CSG. On Tuesday, 6 March 2012 [Colleague] received the following message from the supplier: "I spoke to one of your colleagues today, David is his name. He said he'd fax through the signed LF, but I have not received it yet. ... Are you able to check and ask him to resend...", as a result of which [Colleague] then sent an email, copied to David and helpdesk (to whom the request was originally made), indicating that the job seemed to have fallen over. On the 8th of March [Colleague] received a response saying "this is a double-up in the job log as a result of emails being sent to ITS helpdesk as well. please dont do this as it causes confusion... Kind regards...". It appears that chasing an unfinished job counts as "doubling up". [Colleague] requested an apology. It was suggested that the doubling arose because he had included David on the CC.

Someone else contributes:
One incident I can remember is at the start of A semester last year. In our first laboratory (Monday 28th Feb 2011) we discovered that the print queue on our two computers in the lab (which are terminal clients that connect to Ferret, a Windows Terminal Server) was not working and none of the students could print out graphs. This resulted from an (understandable) oversight of the CSG when they shifted all engineering print queues to the Faculty print server but did not update our Windows Terminal Server. I went personally to talk to David (as we needed an immediate solution and fixing a print queue is usually an easy and quick job) but after 5 to 10 minutes trying to work out which server it was and how to log into it, I realised we would not be getting an immediate solution and explained to him that if it could not be done now the next time we would need it is for the Thursday lab that week. David said that it would be working by Thursday. On the Thursday lab (3rd March 2011) the print queue was still not working. I went to David, and found that: 1) He did not have administrator access to Ferret so could not do the job; 2) He did not pass the job on to Brett who is the administrator of said server. So the job was left undone.

Story 2

Engineering requires a decent amount of computer skills. All engineers use computers, and virtually all engineers have to do some degree of programming, from simple scripts to hard-core program design implementing complex algorithms and evaluating numerical solutions. Much more is required by EEs than, say, CEs, but all strands need some programming skills. Some universities send their students through standard computer science (CS) courses, others have computer science teach the CS-oriented parts set out in their curriculum, and others teach everything they need within engineering. One can use a variety of languages and environments, but scripting in Matlab, low-level programming in C and high-level programming in Java are easily the most needed, and the ones preferred by engineers in practice. I know all this because I have written a white paper (see here) in response to this situation.

At Waikato we send our students through a standard CS course in first year. Our problem is that over the last few years the CS course has changed, a couple of times, to use C# instead of C, and to lower the level of difficulty. This introductory course no longer delves very far into algorithms, and it omits many topics such as the command-line, indirection, and scripting. I suspect that all threshold concepts have been postponed in the interest of keeping the less-prepared students in the stream. Brilliant, possibly appropriate for CS, but not appropriate to engineering. This can be contrasted with, for example, UNSW where first-year students get under the hood of the unix kernel, or Auckland where C and Matlab are the opening fare. We desperately need to replace this lightweight course with one appropriate to engineering. Browsing Amazon uncovers books on just the subjects we want for engineering CS courses. Just up the road, Auckland University has the same degree structure and a perfect model for what Waikato should have. It is a no-brainer to clone the Auckland course and switch all engineering students across to that.

Incredibly, it has been "explained" to me that engineering does not have the power to specify the courses that comprise UoW's Engineering curriculum and degree. Computer Science gets a say, they would have me believe, and they are "likely to resist such a change" because it will have a negative impact on their finances. Hello? This is very Kiwi: People think everybody should have a say. Power and responsibility are chronically disconnected.

I spent some time worrying about this mess. I even have a marvellous email where, in spite of the academic staff overwhelmingly agreeing that a more appropriate course should be put in place, and the documented comments of students affirming the irrelevance and triviality of the current course---the last time to the accreditation panel---the associate dean specifically says that there will be no support for this change, there are "other things" to be addressed first. I describe this in the tea room as "polishing the door handles while the wheel nuts are loose".

Post-postscript, October 2014: This issue is still being thwarted. The faculty has grown a new layer---annoying science and engineering people alike---and this layer seems to be there for the purpose of telling everyone "you can't do that". I have all the paperwork, in the latest templates, to create the required paper and replace the COMP paper with the new paper... but there will be some new problem or requirement. They only have to delay a few weeks to push it back another year!

Why is the administration not focussd on, or interested in, graduate quality?

What to do? I am a bit tired of being the only guy who steps up to the plate. Fixing these matters is not my responsibility. I know when to stop caring. It's now. As the Christmas Message says, I worked too hard and played too little this year. It's time to play. New year's resolution.

| Home | Up one level |