Apple's bug-squashing week was part of its efforts to minimize errors
Apple's week-long pause on development for its next generation of operating systems and to debug code instead was necessary to ensure iOS 18, macOS 15 and other releases have the best chance of bug-free releases, reckons a report.
In late October, Apple software head Craig Federighi implemented a week-long pause on the development of its next operating systems round, including iOS 18, iPadOS 18, macOS 15, watchOS 11, and tvOS 18. The pause was used to fix bugs and improve the performance of the elements that Apple's software team has produced, and was quickly lifted with normal development resuming right after.
Mark Gurman, writing for the Bloomberg "Power On" newsletter on Sunday, points out that this isn't the first time Apple has done this sort of thing, as bugs have been a problem for the company in the past.
Apple's release of iOS 18 and its other operating systems in 2024 will apparently be "more crucial than usual,"as Apple is attempting to catch up with others in the generative AI space. Furthermore, with the belief that there won't be "any major advances" in hardware for the iPhone 16, the operating system has to be even more impressive than usual.
Apple previously made changes to its procedures in 2019, a time when iPhones had software glitches at launch, and after the company had to postpone several features destined for iOS 12 to iOS 13 instead.
The week-long pause occurred after Apple hit a key milestone in iOS 18 and macOS 15 development, namely the completion of the first internal versions that contain the main big new features. After this first period, referred to as M1, Apple took a one-week break to debug before the next phase, M2.
Each of the four phases that occur before WWDC typically boil down to four weeks of feature development followed by two of bug fixes. In effect, the pause added an extra week of bug fixing to M1.
For the grand scheme of development, the extra week shouldn't affect the overall release timings of the operating systems. Instead, it should just give less time at the end for removing last-minute bugs.
The Pact
While bug fixing is generally part of development as a whole, Apple has taken steps to try and minimize the appearance of bugs in its in-development software.
Craig Federighi adopted a policy in 2019 internally referred to by his division as "The Pact." The policy is summed up as "We will never knowingly allow regressions in the build. And when we find them, we will fix them quickly."
The decree essentially meant that if a bug or a new feature breaks something else within the operating system, the bug has to be fixed as a priority.
It is likely that the introduction of "ambitious and compelling" features, according to internal descriptions by Apple's senior management, may have proved to cause more bugs than acceptable, necessitating the extra bug-fix week.
Read on AppleInsider
Comments
I would like some of what they are on.
Mark Gurman, writing for the Bloomberg "Power On" newsletter on Sunday, points out that this isn't the first time Apple has done this sort of thing, as bugs have been a problem for the company in the past.
This is reassuring and makes sense to me. I too was a bit surprised when I first heard about the pause because one week is way too little time to make a serious dent in their bug backlog. Many software teams intersperse these "maintenance" sprints into their software development process.
As chasm points out, there is something called a "cost of quality" that evaluates the cost to fix bugs discovered over the software product's development and release cycle. The least expensive anomalies to fix are those discovered during design and architectural review, before any code is written. The next least expensive anomalies are those discovered by the developer as they test their code, ideally as part of a test driven development process that builds unit testing test cases at the same time or even before the functional code is written. The relative cost to fix bugs between the two least expensive phases is typically around 5X. On the other extreme, the most expensive bugs to fix are those that leak into the released product and have to be addressed after the fact. The cost ratio between the two extremes can rise above 30X (according to NIST) when you factor in business losses associated with critical functionality being unavailable.
Speaking of bugs. The easiest way to prevent bugs is to not write the code, for example, by culling requirements. If I had to recommend a feature that Apple should have culled, in my opinion of course, is the "Reactions" feature added to FaceTime. It is currently broken on iOS, but more so, it's what I consider a totally worthless feature because it provides no value and in its broken state, it is so annoying as to question why they bothered to put it in there in the first place when it gets in the way when you're not using it. Everyone is entitled to their opinion, but these fluffy features just add bloat to an already quality challenged codebase.
That said, bugs should be flagged and fixed, with nothing going unpatched for years or ever, (or before the next big release).
I've been well and truly bitten by absurd bugs that never ever got fixed and when they break workflows etc it makes you wary of upgrading. It's the number one reason I always hold back.
The race for features and interconnection inevitably leads to bigger problems down the line so hitting the pause button from time to time is absolutely necessary.
Bugginess definitely seems to have risen to noteworthy levels over the last few years so I hope the pendulum swings back in favour of better code over yet more functionality.