Take

Jason Snell, in The Talk Show, as transcribed (and ably commented) by Marcin Wichary:

The new features with problems is not a crime. It happens. The crime is: they never fix the problems.

And that’s the part that I would like to see Apple get better at: if you’re going to launch something, you got to maintain it. Sometimes I feel like Apple is willing to spend the money and time and effort to launch something, but then they’re not really willing to do anything other than walk away.

And I think that’s irresponsible. If you can’t stand by that feature, you shouldn’t launch it.

This is a good summary of Apple's software issues, but that might somehow only be one interesting aspect of a fractal subject.

If you stand back a bit, you see wires going back and up and off into the horizon.

You see Apple adopting a cadence of annual releases, with annual hardware features with gimmicks that are only supported in annual software updates.

You see a treadmill of software advancement, which forces every app on every app store to be a constant commitment. There are excellent reasons (security and bug fixes) to treat it as such, but Apple in particular can enforce a run-to-stand-still mindset.

You see the fundamental organization of app stores and subscriptions subsuming whatever independent logic developers may wish to use, to schedule their own major upgrades. Why? Because you can't be caught out in the middle of a big-bang upgrade when you have to adopt to something, and because the ergonomics of even having major upgrades are terrible, another sacrifice at the altar of uniform App Store simplicity, the practicalities of which trip up even Apple.

You see a rat king of consequences, all from adherence to cult-like ignorance of complexity, as if those who are sufficiently pure of mind do not need to acknowledge and wrestle with what their decisions have wrought.

Believe it or not, I am an adherent of taking things slow and building incrementally, picking off small pieces and solving small problems. I see it as one of the better tools to focus on what needs to be built. It is easy, saying these things, to be boxed into being The Guy Who Wants It To Be 2009 Again. I don't. (Well, maybe except for world politics.)

The issue really, that Jason pins down, is that it's so easy to use incremental development, agile development, sprints, whatever, as a method to do the wrong thing. If you have a year-long schedule, it is easier to say "I will take care of the Finder", and within the scope of that is a number of features that need be built, but there's also room for ongoing maintenance. Within the confines of sprint planning, within a culture that sheepishly focuses on the wrong thing, or is obsessed by following the wrong number, or worries about the internal politics of appearing to not have it together, all of a sudden the same work, scheduled into 3 week long sprints, looks like poison.

I know of plenty of organizations that make this work. That have the maturity and discipline and culture to see bugs and defects for what they are, to allocate plenty of time to them and to focus extra time on them with regular intervals.

Apple, apparently, does it every 17 years; maybe once a decade if iOS 12 also qualifies. While I applaud that they do it at all when they do it, I can't give their approach a passing grade.

I don't have a conclusion as much as I have a sense of dizzying comprehension that all these things are interconnected and some of them cause some others. Things were always going to have to be more complicated as the world got more complex, and the ability to ship more updates is fundamentally a good thing.

But we are constantly stepping on rakes that needn't have existed. It will come down to people realizing what the prudent thing to do is and making the grown-up decision to support quality and respect their customer - in a world focused on driving profit, conversion and business metric by hook or by crook, where when the platform vendor does it, it's not immoral.