Tom Fosdick

I’ve run into a few people recently who’ve told me that the Y2K problem, aka The Millennium Bug was a hoax. In some ways the issue was, but let’s get one thing straight, the bug was very real and if we hadn’t done a hell of a lot of work to fix it, things would have gone catastrophically wrong.

What was the problem then? In the 1950s every tiny piece of computer storage was critical. Programmers were always looking for ways to store and process information more efficiently. They didn’t think for one moment that their code would ever have to deal with the year 2000, so they decided to lop the “19” off the front of the year and just store the last 2 digits. 1958 was actually stored as “58”. If the user needed to see the full year then many systems simply printed “19” before the 2 digit year.

This wouldn’t have been much of a problem if it hadn’t made it out of the 1950s. Unfortunately every new generation of the tech industry builds on previous generations. Not only did the 2 digit year become a kind of industry standard, it also got baked very deeply into the code that actually ran the computers themselves.

By the time the 1990s rolled around there was an awful lot of computer code about and people started to realise that a lot of it was going to have to deal with the year 2000.

Suddenly You Find You’re Not Insured…

Let’s look at an example. Let’s say you renew your car insurance. The new policy starts on January 2nd, 1999. Now, you’ve been lucky, this computer program uses 4 digit years so you correctly see your expiry date as January 1st, 2000.

Unfortunately the database that all the records are stored in only uses 2 digit years, so the system writes a start date of 02/01/99 and an expiry date of 01/01/00 into the database.

The problem is obvious: when that record is read back the system will correctly convert 02/01/99 to January 2nd, 1999, but it will wrongly convert 01/01/00 to January 1st, 1900. Congratulations, as far as that computer system is concerned you’re not insured.

In that simple example you’d hope that, at some point, a human would see it and realise something had gone deeply wrong. The problem is that, even in 1999, there was an awful lot of processing going on, in financial systems even in safety critical systems, before the results ever got anywhere near a human.

The Ariane 5 rocket explosion was caused by a similar problem. The guidance system was capable of producing a much higher number than the main computer could deal with. This hadn’t been a problem on Ariane 4 because it couldn’t do anything to cause such a number to be generated. Ariane 5 however could and 37 seconds after main engine ignition on June 4, 1996, it did, ultimately causing the rocket to self-destruct.

That’s why we had to fix the Y2K bug, because pretty much everywhere there was a date in computer code there was potential for things to go badly wrong.

It Wasn’t Just Dates…

What’s more, it wasn’t just the obvious cases we had to worry about. There were more subtle implications of the bug. Consider the following output from a little example program I wrote. It gives you the expected arrival time of a plane and its current altitude both in feet and metres.

 SIGN    DATE            TIME    ALT(m)  ALT(ft)
 Y2K00   1990/11/01      00:00   5000    16384
 Y2K01   1991/11/01      00:35   4900    15872
 Y2K02   1992/11/01      01:10   4800    15616
 Y2K03   1993/11/01      01:45   4700    15360
 Y2K04   1994/11/01      02:20   4600    14848
 Y2K05   1995/11/01      02:55   4500    14592
 Y2K06   1996/11/01      03:30   4400    14336
 Y2K07   1997/11/01      04:05   4300    14080
 Y2K08   1998/11/01      04:40   4200    13568
 Y2K09   1999/11/01      05:15   4100    13312
 Y2K10   19100/11/01     05:50   4000    49
 Y2K11   19101/11/01     06:25   3900    49
 Y2K12   19102/11/01     07:00   3800    49
 Y2K13   19103/11/01     07:35   3700    49
 Y2K14   19104/11/01     08:10   3600    49

There’s one thing you might expect, that when it got to the year 2000 it printed out 19100. The program stores the date as 2 digits and simply prints “19” in front of them. That was a pretty typical Y2K bug: the 2 digit year ticks over from 99 to 100 and it gets printed as “19100”.

What might be surprising is that after the year 2000 it completely screws up the calculation of how high the plane is in feet. The calculation before the year 2000 is (approximately) right. Afterwards it just prints “49” however high the plane is.

This is because, when I wrote the program, I only allocated enough storage for 2 figures in the year. When it came to after the year 2000 however, the program wrote 3 figures regardless. What it did was to write the extra “1” to some storage that was being used for something else – in this case to store the height in feet. 49 is the value a computer would send to the screen if it wanted to print the number 1.

Again, in my little program this gets printed to the screen and you’d hope that someone would notice. What it highlights however is that the problem caused can be somewhere else in the code and affect something other than just the date. This corrupted value could be the radiation dose of a chemotherapy patient and it might never get seen by a human before its delivered…

I hope that makes it abundantly clear that the Y2K bug was very much real and that the consequences could very definitely have been catastrophic. The idea that the bug could have caused planes to fall out of the sky is not and was not scaremongering. It was entirely possible. Indeed if we had somehow sleep-walked through to the closing minutes of 1999 without realising there was a problem it was a relatively likely consequence. We did however realise and we did a hell of a lot of work to fix the problems.

Now of course it’s true that the press over-hyped the situation. The headline “Renowned industry expert says that thanks to years’ worth of effort it’s now exceedingly unlikely that there will be any critical incident in the aviation sector” doesn’t make much of a headline. “Boffin says planes could fall from sky” is going to sell many more newspapers.

On the back of that hype there was also the predictable bunch of spivs and con-merchants offering to Y2K-proof your toaster. I’m sure you get my point; some people capitalised on the ignorance and panic by spreading more misinformation and making a pretty penny out of fixing things that didn’t need fixing.

That doesn’t lessen however the seriousness of the real underlying problem. It was, as they say, “a biggie”.

So It Definitely Wasn’t a Hoax… Or Was It?

There is however a certain thread of logic that says, even considering everything I’ve written, it was still a hoax. It’s a line of argument I actually quite like. For the tech industry it certainly wasn’t a hoax, it was very real indeed. For the government too – the government needed to make sure that adequate provisions were being made to fix it, to mitigate any remaining risk and deal with any problems arising.

As far as the general public were concerned however, they were never actually exposed to any significant level of risk. It was inevitable that we – the tech industry – would fix all of the serious issues well before they came into play. There was nothing that the people on the Clapham omnibus needed to worry about. In fact, being perfectly brutal about it, there wasn’t really any need for them to ever know about the problem at all.

Much as I like it, I don’t entirely subscribe to that school of reasoning. Even as midnight ticked over we couldn’t be sure that we’d fixed every critical bug. There was still a risk of things going badly wrong and the general public needed to be aware of that.
There’s also an argument that it was public awareness that actually made a lot of the tech industry sit up and take notice :- that’s when the senior management of these businesses finally realised that what the technical people were saying was right.

Did we need people predicting that planes would fall from the sky and toasters would stop working though? No, we definitely didn’t. What we needed was common sense. What we got was the British Press.

The question of how much data allowance Primordial Radio uses has been asked a few times.

The simple answer is about 30 megabytes per hour, which means 1Gb of data will last you about 33 hours.

If you’re interested, the not so simple answer goes as follows.

Primordial are cunning, they use a 63KBit AAC stream. The bit rate is, quite literally, how much data per second the stream uses. The higher the bit rate, the higher the quality of audio that can be squeezed in. It’s a trade-off between data and quality. But there’s another factor – the technique used to encode the audio.

If Primordial used a 63Kbit MP3 stream it would sound dismal, because MP3 is actually a pretty old and inefficient audio encoding technique. Because they use AAC, they can get away with a much lower bit rate, which keeps the amount of data you need to use to listen to Primordial low and the quality acceptable.

BBC Radio 3, in comparison, have a 320Kbit AAC stream (amongst others). You can get your Classical Music fix in super-high quality, but it will munch 150 megabytes per hour.

Now, the relationship between the bit rate and the amount of data it uses isn’t entirely straightforward. In data transmission we tend to talk about bits per second and when we talk about data allowances they’re in bytes, or more likely Gigabytes.

Your broadband connection, for instance, is almost certainly specified in Megabits per second. Long story short, the reason is that the bit is the smallest thing that can be sent, so it’s most accurate to talk about the speed of a connection as bits per second.

A byte is almost always 8 bits, but some types of communication use extra bits to regulate the transmission, so it’s not always a straight 8 from bits per second to bytes. It’s close enough for a ready-reckoner though:

63 / 8 = 8 (roughly)

We need 8 kilobytes of data for one second of audio. We can then easily multiply that up.

8 *60 = 480Kbytes per minute

480 * 60 = 28800Kbytes per hour

A megabyte is 1024 kilobytes, so:

28800 / 1024 = 28Mbytes (per hour)

This, however, is always going to be optimistically low. Firstly there is the problem of the envelope. Data over The Internet is sent in billions of packets. You can think of each packet like a… um… packet. You can’t just lob a bottle of Hendricks in the postbox and expect it to get anything other than drunk by the postie. You need to wrap it up in something, put an address on it and pay postage if you want someone to actually receive it. There are similar overheads on the The Internet.

There are various different systems in use, often there are several layers of content and packets. This means that there is a lot more traffic on The Internet than just the useful data.

There is also the problem of packet loss. A small amount of data on The Internet just disappears. This is actually expected, it was designed that way because it’s easier and more resilient. What it does mean however is that a small amount of data has to be sent twice.

You can pretty much account for all this by simply adding a fudge factor. 20% is usually considered a safe margin. If we take our theoretical figure from earlier:

28 * 1.2 = 33.6MBytes per hour.

This, of course, is an estimate based on a bit of theory and some practical experience. If you don’t trust these kinds of calculations, you could just look at the speed on your router’s data rate table.

If you wanted a bit more accuracy though, you could listen to Primordial for, say, 1/4 hour, record the amount of data every packet contained and the overall length of the packet, then add them all up.

You’d have to be a right geek to do that though.

The total data received was 8150537 bytes, of which 7247617 was useful content. Those can pretty easily be multiplied up to an hour:

Total audio and related data: 27.65 megabytes per hour.

Total data exchanged: 31.1 megabytes per hour.

Naturally I can’t guarantee these figures absolutely. They’re over Wi-Fi rather than a mobile network and there will be differences. There will also be differences between different networks and even different times of day as The Internet itself changes and adapts to the traffic.

What I can say is that they should be somewhere near, within a few percent.

Reading Time: 4 minutes

In the words of a certain radio station, “Social media can be a force for good, but it can also be a giant pain in the arse.”

When I wrote that First Class Post was the most rapid form of communication of which I approved I was only half joking. I recently spent two weeks in India. Rather than deal with the expense of roaming or hassle of a local SIM I just turned mobile data off. It was a surprisingly liberating experience.

It’s not like I dropped off The Internet completely: there’s free WiFi in most hotels and a few restaurants. What I found though was that having Internet access time-boxed had a far greater effect on the way I lived my life than I could ever have imagined.

I’ve spent pretty much my entire career in communications, most of it trying to improve the connectivity and communication technology used by the emergency services. I’d always kind of assumed that more connectivity and more flexible communications were a good thing.

It’s true – the increased ability to communicate can benefit us very greatly. For instance, we’re now talking about the ability for members of the public to stream video directly into an emergency service control room. That information could be hugely useful to the call-taker, in informing the member of the public, in informing the crews being sent to the scene and also providing an evidence trail for any followup action.

On the flip side however, as I’m sure you can imagine, the ability to stream video from a remote location to another, particularly via an end-to-end encrypted channel, facilitates some of the most appalling people in existence.

To a lesser extent the same is true of social media. It enables us to keep in contact with people that we would otherwise naturally lose touch with, but it also throws up conflicts that we would never otherwise have. On top of this the social media companies themselves aren’t making money unless you’re using them. They make every effort to ensure that their platform invades your life as much as possible.

Over the past year or so I’ve become utterly frustrated with this: I’ve disabled all notifications from every social media app on my phone. What India taught me however is that this isn’t enough. If I really want to take back control from social media, I have to remove myself from the social media environment and only step back into it on my terms.

Social Media is not a new thing, it existed back in the dial-up days. The difference was that to be online you had to make a phone call, and the costs could mount up if you weren’t careful. You had to set limits, for purely financial reasons (especially if you were on a trainee’s wage).

So I’m setting usage limits again.

Just before we left for India, my partner and I were in a restaurant and the couple next to us spent the entire meal on their phones. They barely talked to each other. The first rule therefore is:

No phones at the dinner table, wherever that dinner table is: in the house; in a restaurant; a picnic table in a field; etc.

If I’m out and about doing jobs or visiting people, the chances of me needing to call someone are fairly high, but the chances of me needing a smartphone are fairly low. The second rule:

Unless there is a clear reason to take the smart phone out, take the dumb phone [see above photo].

The penultimate rule I call the “Soap Opera Rule”. In many ways Social Media is like a Soap Opera, the two differences are that it deals with real people and that it’s constant, it doesn’t come in half hour chunks 3 times a week. The former is somewhat the point of Social Media. The latter is something that you have to manage and it helps if you think of it more like a Soap Opera:

Set clear daily usage limits and don’t exceed them.

Of course there are exceptions to every rule. When we’re talking about usage limits we have to consider what the purpose of usage is. If you’re organising a family meal via WhatsApp that’s not the same as reading your Twitter timeline.

The key here is be sensible and maintain perspective.

The last rule is the simplest of them all:

Talk to people.

Social media is no way to conduct a friendship. Sure, it’s a great way to allow you to find people with common interests and to keep touch with people who you would otherwise lose touch with. Those people aren’t your friends (although they may have been or may become so). Ultimately, friends are not people you broadcast status updates to. Friends are the people you have a conversation with when you have news.

So call them, invite them round for tea, go to lunch with them, go watch a film with them but interact with them directly and personally, not via timelines and group chats.

From now on I’m going to be following these rules. In reality you probably won’t notice any difference, but I think it’s going to make a big difference to me and I hope these words make a difference to other people.

Remember that it’s in the interests of the Social Media companies to create a society where it’s socially unacceptable not to be glued to your phone. Don’t sign your life over to them: take back control and always, always be true to yourself.