Most people who use Apple’s editing software applications have no inkling of how software is developed. For the many who have strong opinions about what features are missing from and doesn’t work well in Final Cut Pro X, it is worth taking the time to consider Apple’s software development cycle.

Apple is more tight-lipped than most when it comes to talking about how they build products and services, but a recent series of podcast episodes are a good place to go. The Debug podcast from iMore covers tech software and services for computers, tablets and phones. Episode 60 features a conversation with people who were involved in making multiple versions of OS X and iOS at Apple over the years.

It is worth understanding what they say about deadlines and development when it comes to OS X and iOS, because it is likely similar rules apply when it comes to Final Cut Pro X development. The main difference is that of timeframes. The podcast interviewees talk about how little time they have for actual development when their OSs are being updated every year. Due to fixing bugs found in the current version and the next version, most features have to be implemented in two and a half months out of every 12 (The longest time between major updates of Final Cut Pro X has been 14 months: between 10.0.6 and 10.1).

[43:42] It’s not a yearly cycle. Part of the cycle of what you’re going to do for one release happens during the previous release. Let’s say you’re going to do announcements in June [at the worldwide developer conference] and you’re going to bring out a product (whether it’s iOS or OS X) in September/October… You start figuring part of that out in the spring time of the previous cycle. Because you have a set of features where it’s ‘do or die time:’ you’ve passed that two and a half months of typical development time in the previous December, January or February. Everyone’s got to work out what features are going to make it …

[45:22] You have a big spreadsheet [at the start of March] which has everything and you decide what’s going into that release. [Higher ups would look at each feature and say…] “Not this time, we’re gonna bump that.” Sometimes there were crushed [software] engineers, sometimes there were completely relieved engineers… that gets bumped to another list. Basically everyone starts at that point to start panicing about bugs and gets into a dead run for that release. Once the new one comes out, everyone says “What the hell have we got” – that’s one bucket we draw from: what got deferred. Another bucket is ‘what did we make up in the meantime?’ [new ideas for features thought up between March and August] and there’s the bucket of things we need to do because people are pestering us about them…

[47:27] It’s usually a month before it goes out the door that the product management team and the product marketing team start gathering the stuff up together for a big meeting, usually in October or November and then you decide what that release is going to be…

[48:19] …they would decide what the ‘theme’ of the release would be…

[48:40] …you really start some time in December getting on with it…

[50:19] …there’s the list of features that project management is tracking […which are part of…] ‘tentpoles’ – the small number of features that define the release … top down decisions informed by ‘bottom-up’ feedback: “have you seen what Android has introduced, the Palm Pre is going to have such and such”

[56:01] From the moment the feature list is defined, until that release hits, everybody and their brother and their mother is trying to come in with another feature…

[The trick is to match the amount of new features you want to implement with the amount of resource you have to implement the features – you have to say “no”]

[1:01:33] …progress reports start trickling in at the end of January, sometimes February. There’s a big feature review in March … [some features aren’t going to be ready for August, so need to be dropped] “Oh my god, we’ve just kicked out one of the tentpoles, oops, we’ve just kicked out another tentpole. The tent’s collapsed we’ve got to come up with something else” […] That’s where things get really ‘exciting’ [unpleasant].

This conversation shows that even Apple, the richest company in world, has to limit what it does when devloping software – even when that software is for iPhones, the hardware that accounts for 67% of Apple’s profits.

PS: Brooks’ Law: ‘adding manpower to a late software project makes it later’