It’s like criticizing your children. Because I like Apple so much I want to make sure they’re not doing anything that will be a problem later. And this comes from the experience of Apple nearly going out of business in the ’90s. They’re no longer that underdog, but I’m looking at everything they do and saying, “Are you doing everything you should in the way that you should? Are your products living up to the ideals you set for yourselves?” I don’t write these reviews of Windows. I could never muster up the enthusiasm or indignity.
The two markets where iPhone sales are effectively at parity with Android are the USA and Japan, and those are also the two markets where the subsidy structure means that the iPhones is not at a big price premium to Android. This is probably not a co-incidence. Meanwhile, we also see strong indications that the second-hand market for iPhones, mostly in the $2-300 range, is also extremely strong. It doesn’t seem unreasonable to suppose that a new, attractive iPhone in this segment would be highly competitive. So, such a phone would sell, and sell well, and take a big chunk of the most valuable Android customers. Not, of course, the ones who value ‘open’ and the Google ecosystem above everything else, but true enthusiasts are a minority on both Android and iOS.
I was recently reminded of an excellent post from back in 2009 by Brent Simmons called Anatomy of a Feature. In it, Brent walks through the seemingly trivial work required to add a “Save to Instapaper” feature to NetNewsWire. What seems at first like a simple call to a web service quickly expands into a number of non-trivial feature decisions that have to be made:
“Oh, it’s easy, just a quick http call. I could write a script to do it in like 20 seconds.”
But of course it’s not as simple as just writing a quick script. It’s tempting to think that adding a feature like this is just about adding the functionality — but there’s a bunch more to it than that.
So often people fail to grasp the inherent complexity of building software. In my line of work I often hear people talk about how easy it would be to throw in this or that feature with no regard to all the baggage that goes along with it. There’s very little intuitive understanding that software can be infinitely complex, that complexity is absolute poison to a software project, and that effective management of complexity is one of the key responsibilities of any project team. Even seemingly simple features can have implications that are far reaching.
Brent’s post is a really good examination of this issue viewed through the lens of a feature most software engineers can understand instinctively. It’s and worth a read if you work in or near software in any capacity, even if you’ve read it in the past. It’s a key principle that isn’t called explicitly out enough, yet it underlies so much of what we all do as part of software teams.