Tag Archives: Computing

Innovation department

When I see a company that has an “innovation team” or a “chief innovation officer” I immediately understand that it’s not the kind of company I want to work for.

Innovation isn’t found in a particular team, person or department. It’s your culture.

If you need a special team outside the normal management structure to innovate, what does that say?

iTunes Match — addendum

Since I wrote about iTunes Match nearly eighteen months ago I thought it was worth revisiting and seeing how things have changed in that time.

Oddly, the short answer is “not very much.”

The problems that I identified last year are still very much present. Indeed there are some new examples. This is my favourite: when listening to “Man Machine” by Kraftwerk, iTunes Match seems to have decided that track four, which should be “The Model,” is really “Wouldn’t it be nice” by the Beach Boys. I don’t even own a copy of “Wouldn’t it be nice.”

The biggest changes in those eighteen months have been on the client side. iTunes 11 (the lipstick on pig release), as far as I can tell, didn’t change very much. iOS 6 wasn’t nearly as fortunate. The point zero release removed the ability to delete individual tracks. Not exactly progress. (It’s back again in 6.1.)

Apple likes to talk about its magical products that Just Work. iTunes Match tries to be more magical than most but clearly missed a few visits from the faeries.

One bit of magic that I thought was supposed to happen was that when getting low on disk space, iTunes Match would delete less played tracks. In fact, what I think happens is that it removes older, cached tracks.

The distinction here is between cached and downloaded. If you press the download (cloud) icon it isn’t automatically removed; if you didn’t it is.

But how do you tell? Well, that’s the other major client flaw. There’s no easy way to see which tracks have been downloaded without opening each album, one by one. I have six hundred albums which makes this an exceedingly tedious task.

My guess is that you’re supposed to use it by just pressing the Play button and have iOS manage the space for you. But this would mean you live in a utopian universe where you have a data signal every time you want to play some music. That does not resemble my life.

What I want it to be able to download tracks that I think I’ll want to listen to and then allow playing from the cloud. When low on space it should remove tracks that have not been played recently regardless of how they got there.

So eighteen months on I find that many of the same problems remain and I’ve found some new ones, yet I still paid for another years subscription without much though. Why? Well, it’s still very useful. I like being able to play music using my Apple TV. I like being able to access any of my music when I have wifi or 3G. I just wish Apple would spend a little time and make it less like a 1.0 release1.

  1. You could argue that they added iTunes Radio, but that only comes with iOS 7 — nearly two years after iTunes Match came out — which isn’t out yet and even then that will only work in the US to start with. []

iOS 6

Like all the best upgrades, iOS 6 is almost entirely invisible. It works just like iOS 5 — which is to say, pretty well most of the time — but with some convenient new additions. Also, unlike version five, it’s been relatively stable throughout the beta process.

What’s new and what will you like? I’ve grown so accustomed to most of them that I had to look up the “What’s new” page on Apple’s website. Really, that’s a good thing. Invisibility is the fate of a feature that’s quickly integrated with how you use a device. (The thing that makes it tricky is that it’s also the fate of a completely useless feature that you never use.)

Roughly ordered by how much I like them:

  • Do not disturb. This is the one feature that the Blackberry had that I missed in iOS. I only had a Bold for a few months but being able to switch off “work” between certain hours was brilliant, and the same is true of Apple’s implementation. You set a range of hours and it automatically mutes. This feature alone is worth updating for
  • Shared Photo Stream. This will be even better when I can share directly with other people’s devices, but being able to create a web gallery of Photo Stream pictures has already proved to be useful
  • iCloud tabs. This feature sat idle until Mountain Lion and then… great. The only thing I would ask is for this to work on my iPad!
  • New options when receiving a phone call. The “decline but remind me later” is a great option

Stuff I’m ambivalent about:

  • Maps. Apple switched from using Google’s maps to their own. I miss Street View but otherwise all the functionality seems to be there. Searching for stuff seems a bit hit and miss, just like with Google Maps. Search results differ but I’ve not used it enough to determine whether one is better than the other
  • Siri. I have an iPhone 4 and an iPad 1, the former of which doesn’t support Siri, the latter of which doesn’t support iOS 6
  • Passbook. This might be great when there are apps to support it. Right now, a waste of a spot on my home screen
  • FaceTime over 3G. Not sure if it will be supported in the UK. Rarely had the need to call when there’s been no WiFi

The only “bad” I can think of is that it doesn’t run at all on my two year old first generation iPad. I understand technically why they made this decision, but at the same time it’s a little galling to have such a relatively recent device be declared obsolete.

In conclusion, this is one of Apple’s “refinement” releases. They seem to have a big update (iOS5, Lion) and then a release that fixes some of the rough edges (iOS6, Mountain Lion). 2012 has been a year of two spit and polish releases. I’m not complaining.

Mountain Lion — The Good, The Bad and the Ugly

I’ve been using Mountain Lion, the new version of the Macintosh operating system, for less than a day so this isn’t intended to be detailed (see John Siracua’s review) or thorough. I have, however, kicked the proverbial tyres so here are a few, quick thoughts.


  • Probably the most stable 10.x.0 release I’ve used
  • Little earth shattering but lots of really nice improvements, not all of which I’ve seen documented (for example, attachments in Mail now appear in the “All My Files” view in the Finder, multiple Time Machine disks)
  • Notification Center works well; AirPlay mirroring is going to be really useful
  • I’ve not found any software that worked in Lion that no longer works. That includes stuff like VMWare (scary because it’s low-level) and Photoshop Elements 6 which is not listed on Roaring Apps compatibility list


  • You’re not going to be able to make the best use of everything until iOS 6 comes out. This is a bit of a pain if you own a first generation iPad and know that this will never happen…
  • The installer got confused. After “less than a minute remaining” it went to “-1 minutes remaining.” It got to -7 before finally resetting to twenty minutes. It worked in the end so clearly this isn’t a “show stopper” but anything weird in a process that reconfigures your system is disconcerting
  • I launched Mail. It upgraded my database successfully and then, while I was making a cup of coffee, crashed. It’s been stable ever since, but first impressions and all that
  • Every time I click on Messages — the new iChat — it opens the instant message (“Messages”) window. Do Not Want


  • The font in the new Notes app. What were they thinking?!
  • If you didn’t like the iOS-ification of Lion you’re not going to like Mountain Lion any better. But if that’s the case you’d probably start thinking about migrating to another platform!

But overall, at less than £15 it’s a no-brainer if you use your Mac a lot.

Programming Is Hard

It’s hard to explain to someone who is not already a programmer the kinds of things that you have to do when building an application. The thing you’re trying to explain is often very abstract and the answer frequently would involve lots of code.

That’s why I thought this particular problem might make an interesting discussion. In talking about this very simple problem we can talk about the things that developers deal with every day and, hopefully, the process can be followed by most people who have used an iPhone (or, actually, any computer). You won’t be a programmer at the end but you might have a greater appreciation for what happens behind the scenes.

The basic problem can be seen in this screen shot.

The login button is a toggle. That is, if I’m currently logged in it says “Log out.” And when I’m not logged in it says “Connect,” which is “log in” in Facebook parlance. A subtlety that you might not ordinarily notice is that when the user clicks the button, the keyboard should move out of the way when it’s not needed and come back again when it is.

There are two basic cases to consider:

  • When I’m not already logged in. In this case pressing the button opens the login screen and the keyboard should shift out of the way.
  • When I am logged in, pressing the button just logs me straight out. In this case the keyboard can stay where it is.

Easy, eh? (That’s what I thought when I started, too.)

Let’s sketch out the code.

when the button is pressed
  if I'm not logged in then
    make the keyboard move out of the way
    log in
    log out

This is called pseudo code because while a computer can’t actually execute it we’ve broken down the processing into the required basic steps. You’ll have to trust me when I say that the real code (called Objective-C) isn’t terribly different.

Not so hard.

Except… you didn’t really think it would be that easy, did you?

It turns out we’re missing one important detail from our algorithm.

One thing we do a lot when programming is use pre-existing components (standing on the shoulders of giants as Isaac Newton, or Oasis, would have it). When you write a component you’re going to come at the problem with some specific ideas of how it’s likely to be used. Hopefully these ideas are the most common ones as this will make everyone else’s life significantly easier.

In this case, our button — a pre-existing component that I didn’t write — is a clever one. It already “knows” how to log in and log out of the service. This sounds like a great time saver and it simplifies our algorithm to just this:

when the button is pressed
  if I'm not logged in then
    make the keyboard move out of the way
    do nothing

Only, it turns out that that doesn’t work.

Why not? Well, the implicit assumption in the above pseudo-code is that it is run first, that is, before the instruction to log us into or out of the service. But if the button logs us out before any of my code is run then no matter whether I was logged in or not before I pressed the button, the above code will find that we’re logged out and move the keyboard out of the way.

When you’re writing a user interface you find dozens of these tiny little details getting in the way of what you’re trying to do. Any non-trivial screen will have lots of these little problems, and the worst thing? No-one will ever know. If you do your job well no user will ever see these little glitches.

Talking of which, how do we eliminate the anomaly that we’ve just found? The solution is pretty simple. At the moment we’re trusting that the button “knows” whether we’re logged in or not. Instead, we’re going to have to take responsibility for doing that as well. That adds a little bit of complexity but isn’t too scary:

  • When the screen opens we need to check whether we’re logged in or not and remember that. In Objective-C we call that a “variable,” but really that just means something that we’re going to store and access again later
  • Later, when the button is pressed we can use the following pseudo-code:

    if the value I saved says that I'm not logged in then
      make the keyboard move out of the way
      change the stored value to "not logged in"

  • When I’ve finished logging in — remember I could press the cancel button in the log in screen — change the stored value to “logged in”

And that’s it, we’re done. We have a working version of the log in button.

The final point I’m going to make here is that I ended up discarding all the code above. It just didn’t work as well as I wanted and I ended up implementing it in a completely different way. And this really is the kind of detail that you never notice. A good chuck of any programming project is prototyping, building mock-ups and other activities that don’t directly end up in any shipping product. All this discarded work — which does, at times feel like a waste of time — is designed to make the product better.

Some people who have never programmed say things like “there’s nothing complicated there” or “it’s only a button!” Hopefully this post has shown that even a simple button can be far more work that it initially seems.


“Do you ever change this type of trade?”

I was sat on the trading floor discussing a new feature that I was implementing with the person who would be using it the most.

“No, never.”

This was one detail of the change that would have far-reaching consequences in the code. A “no” would mean a few days of development, a “yes” would indicate several weeks.

“Are you absolutely sure? You don’t change it even once a month?”

I knew they’d like the smaller estimate but, equally, I knew that I didn’t want to end up trying to implement several weeks worth of functionality in the smaller time frame. I’ve seen that kind of thing happen too often.

“John1, we don’t ever change these trades do we?”

John was the head trader. If anyone would know it would be him.

He rubs his head and leans back, thinking.

“Why would you want to? No, I can’t see us ever changing one.”

Of course, you can guess what happened thirty minutes into the first trading day with the new software.

So, what happened here? Why did we get the requirements so wrong? And why did we only find the mismatch after the system was moved into production?

Both the problem and the solution is the same thing: communication. Or more precisely, communicating using the right language.

Some developers are happy to only “speak” technical, proud that they are masters of their programming environment but ignorant of their users problems or how they really use the software.

Above I started out correctly, I was trying to understand the traders business and talking in terms of booking trades, positions, legal entities and a bunch of acronyms that would make even less sense out of context.

But I made one error: I used the word “change” without defining what I meant. I meant, well, any change. And so did they. Yet they didn’t consider moving a trade from one book to another to be a change and, unfortunately, I did.

You’d like to think that there were checks and balances in place to make sure that this kind of thing didn’t happen. And there were. In addition to informal and formal testing, there was over a week of “parallel running,” where the traders had to use the old and the new system together and check that the results were the same in both of them.

Were there any moved trades during this time? Of course. Why did the traders not notice? Well, it was about right; the differences, while present, were explicable and so not considered significant enough to mention even though I asked to hear about any problems at all.

So, again, communication. Or at least human nature. I wanted to hear about any differences but they tried to help me by only talking about differences that they couldn’t account for.

What’s the answer? Well, I’m not sure there’s an easy one. “Understanding your user” is a short, simple phrase but hides so much. If you spent the time to fully understood their job you probably wouldn’t have the time to do your own. But finding the balance is crucial.

  1. Names have been changed to protect the… well, they work for a bank so I hesitate to say “innocent” but you know what I mean. []