Train Drivers are Obsolete

In the UK, train drivers get paid A LOT of money. For one company, their base salary in 2017 was £49,001 (approx $65,000 USD). As a part of a pay dispute, they were recently offered £60,683 (approx $81,000 USD) for a 35-hour, 4 day week.

For comparison, the maximum base salary for an ‘ordinary’ police officer (i.e., below rank of sergeant, no specialisation) in London is £40,374 (approx $54,000 USD), for a 40-hour week, spread over a rotating shift pattern. Both roles are eligible for overtime but, for the police, when things go wrong – like when some whack job blows up a bunch of little girls at a concert – this can become a 60-hour week, WHICH THEY MUST WORK, OR THEY WILL GO TO PRISON. Yes, unlike many countries around the world, police officers in the UK are not allowed to go on strike. They cannot even talk about going on strike!

Now, which is more difficult? Driving a train for about 7 hours per-day (after all the rest breaks they get…), 4 days a week or being a police officer?

How about, driving a truck/lorry (44 tonne HGV; 16-wheeler) or driving a train? Well, the average salary for an HGV driver in the UK is £31,787 (approx. $42,500 USD), so, driving a train, right?

Well, how many fully automated HGVs do we have? 0. Zero. NONE. Yes, people are testing fully automated HGVs, but as of September 2017, no one has completed or even applied for regulatory approval to operate such a vehicle, without human supervision.

Ask the same question about trains. Well, according to Wikipedia, there are over 50 metro rail systems with lines that are fully-automated or automated to the point where a human just opens and closes the doors (which could easily be automated if there was the political will to do so). Even if this isn’t 100% accurate, it’s pretty clear that we’ve had the technology to safely operate railways without human operators for well-over 40 years.

Yes, I did say safely. Automated rail systems are safer than human-operated ones. The Docklands Light Railway (DLR), opened in 1987 has had some accidents almost all, including its most famous, were caused by human error!

In the 40 years of operation of the DLR, as far as I can tell, there have been less than 50 fatalities, all of which have been Person Under Train incidents, which were either suicides or probably unavoidable accidents. In that time, we’ve had Ladbroke Grove (1999; 31 fatalities, driver error) and The Santiago de Compostela derailment (2013; 79 fatalities, driver error), to name just two incidents caused by human error.

And this is even before I make the assertion, that, as a computer scientist, I can guarantee to you, that if you’re even seriously contemplating building driverless cars, then you have already exceeded the technology level required to implement a fully-automated railway network. I further assert that if you ask any computer scientist worthy of the name and they will give you same answer.

Why? If the evidence I have already presented is not enough to convince you, I can assure you that the difference in difficulty between implementing a fully-automated rail network and a self-driving vehicle is astronomical. If we say that a self-driving vehicle is the computer equivalent of landing on the moon, then building an automated railway is like building a bicycle. Yes, the difference between the two is that big! So big, in fact, that it makes by cry just thinking about it!!!

Re-inventing the Wheel

One of the most common criticisms of software developers is that we are perpetually re-inventing the wheel.

It (re?) occurred to me today that this probably owes a lot to the way programming it taught.

I would argue that any good Computer Science degree will aim to have it’s readers come away with an understanding of the principles at work. Now, in order to do this effectively (or at least demonstrate their understanding), students will have to implement much of the basic software that has been around for decades (sorting algorithms are a good example of this).

Of course, this is great for ensuring that you get really good Computer Scientists who can deliver real innovation and solve hard problems, but the disadvantage of this, is that they don’t practice doing what one would normally do InTheRealWorld™, which is find an existing implementation that is ‘good enough’ and work from there.

Learning to use software libraries is a skill in and of itself, as it often requires an understanding that may not be available immediately. This is partly an issue of design or (more usually) documentation, but there is also an element of experience; it requires experience to understand how other programmers think and how they build and design libraries.

I think that teaching needs to acknowledge this; yes, get students to write the fundamental algorithms, but make sure that you follow-up with a course that makes them use existing libraries, as this is how they will expected to work in the future.

Starting Cygwin ssh-agent at Logon

Common problem: you want to use ssh-agent with Cygwin, but because Windows is special, you can’t inherit the environment in the way you naturally would on a Unix or Linux system.

Now, before I proceed, understand that this is a HorribleHack™; it is the equivalent of modifying your .bashrc every time you login.

For this to work, you need to have the setx utility installed, which you need to download if you’re still using XP.

The first step is to save the following script; I put it in ~/bin/, but you could safely put it into /usr/bin as it only modifes the environment of the person who runs it. I used Python 3 because I could and because everyone should.

Next, create a shortcut in your Startup Folder. I called it simply “SSH Agent”.

The command line you will need (the Target field in the shortcut), is:

There seems to be an undocumented feature of run, that requires one to set the -p option to something or it will fail. Obviously, if you’ve installed the 64-bit version of Cygwin or put the start-ssh-agent script somewhere else, you’ll need to change your paths accordingly.

I haven’t written the symmetrical stop-ssh-agent, because I’m lazy and Windows doesn’t provide a convenient location to run scripts at log-off (you mess with group policies if you want, but I have more interesting things to be doing…)

Overcoming Intertia: Why YOU Should be Using Python 3

I despise change for the sake of change. Change for the sake of change is un-scientific. Change for the sake of change is a small person’s way of imposing their way on people.

I’m a fan of Python. I enjoy coding in Python; it lifts my spirits. I believe that Python is a good general-purpose scripting language, but more importantly, I believe that The Python Language is well-managed. By this, I’m referring to things like correctly managed backwards compatibility: a script written in Python 2.0 will work correctly in Python 2.7; there was a clear plan for migrating from 2.x to 3.0, which was adjusted in response to community feedback.

I’ve been using Python 3 for 3 years (starting with 3.1). If you’ve used Python 3, I suspect that, like me, you agree that it does what it’s meant to do: provide an incremental step forward over the 2.x series, while fixing some inconsistencies and oversights. This is the main reason I would encourage anyone who hasn’t already taken the plunge to do so; Python 3 is JustBetter™.

There is an additional reason, as the title of this post implies; unless and until “everyone” is using Python 3, “people” will continue to use Python 2. Unfortunately for Python 3, Python 2 is really good and much of the good stuff in Python 3 has been back-ported to 2.6 and 2.7. This has resulted in the paradox of technological inertia; an inferior technology persists, simply because it is ubiquitous.

Now, as I stated at the beginning of this post, I do not believe in change for the sake of change. Neither do I agree that all technological inertia is actually real (see dvorak vs. qwerty) and I’m not saying progress hasn’t been made (Django now supports Python 3, for example), but the default python is still Python 2 on most systems that I’m aware of and until that changes, we all have a responsibility, I believe, to push for that change.

I believe that it’s just as important, if not more important, that we push for the small changes where we can, because big changes are more often than not an accumulation of small changes that happen all at the same time, yet they are more difficult and more disruptive (and often less successful) – you only need to look at recent events, such as those in Egypt or Syria for evidence of this.

By embracing the small changes, we make life easier for ourselves, not more difficult.

Computers don’t like Mondays Either

Back from Holiday and I have two emails (amongst many, of course). The first, to my personal address, is from a colleague notifying me of an error she encountered accessing a company Website for which I am responsible (and that when she tried to send it to my work address, it was bounced by the mail server). The second, to my work address, is from my boss, forwarding the original message I’d already received but which also included the bounce message.

Interestingly, both of these errors (a database connection error for the first, a 554 Relay Denied for the second) appear to have been transient and occurred around the same time this morning. This makes me think of the notion of Ghosts in the Machine – the idea that as software systems become increasingly complex and/or have been installed for a long time, they develop unexpected (emergent) behaviours that makes them seem temperamental; that they develop their own personalities.

Of course, it’s just a textbook case of anthropomophisation and could almost certainly be explained by something as mundane as a temporary spike in traffic, but you know, there is something strangely comforting in the thought that Computers don’t like Mondays Either.