Apple and Brooks’s Law

Apple recently announced that it had to delay the release of the next version of Mac OS X, Leopard, by a few months — too many developers had to be tossed into the effort to get the new iPhone out the door by its June release. Commenting on the delay, Paul Kedrosky wrote, “Guess what? People apparently just rediscovered that writing software is hard.”

In researching Dreaming in Code, I spent years compiling examples of people making that rediscovery. I’m less obsessive about it these days, but stories like this one still cause a little alarm to ring in my brain. They tend to come in clumps: Recently, there was the Blackberry blackout, caused by a buggy software upgrade; or the Mars Global Surveyor, given up for lost in January, which, the LA Times recently reported, was doomed by a cascading failure started by a single bad command.

Kedrosky suggests the possibility of a Brooks’s Law-style problem on Apple’s hands, if the company has tried to speed up a late iPhone software schedule by redeploying legions of OS X developers onto the project. If that’s the case, then we’d likely see even further slippage from the iPhone project, which would then cause further delays for Leopard.

This is the sort of thing that always seemed to happen at Apple in the early and mid-’90s, and has rarely happened in Steve Jobs Era II. I write “rarely,” not “never,” because I recall this saga of “a Mythical Man Month disaster” on the Aperture team. If the tale is accurate, Apple threw 130 developers at a till-then-20-person team, with predictable painful results. We’ll maintain a Brooks’ Law Watch on Apple as the news continues to unfold.

UPDATE: Welcome, Daring Fireball and Reddit readers! And to respond to one consistent criticism: Sure, iPhone isn’t late yet, but Apple is explicitly saying it needed to add more developers to the project to meet its original deadline. If that all works out dandy, then the Brooks’s Law alarm will turn out to have been unwarranted. Most likely, given Apple’s discipline, the company will ship iPhone, with its software, when it says it will. What we won’t and can’t know is whether, and if so how much, the shipping product has been scaled back. And sure, of course this is all conjecture. Conjecture is what we have, given Apple’s locked-down secrecy.
[tags]apple, leopard, os x, software delays, brooks’s law[/tags]


Post Revisions:

There are no revisions for this post.

Get Scott’s weekly Wordyard email


  1. Blake

    Scott, I’ve been writing software professionally for fifteen years, and reading yet another story about Apple doing something stupid no longer even registers as a blip on my radar. I have an iPod video, so I’m forced to use iTunes at home, and I work on a product that runs on the Mac as well as Windows, so I’m forced to use their System and development tools, as well. They all look indescribably beautiful as they sputter along, crash, lose my work and my music. Recently a coworker downloaded an OS X update, and had the audacity to start an application during the process. The update bricked his system, he lost the rest of the day bringing it back, and when he was done he found that this is a known bug that Apple has neglected to fix for about 18 months. Either Apple does not know how to write reliable software, or they do not care; the result is the same in any case. I can’t wait to see how much fun people have when they get ahold of something they actually expect to work all the time, like a phone, from these people. Then again, the faithful continue to buy their products, no matter how much overt disdain the company heaps on them. Sometimes I really question the nature of that relationship.

  2. Dileepan

    How dare you say that about Apple? Apple is the best because I SAY SO! Steve Jobs is the best because HE SAYS SO!

  3. Wu Ming

    I have been upgrading Mac OS X since 10.2.0 and I currently run 10.4.9. on a PowerPC G4. Even listening to internet radio through iTunes while updating the system software, I never got a crash, hang up or kernel panic (in fact I NEVER got a kernel panic), so I guess that old saying fits really well here: your mileage may vary.

  4. Andy Lee

    “Straw man. The iPhone project isn’t late.”

    How do you know? The release timeframe hasn’t been changed, but the project could still be behind schedule. Maybe Scott should have said “if the company has tried to PREVENT a late iPhone software schedule…” His point about the mythical man month would be the same.

    That said, I don’t know what’s really going on, and I don’t trust anybody who claims to know. I *hope* the iPhone project is not a big clusterf*ck, but at this point everybody is just speculating.

  5. Andy Lee

    >>Paul Kedrosky wrote, “Guess what? People apparently just rediscovered that writing software is hard.”

  6. Andy Lee

    D’oh, no preview…

    [Paul Kedrosky wrote, “Guess what? People apparently just rediscovered that writing software is hard.”]

    Guess what? Kedrosky apparently just rediscovered that software companies sometimes have to change their plans.

    It’s fun to be a smart@ss, but until I know more I prefer the approach of “maintain[ing] a Brooks’ Law Watch on Apple as the news continues to unfold.” I get the little alarm going off in my head too; I just don’t presume to know exactly what’s going on — yet.

  7. From what I’ve read, it doesn’t sound like OS X engineers were actually moved to the iPhone team. The iPhone runs a variant of OS X, which means a lot of work needs to be done within OS X itself to support that new platform. So it seems less like a case of redeployment, and more like a case of many OS X engineers doing work on OS X itself to support the iPhone team.

  8. James

    [So it seems less like a case of redeployment, and more like a case of many OS X engineers doing work on OS X itself to support the iPhone team.]

    This is what he meant: Each minute an OS X engineer works on issues specific to the iPhone is a minute not spend on issues specific to the new OS X release.

    We used to call this: “borrow from Peter to pay Paul” (not sure where that originates from). In my experience both projects become late as the result.

  9. Dave

    OS X engineers were reassigned to work on… OS X? It’s much more likely that the OS engineers were instructed to prioritize the iPhone over a Leopard release. That is not a Brooke’s law problem.

    It’s easy to speculate that the iPhone was late. However, unless you have credible sources, all we know from Apple is that the iPhone is on or ahead of schedule. In fact, I would argue that it’s Leopard that’s behind schedule (to the point it was threatening the iPhone which is based on Leopard). Rather than push to get Leopard out, the priorities were shifted as I said earlier and the Leopard release date was pushed. Of course, I don’t have any reliable sources inside Apple to confirm this either. It just fits Occam’s razor a little better IMO.

  10. Kevin

    If memory serves “robbing Peter to pay Paul” originally had to do with the Vatican moving churchbells from an existing St. Peters Cathedral to a newly constructed St. Paul’s Cathedral.

  11. I work in a lean organization, and we constantly have to make the tradeoff between features and release dates. We don’t have the resources to trade off people, often, and are wary of attempts to do that. Our biggest bottleneck, by the way, isn’t development, but QA—and Apple explicitly said that they were borrowing both software engineering and QA resources from Mac OS X to work on iPhone [OS X].

    This isn’t a Brook’s law situation at all, especially if it involves QA resources.

  12. Fred Hanranhansenhansen

    What Apple did is analagous to Donald Trump staggering the opening of two office buildings so that he could have the same designer do the interiors of both buildings. It is not an architecture or construction problem like you see with Windows delays, where they are madly dropping features and every year they push the next release into next year.


Post a comment