Sign up with your email address to be the first to know about new products, VIP offers, blog features & more.

Understanding Apple at scale | iMore


Every year, at the end of the year, I go over what I consider to be the biggest problems facing Apple. Last year, just before New Year, I wrote about the challenges of scaling:

All of the issues I’ve outlined above are really facets of the same problem: scaling.

Once upon a time, Apple made desktop computers. Now, Apple makes computers for your desk, lap, living room, hands, pockets, wrists, and ears. And they’re working on more. They’re also working on everything that runs and plays on all those computers, both in terms of software and services.

Yet, through it all, Apple has maintained its functional organization and small, focused team-based approach.

Our greatest strength is often our greatest weakness. So too, Apple’s culture. It’s what lets the company do so much but what also causes so much to be left undone.

I’m not one of the people who thinks Apple needs to abandon its past to better serve the future. I don’t think Apple needs to or should become IBM or GE. I think Apple can have its culture and scale it too. But I think it’s got to do a much, much better job shoring up its foundations as it keeps building.

But, like most who write about Apple, I was never responsible for shipping product at scales that reach into the hundreds of millions. Steven Sinofsky, who ran Office and then Windows at Microsoft, and also worked on early versions of SkyDrive and Outlook.com, was.

Sinofsky understands developing and shipping software and services at massive scale. So, when the topic of Apple and software and services quality came up again, Sinofsky took to Twitter for what can only be described as an epic — and epically long — tweet storm and reality check. (And, unsurprisingly, the former Microsoft guy understands Apple-at-scale better than any Apple pundit or reporter.)

Excerpted from @stevesi:

Several important points are conflated in the broad discussion about Apple and software:
– Quality
– Pace of change
– Features “versus” Quality
– Innovation

Scanning the landscape, it is important to recognize that in total the work Apple has been doing across hardware, software, services, and even AI/ML — in total — is breathtaking and unprecedented in scope, scale, and quality. Not saying that lightly or trolling. It just is.

It is absolutely ok — in fact, it’s imperative — that we report constantly and consistently about bugs and issues that need to be fixed. But it’s just as important to stop and remember all the features that we’ve gotten over the last few years, and what they’ve enabled, beyond just the bugs that need to be smoothed out.

Few companies have done so much for so long with such a high level of consistency. This all goes back to the bet on the NeXT code base and move to Intel for Mac OS plus the iPod, which began the journey to where we are today.

The pace of change has been remarkable. In the 10 years from when Apple acquired NeXT OS X was reinvented in a completely modern architecture. And in the next 10 years the iPhone went from that code to where we are today.

One must consider in those 20yrs there were releases every 12-18 months for the entire time. While some were larger/smaller, there wasn’t much comparable anywhere and certainly nothing without some big gaps. There were some massive architectural bets playing out over years.

Some years and releases are met with far-reaching excitement. Others with the equivalent of “bored now”. The truth is always in between — not every whiz-bang new feature keeps being used for years and some barely noticed architectural changes reap dividends for decades. Over the course of the last twenty and ten years, though, all of the those updates all stacked together have undeniably enabled entirely new, more personal, more functional workflows and brought as all the future faster.

[…]

The pace, scope, and quality of change is unprecedented in the industry. That’s a debt to the whole team, especially to the leadership like Jobs and Forstall (and the people in place now who were there). Apple was disrupting the PC market with a unique POV but no one knew.

What is lost in all of this recent discussion is the nuance between features, schedule, and quality. It is like having a discussion with a financial advisor over income, risk, and growth. You don’t just show up and say you want all three and get a “sure”.

You can have it be fast, you can have it be good, and you can have it be cheap, but you can’t have it be all of those things at the same time…

On the other hand, this is precisely what Apple did so reliably over 20 years. But behind the scenes there is a constant discussion over balancing these three legs of the tripod. You have to have all of them but you “can’t” but you have to. This is why they get paid big $.

When you look at a feature like FaceID and trace it backwards all the way to keychain—see how much long term thought can go into a feature and how much good work can go unnoticed (or even “fail”) for years before surfacing as a big advantage. That’s a long term POV AND focus.

Passbook was similar. When Apple introduced it, many rolled their eyes at how limited it was. But it was clear Apple was just laying foundations, and that parts could be swapped in and layered on. And then we Passbook became Wallet, we got Apple Pay authenticated through Touch ID — and now through Face ID. Same with iCloud Keychain, Extensibility, Continuity, and so many of the technologies that started small and became fundamental parts of the architecture over time.

There’s nothing magic about this. It goes back to a balancing act. Mature orgs just manage this the whole time. There are processes and approaches that you use so you never face the absurd notion that this is a zero sum trade off between quality, schedule, features.

What happens to a growing project over time is that processes and approaches need to re-thought. It just means that how things once scaled—tools like deciding features, priorities, est. schedules, integration test, etc—are no longer scaling as well. That happens. ¯_(ツ)_/¯

What I think it happening at Apple now is not more dramatic than that. What they had been doing got to a point where it needs an adjustment. Reality is that for many at Apple it feels dramatic b/c it might be first time they have gone through a substantial “systems” change.

A system designed to support one product (Mac), scaled to the biggest product in history (iPhone), added on to with several more significant products (iPad, Apple TV, Apple Watch, AirPods, HomePod) will show stress fractures.

Smart executives will have some special projects groups go off an explore other ways of managing future projects, and allow existing systems to be tested and evolved in new ways to better support existing projects.

Just like Apple considered several candidates for a new language before unveiling Swift, and several candidates for a new file system before unveiling APFS, almost all of this happens internally, in small groups, and and only looks sudden from the outside.

In any absolute sense the quality of Mac/iOS + h/w are at quality levels our industry has just not seen before. Think of the scale of iPhone X release. From zero to 30M in months. That’s just insane. And it works better/more reliable than just about anything else I can buy.

How does that explain general “buggy” feeling w/ so many super smart/skilled people saying products are suffering? It’s because of the depth and scale of usage that comes w/success. A responsibility.

Look, there are bugs. You (and Apple) can make a list of them. But mostly this is about change. I know people say that isn’t the case but it is. On any absolute scale number of bugs—non-working, data losing, hanging mistakes—in iOS/Mac is far far less today than ever before.

I’ve said this before: Humans forget past pain quickly but feel present pain acutely. It’s what lets us survive. There are fewer showstoppers today because Apple became really good at finding and fixing them. Kernel panics and SpringBoard crashes, which used to be frequent are few and far between now.

But “frustrators”, the small things that crop up and harshen your user experience in one way or another, feel more frequent. That’s a function of Apple’s much, much, much wider product portfolio (the teams are doing far more than ever before), and our increased usage of the wider product portfolio (we’re hitting them harder than ever before.)

No one ever anywhere has delivered a general purpose piece of S/W+H/W at scale of 1B delivering such a broad, robust, consistent experience. We don’t have a measure for what it means to be “high quality”. I can say that in any absolute sense, Apple has exceeded everyone else.

So Apple will just renew the engineering process. It means thinking about how risk is analyzed, how schedules are constructed, how priorities are set. This is literally what it means to run a project and what we are all paying them to do.

They have more data and understanding to make adjustments than anyone. The only thing I think is fair to say from the outside is that this is not nearly as dramatic as it is getting made out to be…

If you’ve been paying attention, change has been happening for years. Last year was different than the year before. And the year before, different than the year before that. Craig Federighi has said as much at the last couple of WWDCs, including last year’s revelation that engineers were given time to work on and fix issues they felt were important beyond the release spec and schedule.

The idea though that this is some massive shift to focus on one dimension of the overall product process: quality OR features OR date is just nonsense. Nothing of scale is thought of or executed that way.

So to me on Apple, even as an outsider, I feel confident saying that this isn’t reactionary/crisis or a response to externalities. Importantly it isn’t a massive pivot/”student body left”. It’s a methodical and predictable evolution of an extremely robust and proven system.

As Jason Snell, former head of Macworld, currently at Six Colors, pointed out — Sinofsky is one of the few people who could have written this.

For anyone who cares about understanding Apple at scale, it’s terrific that he did.

Main





Source link

No Comments Yet.

What do you think?

Your email address will not be published. Required fields are marked *