Category Archives: Opinion

Thoughts on computers and the IT industry.

App Store pricing

Like Spotify’s complaint before it, yesterday’s “App Store Principles and Practices” document from Apple got me thinking.

Apple talks a lot about free apps not paying anything (which isn’t entirely true of course), and it’s always pitched as a feature.

But the more I think about it, the more I think it might be a bug.

This effectively means that all paid apps have to subsidise all free apps. Is this what’s preventing Apple from reducing the 30% fee?

Why should free apps get a free ride? How much value is Facebook getting from Apple? My apps don’t take your personal data and use it for advertising purposes — something that Apple seems to be in favour of — yet I have to pay 30% and Facebook pay nothing.

Of course, we have to consider unintended consequences. It would be fair for Google and Facebook to pay, but what about a game I wrote in my spare time? Or that useful utility I wrote for myself that I’m altruistically sharing?

I don’t know is the short version. Should they charge for each download? Or each App Review? They’d probably need exceptions for certain categories, but also to be very careful that the system doesn’t get gamed.

The other thing Apple doesn’t directly address is Spotify’s most compelling argument: the fact that Apple charges 30% commission for apps that provide digital services, such as streaming music or books, means that no one other than Apple can actually allow in-app purchases in those categories. Apple only allow in-app purchases with the fee yet many of these services just don’t have 30% “spare” that they can give Apple. Apple Music and Apple Books don’t have to play by the App Store rules and they don’t have to pay the 30% fee.

If anything, this is harder than than the free freeloaders problem. It doesn’t seem right that Apple couldn’t compete in these categories, yet the platform owner clearly has a huge advantage here.

Anyway, at least two issues here and no firm conclusions. They always say “bring me solutions, not problems.” Sorry, I failed.

Fragile Development

The problem with “agile development” is that it is both a methodology and a buzzword. What this means in practice is that people who do not understand it implement parts of it without appreciating the whole. This usually results in more overhead but without the benefits.

I’ve come across this multiple times in my career. The usual refrain is “we’re agile so we don’t need documentation.” The “agile” aspect is more often than not, merely the assertion that the project is agile. Or someone says that the code is the documentation.

Another common one is “we need to improve communication so we’ll have have a daily stand-up.” This often ends up being an opportunity for senior managers to give ten minute monologues about what they might get up to if they didn’t have so many meetings to attend. (Cue unheeded calls for sympathy.) Updates from people at the coal face often get cut due to time pressures. After a few weeks people stop attending…

Agile as it was originally designed was clever because it went up against the common wisdom of the day by jettisoning certain elements of bureaucracy but balancing them with other carefully considered, and hopefully less onerous, procedures. Less documentation might work if you increase the amount of teamwork; less formal requirements gathering is counteracted by including a user in the team; regular cadence of releases means you can get away with less rigid planning.

The common trait in the examples I gave is that they lack that balance. Not writing documentation is a mistake if there is no other method of retaining knowledge inside an organisation. Poor communication is not solved by managers broadcasting how out of touch they are.

As with any problem, you can’t fix it if you don’t understand it.

iOS 12

As I’ve done for the past few years, here are a few thoughts on the new version of iOS that will be heading to your phone in a few days. Usual caveats: my usage patterns are probably different to yours, I have a 6s and iPad mini, not whatever weird and wonderful hardware you have. I’ve been using the beta on my iPad since early August and on my iPhone since late August.

The good

  • Stable. I’ve had a couple of minor glitches but, honestly, there have been worse release versions. (They have been fixing new APIs and suchlike so I’m not saying they should have released earlier. But I am saying that the GM version should be pretty solid.)
  • Performance. As advertised, it works well on my far-from-new devices, probably better than iOS 11. I didn’t buy into the whole battery-gate scandal but if this is the result I’m happy with it.
  • Siri suggestions. I’ve not seen the full benefits yet, since I’ve not finished writing my own and haven’t been running anyone else’s beta software. But even just with Apple’s suggestions it’s nice. I go to the gym and it suggests my “gym” notes document. I think this is going to be big when more apps support it.
  • Do not disturb. I already used it a lot and now it’s better. DND until the current meeting and DND until I leave the current location are both super useful.

The bad

  • Nothing. Really. Sure, there are things that I would change or do differently, but there’s nothing that I would really look at and say “That’s worse than iOS 11.” If you’re okay with iOS 11 there’s no good reason not to update.

The ugly

  • What’s with the time and battery indicator being jammed in the very top left and right of the iPad screen? What a waste of space.

Final words

You’ll note that “Screentime,” Apple’s answer to the accusations that people are spending too much time on their devices, is not on the list. I don’t have anything bad to say about it, but I didn’t find it very useful. I have my smartphone addiction under control. I could stop any time I want to…

Pro is not a useful label

Here is goes again. Apple announces new MacBook Pros (or there are rumours about a new Mac mini pro) and the hoards pile on it saying it’s not a “Pro” machine. But what does that actually mean?

Traditionally the label “pro” is short for professional and is used to describe people who make their living using the tool. Sadly that definition is so ridiculously broad that it’s not terribly useful. What does a video editor, a writer, a 3D modeller and a software developer have in common?

Nothing.

Some need a fast CPU, others lots of memory, or storage or ports or GPU. Others just like the “best.”

And that’s the problem. We have to stop fixating on it being short for “professional.” It’s a marketing term, nothing more. It doesn’t mean anything beyond “expensive.” Just because it’s missing a feature that you’ve grown accustomed to does not mean that it’s not usable by professionals. Maybe it makes it unusable by you but that’s not the same thing at all.

If you work on a computer, buy the one the best meets your current and anticipated future needs. Whether that’s a MacBook or a Mac Pro, a Mac mini or an iMac Pro, even a Windows PC, the name doesn’t matter.

And if none of the computers in Apple’s current line up meet your requirements, that might legitimately be a problem. But, it’s not a new problem — Apple has had a relatively limited range since at least the late 90’s — and that still has nothing to do with the name.

iOS 11

As I’ve done for the last few years, here are a few quick thoughts about today’s new iOS release, version 11.

I’ve been using the iPad version since the beginning of August and the iPhone version for only a couple of week but I think I have reasonable picture of what you’re going to see. 

Good

  • Multi-app support on the iPad. Wow! It’s quite different. You might need to give it a while before you get used to it. I also found that I needed to rearrange my dock so that apps I use to multitask are quickly available
  • “Swipe up on the iPad keyboard to get symbol characters.” Such a time saver
  • The voice synthesis of Siri is way better. But I agree with Gruber, if I could have dedicated engineering resources to Siri that wouldn’t have been where I would put them
  • iCloud sync for Photos. No more training each device to receognise each person!
  • Lots of nice, minor changes. The “Now playing” lock screen widget, the “play” button at the top of playlists/albums in the music app
  • Control Center is improved (but see first item in the “ugly” section below)

Bad

  • I’m guessing this has something to do with the iPhone X, but the one 3D Touch gesture I used all the time was the hard-press on the left side of the screen to trigger the app switcher. That’s gone in iOS 11. This is going to take a lot of getting used to
  • It won’t work on older devices. I get the “why” but it always sucks when they get left behind

Ugly

  • Why did the WiFi button is Control Center change to be “disconnect” rather than “switch off”?!
  • Not sure about some of the animations, especially on iPhone. 

What do you know?

How do you interview people for developer and technical jobs? This is an enduring question, and one with many angry factions.

It’s too big a subject to tackle in its entirety and I have no intention of trying. Instead, I want to talk about one aspect: should you ask Computer Science questions or not?

In one corner are the people who argue that you never need to implement a linked list or write Quick Sort in real life, so asking you to do that in an interview is unreasonable and excludes good candidates. They argue that there are more important things to consider, such as the use of applications frameworks or design or working with other people.

In the other are those who say that algorithms are a fundamental part of writing software and, while you may not need to write a Quick Sort, you do need to understand it and to be able to explain it.

The first group calls the second elitist. The second calls the first naive. Who’s right?

Of course, I come at this with my own bias. I have a Computer Science degree but I did it some time ago and don’t have perfect recall on this stuff. Ask me the Big O notation for Quick Sort and I’ll understand the question and maybe make a stab at the answer, but I’m not going to pretend I’m 100% sure.

There are two main angles I want to consider: the intent of the interviewer; and the knowledge a developer actually needs to do the job.

Let’s start with the former.

So, your interviewer asks you to implement a linked list on a whiteboard. Why? What are they hoping to find out about you?

If the answer is… well, the answer, then I’m very firmly with the “you don’t need to know this stuff” crowd. People tend to want a specific answer when either they want a cookie cutter computer science graduate or they wouldn’t understand the answer.

Alternatively they might be trying to see how you think; how you’d start with a simple solution and build up; how you’d test it. In these cases, the answer is less important than how you got there.

Another thing to consider is that, as an interviewer, you want to get the most information in the least amount of time. Starting with a “real” business problem might require too much context to be explained before you could really start. But the candidate hopefully already know what a linked list does, even if they’ve never had to write one.

Of course, sat in a conference room with a stranger it’s very hard to tell which of the two camps your interviewer falls into (and practically impossible if they’re on the phone).

So that’s pretty inconclusive. There are good reasons to ask but you can’t tell whether that’s the case for your interviewer.

So how about job requirements?

This angle is easier. Most jobs don’t require standard algorithms that you’d come across in a computer science or software engineering degree. A knowledge of user interface frameworks probably is more useful for many projects.

But what about the rest? There are jobs where knowing algorithms is important. On projects where low-level or performance intensive code is required understanding the fundamentals can be important. Maybe you’ll be writing a game or something with very low latency requirements or an engine that processes vast amounts of data.

In my last project I deliberately avoided using the system provided Quick Sort and implemented my own Heap Sort. I may not have been able to tell you the Big O notation for heap sort and quick sort, but I do know that quick sorts’ Achilles heel is that it works poorly on already sorted data. (It’s only fair to note that they didn’t ask me about algorithms when I interviewed for that position. In fact, they didn’t ask me much of anything! That’s a long story for another time.)

I’m not saying that you need a Computer Science degree to know those things. I’m not saying that the project would have failed without that background (though the fact that someone knew saved tens of thousands of pounds in hardware costs). And, most importantly, I’m not saying that the kinds of projects that you do are anything like mine. I am saying that the people who say this stuff isn’t useful or important are wrong.

So what do we conclude?

Well, firstly, and most importantly, no one size fits all. Your interview process needs to be tuned for the kinds of position you’re trying to fill.

Secondly, if the only questions are about linked lists and sort algorithms, that’s a big red flag. These aren’t the only interesting subjects for any job. If you’re not at least asked about how you work in teams, you should be worried.

Finally, having said all that, you can’t escape from the fact that programming is about algorithms. According to Wikipedia:

Programming involves activities such as analysis, developing understanding, generating algorithms

You should be expected to understand and to be able to explain algorithms.

But you should also understand team work, several programming languages, relevant frameworks, user interface design, source control, your IDE, the Unix command line, security, Linux, web servers, leadership and management, the film that the line “pop quiz, hotshot” comes from and know the correct answers to “tabs or spaces?” Developing software is hard and has many facets.

Focusing on any one aspect to the exclusion of others is a mistake. And that’s true both for you as an individual and you as an employer.