A Look at Quality Management in Apple’s System Updates Over Time ⇥ eclecticlight.co

I thought this piece by Howard Oakley was very thoughtful in examining the relationship between the length of MacOS development cycles over time and whether system updates have become more frequent. He concludes:

Surely the most important way to improve quality is to strengthen quality management processes throughout engineering — the principle of building it right first time, rather than expending more effort at detecting and remediating errors. Simply extending the cycle without changing quality management would be very unlikely to result in any improvement. But better quality management doesn’t entail making the cycle any longer, so cycle length is unlikely to be relevant, as was shown by Apple’s only real two-year development cycle with Mac OS X 10.4 Tiger.

Oakley’s data doesn’t lie, but I think it is more complex than it appears at a glance.

For the first few public releases of Mac OS X, Apple stuck to a development cycle of well under a year per release. Beginning with the Panther release in 2003, Mac OS X settled into something closer to an eighteen-month gap between x.0 public releases, with a long exception for Tiger. Then, with Mountain Lion in 2012, Apple stated that its intention was to begin releasing a new version of OS X every year; Mountain Lion had a shorter cycle than its predecessors, but it was still longer than any release after.

In all three eras of MacOS development cycles, you will find versions that are legendary for their refinement, and those which are the complete opposite.

But Tiger’s release is special. It came out in 2005, just a couple of months before Apple announced it would be switching to Intel processors across its lineup. The processor switch, the iPod effect, and Microsoft’s dreadful Vista release combined to persuade millions of people to switch to the Mac around this time — yours truly included. We all skipped past the chaotic first two years of Mac OS X and got used to a slower release cycle of major versions that did not feel bound to a calendar.

Another development is that MacOS is not the only project that is on an annual release cycle. Apple now develops six operating systems, and it ships new x.0 releases every autumn for all but audioOS. That is an enormous amount of pressure for a lot of devices and an ever-increasing number of users. Apple also employs more designers and developers, but that does not necessarily imply that design and development tasks are scalable.

There are surely more factors for why older versions of MacOS felt more stable, including faulty human memory. But I also bet cramming five OS updates into a synchronized twelve-month release pattern must have some effect on overall quality. For what it’s worth, I have found that you can get a similar feeling of stability and quality by skipping every second major release of MacOS. It is almost like implementing your own version of a longer development cycle.