Reduce noise

delete-recycle-bin

I am a big fan of deleting things. Sometimes I go too far. In the past, I’ve deleted things that I’ve needed and not been able to recover them. But I still think it’s the right thing to do.

There’s an article by Ned Batchelder from over 10 years ago, that I still think is relevant today:

If you have a chunk of code you don’t need any more, there’s one big reason to delete it for real rather than leaving it in a disabled state: to reduce noise and uncertainty. Some of the worst enemies a developer has are noise or uncertainty in his code, because they prevent him from working with it effectively in the future.

  • A chunk of code in a disabled state just causes uncertainty. It puts questions in other developers’ minds:
  • Why did the code used to be this way?
  • Why is this new way better?
  • Are we going to switch back to the old way?
  • How will we decide?

You’ll always have a battle on your hands when you try to delete things. People don’t like doing it. It’s similar to trying to throw out physical things (something I also try to do). People just have a natural hoarding instinct. Maybe it dates back to our hunter-gatherer days. After we’ve spent days or months hunting wild bits of code and bringing them back to our cave, it can be difficult to bring ourselves to delete them.

It’s because we remember the effort we put into writing the code the first time. But deleting code is part of writing code. It’s the same with writing prose. As EB White said, “writing is rewriting”. And coding is very similar. In particular I think of William Shrunk’s advice in The Elements of Style:

Omit needless words.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell.

Advertisements

Apps and Websites

I have mixed feelings about apps. There’s an XKCD comic that pretty much sums up my experience:

xkcdapps

It’s quite common to come across apps that are just content from the website but in a more limited container. You can’t interact with them as you would with webpage content. Sometimes you can’t copy and paste from them or use  features that have been in webpages as standard for twenty years.

People who are familiar with computers tend to forget that most normal users  are worse with computers than we think. I once told a story about a project to build an appstore at work:

A colleague of mine had to give a presentation about a Corporate iPhone AppStore that we’re building. Half way through, he realised the audience weren’t feeling it, and so said, “Who here knows what an appstore is?” About four people put their hands up.

The excellent web app Forecast.io has a blog that talks about the confusions people get into when trying to pin their webclip to the homescreen:

I’m fairly certain none of them will ever know that Forecast is actually a web app. To them, it’s just an app you install from the web.

Users don’t really understand what they’re doing. Instead they do get frustrated and confused when things don’t behave when they expect. The user who wrote in to Forecast.io was confused that he couldn’t download the web app from the Apple Appstore.

Apps are too much like 1990’s CD-ROMs and not enough like the Web. I feel like I’m always updating my apps. Every time I pick up my phone there’s a little red box next to the Appstore, telling me I have more updates to download.

Perhaps it’s my OCD coming out, but I just can’t leave the updates sitting there. I have to download them all. But if I ever look at the reason for the updates, I see it fixes an issue like “error with Japanese timezone settings for people living in Iceland” or “fixes an issue when you plug an iPhone 1 into a particular model of ten year old HP TV” that I’ll never encounter. Sometimes they change apps so they no longer work in the way I’ve got used to.

It’s probably worth adding: I’m not complaining that they’re fixing problems. Someone in Iceland is probably on Japanese time. And even if they’re not, I’m idealistic enough to think it needs fixing just because it’s wrong. The problem is the nature of apps. I never have to update Amazon.com before I buy a book, or update Facebook before I poke someone. Websites don’t need updating. They are always the latest version.

There are, of course, some good things about apps. Jeff Atwood wrote about how much better the ebay app is than the website. An he’s right. It’s slicker, simpler, easier to use:

Above all else, simplify! But why stop there? If building the mobile and tablet apps first for a web property produces a better user experience – why do we need the website, again?

But maybe the solution here is to build a better website.

Of course, some apps carry out functions on the device, or display static data. And it makes sense for them to be native apps. On my iPhone, I have a torch app (it forces the flash on my camera to remain on), and I have a tube map app (it essentially shows me a picture of the tube map). One of these interacts with the base firmware, so that one has to be a native app. The other displays static data. It would be unnecessary to connect to the Internet to pull the map down every time I want to look at it.

But other apps, like Facebook or LinkedIn are just a native wrapper around the website.

So, what’s the solution?

Of course, there isn’t one. It’s a compromise. At the moment we’re in an era obsessed with native apps. All companies have to have an “app”, if only just to show that they’re up to date.

I was in the pub the other day and accidentally got chatting to someone. He told me that his company had just released an app. “What does it do?” I asked him. “No idea,” he said, “but you’ve got to have an app.” He was the managing director of the company.

Hopefully, when we’ve got over the novelty of the technology, we can start using apps for what they’re good at, rather than just having apps before they are there.

A lot happened on 1st January 1970

WordPress

If you’ve spent any time playing with code and dates, you will at some point have come across the date the 1st January 1970.

In fact, even if you’ve never touched any code, you’ll have probably come across it. I came across it today when I was looking at the stats on WordPress:

Hits

Bizarrely, the WordPress hit counter starts in 1970. Not so bizarrely, no one read my blog that day. But then they were probably all so excited by Charles “Chub” Feeney becoming president of baseball’s National League. Or something.

Most likely, this is caused by the Unix Timestamp, a number I wrote about the other day. As I said, time is a real faff, but numbers are great, so computers sometimes store time as numbers. Specifically, the number of seconds since midnight on the 1st January 1970. It’s a real oddity when you first encounter it,  but it makes a lot of sense.

It’s not, though, the only way of storing time. Microsoft, typically, do it a different way, and use a value that’s affectionately known as Integer8, which is an even bigger number. This is the number of nanosecond intervals since midnight on January 1st, 1601.

With both of these, you need to do a calculation along the lines of:

January 1st 1970 + number of seconds

To turn the number into a date. Of course, this means that if you report the Timestamp as 0, the computer adds 0 to January 1st 1970, and gets January 1st, 1970.

Presumably, it’s something along these lines that have resulted in WordPress reporting me hit stats from 1970. According to computers, a lot of things happened on 1st January 1970.

The Unix Timestamp

Time and Dates

Time is a bit of a faff really.

If you want to add 20 minutes to 6:50, you get 7:10. Not, as you would with normal maths, 6:70. I remember at school putting calculators into “clock mode” to add times.

I also remember spending a surprising amount of time during my sound engineering days adding and subtracting times. There was a brief period when I was convinced that we needed to decimalise time; change the system so there are 100 seconds in a minute and 100 minutes in an hour. It will be a bit of a faff for everyone, but if it saves me from having to do slightly tricky mental arrhythmic occasionally, then I’m all for it.

It turns out that computers, similarly, have difficulty with time. Which must be partly why many computer systems use the Unix Timestamp.

The Unix Timestamp is a number. A really long number, like 1369634836 or something. But, ultimately, just a number. And this means that adding and subtracting from it is easy.

The number corresponds to the number of seconds since midnight on 1st January 1970. 1369634836, for example, corresponds to seven minutes and sixteen seconds past 1 AM on 27th May 2013.

Funnily enough, though, the Unix Timestamp was invented until 1971, meaning that the first few thousand numbers only ever occurred in the past. Dates that are before January 1970 are recorded as negative numbers, so theoretically it can go back as far as you want.

These days, the Unix Timestamp is used in loads of, if not all, computer languages.

In javascript, you can generate it with this code:

new Date().getTime();

In PHP:

time

And so on.

Now, I don’t mean to alarm anymore, but there is an apocalypse coming. Well, I say apocalypse, it’s more just an expensive and inconvenient problem. But on January 19th, 2038, we’re going to have another “Millennium Bug” situation, when the Unix Timestamp gets so big that it cannot be stored in normal (32-bit) computer file systems.

Before this time, we’re either going to have to switch to using 64-bit systems, which support much bigger numbers, or using a different method for storing dates. That is, assuming we there are any 32-bit computer systems still running from today.

Even when we switch to 64-bit systems, though, we’re only prolonging the problem, not solving it indefinitely. At 15:30:08 on Sunday, 4 December 292,277,026,596, we will again run out of numbers. Luckily, though, as Wikipedia notes “This is not anticipated to pose a problem, as this is considerably longer than the time it would take the Sun to expand to a red giant and swallow the earth.”

Which is slightly more of an apocalypse than the dates not displaying correctly on websites really. But I’m still more worried about the date thing than the sun thing.