Advertisement

Apple software quality and the "sprint system" of OS X development



A recent post

from developer Marco Arment kickstarted a whirlwind of debate regarding the current state of Apple software. The gist of Arment's piece is that Apple has unfortunately worked its way into a position where marketing is given too much deference, all at the expense of the "it just works" mantra that Apple users have traditionally boasted about.

I suspect the rapid decline of Apple's software is a sign that marketing is too high a priority at Apple today: having major new releases every year is clearly impossible for the engineering teams to keep up with while maintaining quality. Maybe it's an engineering problem, but I suspect not - I doubt that any cohesive engineering team could keep up with these demands and maintain significantly higher quality.

Unfortunately, a few of the problems which have plagued Apple users in recent months haven't been relegated to obscure use cases, but rather center on fundamental features such as, say, oh I don't know, Wi-Fi.

As Arment intimates, it's simply not feasible for Apple to release major new software updates to OS X and iOS every year and have the finished product be as polished and bug-free as one would expect from a more drawn out development process.

While iOS releases have more or less always been on an annual release cycle, the same can't be said for OS X.

Consider this: the average wait time between individual OS X releases starting from OS X 10.1 Puma to OS X 10.7 Lion was 19 months and 20 days. The average time between OS X Lion and every subsequent OS X release has been 13 months.

On this note, I wanted to highlight two comments from a HackerNews thread which emerged in response to Arment's piece.

The first is from a user who claims to have worked on Apple's OS X development team.

Former OS X developer here.

I'd say the biggest change in the development methodology happened when Bertrand Serlet was replaced with Craig Federighi.

With Bertrand, we would move in giant monolithic releases where every group would just dump in whatever they had ready and the whole thing would get released with nightly builds. With SnowLeopard in particular, I remember three dozen releases in a row where Xcode was unusable due to obj-c garbage collection issues. Random stuff you didn't expect like CoreGraphics would have showstopper issues and then we'd report it and it would get fixed by the next week.

This resulted in extremely late releases that had a ton of bugs that we piled patches onto as time went on.

Craig moved the organization onto a sprint system, where we would develop new features for 2 weeks and then spend a week fixing bugs. After 10 or 12 or 16 of these cycles, we would deem it ready and ship it out.

I felt this produced more stable but more conservative software. It seemed like giant rewrites and massive features would be very difficult to introduce and if they did get done, wouldn't happen until two thirds or so into the release cycle.

On the other hand, Craig has consistently been able to release on time with most of the features promised.

I was only there up to the release of Lion (the first Craig release), so I don't know how updates and patches worked from then on. Maybe they're worse now.

But I've been using OS X all this time, and honestly I don't think it's any worse than before.

What has changed is that releases and features happen more often. Tiger and Leopard had a good 2 years to mature and get patches while their delayed successors missed target dates. In the meantime they stagnated with ancient unix tools, safari build, QuickTime frameworks, graphics drivers etc.

They felt stable because they were just old, sort of like Debian stable. Meanwhile, the development versions of Leopard and Snow Leopard (the two I spent most of my career at Apple developing) were downright horrible and unreleasable. Each of those releases went gold and had an almost immediate .1 release to fix glaring issues.

It's just that you remember them better because they had a longer history as a stable legacy OS than the modern versions.

The last sentence here is particularly interesting. I mean, if Apple keeps up its aggressive annual OS X release cycle, users will barely have time to get comfortable with OS X Yosemite before a successor is introduced, likely with its own set of bugs that will require time to iron out. In this regard, Apple is like a dog chasing its tail insofar that its desire to innovate and introduce new features never allows it to catch up with and get ahead of various software issues.

On a personal note, my favorite iteration of OS X (yeah, I'm going there) was OS X Tiger. Now was that because Tiger introduced a slew of cool new features and was bug free? Or, perhaps, as the anonymous Apple engineer writes, could it be that I associate Tiger with a positive user experience simply because I used a stable version of Tiger for longer than any other iteration of OS X. After all, recall that the wait time between OS X Tiger and OS X Leopard was a whopping 2.5 years.

The second HackerNews comment comes from someone who claims to currently work at Apple. He/She writes:

current apple engineer... the sprint (milestone) development system is still in place... it's not the problem though, it's the problem is the focus on new useless [imo] features at the expense of core functionality and quality

hope marco, geoff and others keep writing these articles so that eventually tim or someone sees one and shakes things up. pressure from the bottom has not worked so far.

Apple here is effectively stuck in a Catch-22. The company is innovating like crazy and introducing waves of new features at a rapid clip. With such a "sprint development system" in place, bugs are inevitable.

The alternative, however, is just as likely to irk some Apple users and tech pundits who inexplicably yearn for innovation on-demand, every year, without exception. Still, it wouldn't hurt Apple to focus on a few big features while addressing underlying system reliability as opposed to trying to come up with "hundreds of new features" each and every single year.

Taking a balanced view on the current state of Apple software, former Apple engineer Daniel Jalkut writes that discovering troublesome bugs in Apple software isn't a recent phenomenon. While Jalkut concedes that Apple is perhaps rushing software out the door a bit too quickly these days, he's not overly concerned with the direction Apple is headed.

And now it's 2015, and in the immortal words of Kurt Cobain: "Hey! Wait! I've got a new complaint." Don't we all. A company like Apple, moving at a breakneck speed, will undoubtedly continue to give us plenty to obsess about, both positively and negatively. I've been following the company closely since my hiring in 1996. Since that time, the company has consistently produced nothing short of the best hardware and software in the world, consistently marred by nothing short of the most infuriating, most embarrassing, most "worrisome for the company's future" defects.

All told, debating the current state of Apple software makes for an entertaining and, one can only hope, instructive discussion. And who knows, perhaps some of the higher ups at Apple are actually paying attention and lending a thoughtful ear to some very valid concerns.

Personally, I think both sides of the Apple software debate have merit, which is why many of the online discussions have been so engaging. Yes, OS X and iOS seem to have more problems out the gate than we're accustomed to. At the same time, the Apple userbase is incredibly larger than ever before. Which is to say, a bug that in the past might have affected 800 users may now affect 4,000 users across the globe. What's more, as technology has seeped into nearly every crevice of our daily existence, the expectation that software work flawlessly 24/7 is much more embedded today than in years past. Furthermore, the breadth and complexity of features users expect to see in a mobile OS and modern operating system is eons beyond what we many might have imagined was possible even 5 years ago. All that said, it's arguably unreasonable to expect some of the new and more ambitious features from Apple to be relatively flawless at launch across a userbase that encompasses hundreds of millions of iOS users and tens of millions of OS X users.

On the other side of the coin, there is a case to be made that Apple might want to slow down and catch its breath for a second. Perhaps a Zack Morris timeout is in order. As Russell Ivanovic eloquently wrote this past October, perhaps Apple needs some more Snow Leopard-esque updates that focus primarily on under the hood improvements.

The yearly release cycles of OS X, iOS, iPhone & iPad are resulting in too many things seeing the light of day that aren't finished yet. Perhaps the world wouldn't let them, perhaps the expectations are now too high, but I'd kill for Snow iOS 8 and Snow Yosemite next year. I'm fairly confident I'm not alone in that feeling.

Indeed, it was pretty cool, not to mention a clever bit of spin, when Apple touted Snow Leopard as an OS X update with "0 new features."



Going forward, one can only hope that Apple appreciates that it won't be afforded the same benefits of the doubt with the Apple Watch that it has traditionally enjoyed with iOS and OS X.