This post was originally shared on Medium in 2016. With all the anti-trust action currently happening in both the US and Europe, it’s still quite relevant. In some ways, things have not progressed very much at all!
Given the things that Google *didn’*t say in their response, I wonder if they agree? Contrary to some commentators, I think what they do goes beyond playing hardball. I’ve no idea whether that’s illegal but they’re certainly not being nice to their “partners.”
A few years ago I had a job where every new recruit would go through a long process of shock and gradual acclimatisation to the main software product.
What it did doesn’t matter as much as how it was built: it was an application developed on top of a proprietary programming language and user interface designer. The reaction was always the same. Why? Why?! Why would you reinvent Visual Basic on Unix? Why would you inflict a programming language even worse than Basic on developers?1
I’ll be honest: I wanted to like “Facts and Fallacies of Software Engineering” by Robert L. Glass more than I did. I’m not sure if it’s dated badly — it’s from 2002 — or I was in the wrong frame of mind, or something else, but it just didn’t work for me.
The book is structured as a list of facts grouped around areas such as “Management” and “Requirements.” For each fact, there is a discussion, the controversy, and then the sources and references. The writing aims to be friendly, but I found it a bit grating1.
I confess that I’ve stolen the title of the post from elsewhere. My objective here is not to detract from that post, which is great, but to build on a few points that I thought it was going to make but didn’t. To make it clear where I’m coming from, here’s a Tweet that I wrote some time before I read that blog:
People who complain that “enterprise” software is too expensive have clearly never come across the bizarre, arbitrary and nonsensical policies and rules these companies have. It’s not unusual to have two customers with contradictory policies.
I greatly enjoyed Graham Lee’s series of posts about specialisation versus generalisation in software engineering1, quite possibly because it’s me.
My background is a little different from Lee’s, though, so I thought it was worth sharing.
I have a two tier experience2. With a few minor blips, Unix has been a constant technology underpinning since my first year at university. I started using Linux around the time 1.0 was released. I got a Mac when — or possibly before — OS X was ready for mainstream use because it was Unix with a nice UI. At work I’ve seen the change from big Solaris and HP-UX machines, to Linux, to containerised applications (which are normally based on minimal Linux distributions). Sure, the different Unix variants are not exactly the same, but most of them have something bash-like and ls does the same thing everywhere, even if the more esoteric options vary.
I made the mistake of suggesting that there was a blog to be made from this tweet. This is that post.
People still underestimate the value in (Developer|Operator) Experience when building platforms and honestly it’s kinda shocking to me.
If you want to win mindshare you need to make your tools actually usable. If you don’t want to lose it you need the same.
As happy as I am with the way that my new app, CameraGPS, a GPS logger application for people who want to geotag their photographs, came out I can’t say that it’s exactly as I envisioned it at the start of the process.
The idea was something like this: many of the GPS logger apps in the App Store require you to either use iTunes file sharing (who connects their iPhone’s to iTunes any more?) or mail yourself the exported document or sign up to some third party fitness or trekking website. Mailing yourself stuff just didn’t feel very slick and I didn’t want to record my trails for fitness purposes.
It seems that there’s a large variation in people’s experience with iCloud and iTunes Match, Apple’s recently introduced service for making your entire music collection available across all your devices. At the risk of making things worse — since I have nothing conclusive to add — I thought that I’d add my anecdote to the collection.
Like most software — and especially Apples — it works best when you work in a particular way. It’s often difficult to tell how close your expectations are to the real thing until after you’ve handed over your credit card. But what I will say is that iTunes Match works pretty well if you want to do what I do. So if you read nothing else in this post, you should look at the next few paragraphs.