WWDC of the Future

So WWDC 2012 was announced at early o’ clock and sold out in less than two hours. New restrictions on multiple purchases didn’t do anything to stave the ever-shortening window. As compensation for all the interested developers who won’t get to go to WWDC this year, Apple has promised to quickly post the session videos online (as they’ve done in the past few years).

Which leads me to ask: why is WWDC still worth attending? WWDC’s allure has always been the exclusive combination of three features: the sessions, the labs, and the social interaction with the worldwide Cocoa community. Now that the sessions can be gotten online mere days after the conference (and have lately been repeated locally during the Tech Talk series), and much of the community wasn’t even awake to purchase tickets, the only remaining feature of WWDC is the direct access to Apple engineers provided by the labs.

Maybe it’s time to think of a post-WWDC world. Or perhaps a world in which an event named WWDC still exists but bears no resemblance to the event we currently know.

What if instead of a week-long conference in the Moscone Center, Apple held a three-week-long open house during which developers could sign up for one-on-one sessions with Apple engineers? This open house would be prefixed by a livestreamed keynote and the release of prerecorded session materials. The actual WWDC “event” would become a festival of sorts, emanating from but not tied to a physical location.

Apple clearly benefits from the excitement that surrounds WWDC, and there’s no need to get rid of that. They could hold a press-only WWDC Kickoff Keynote sometime in late Spring. Following the keynote, Apple would post prerecorded session videos on the Developer Center and publicly announce the dates during which the open house will occur, likely starting in mid-June and ending in early July. This would give developers time to digest the material and, importantly, schedule a timeslot during the open house to meet with an Apple engineer (or UX designer or Review team member).

All of a sudden the entire “crunch” disappears. All registered developers get access to the same information at the same time. They have time to schedule a brief trip to Cupertino rather than a week-long ordeal. Developers can coordinate among themselves to meet in San Francisco around their sessions. And Apple’s engineers aren’t pulled away from their desks for a week, but scheduled to be unavailable to their teams for short periods of time well in advance.

WWDC could be the Cocoa community’s Easter Season, celebrated everywhere but especially in the Bay Area.

5 Comments

  1. Greg Parker

    In the labs, it’s common that it takes several attempts to figure out which engineer or engineers a developer should be talking to. This is especially common for the hard problems. Signing up for one-on-one sessions in advance makes that procedure difficult.

    • How about organizing them by team/expertise instead of signing up for individual engineers? Maybe a slate of AppKit engineers would be available Wednesday-Friday afternoons, and you’d get to pick a slot from there.

      From past experience, the lab registrations at WWDC clearly aren’t fixed in stone; I wouldn’t want to make the registration process any stricter. I’d expect people flying to Cupertino to make their reservations would be happy to hang out for a while to find the right engineer.

  2. Jerry Krinock

    Looks good, Kyle. Here’s another idea which will give Apple engineers more time for these one-on-one sessions. Presentations and videos are time-consuming to produce. The most value I’ve got from WWDC videos is to learn things that are not in the documentation yet. So, instead of producing videos, finish and ship the documentation with the new technologies, instead of a year later. I’d rather have documentation than videos because documentation lives in a tree, and is searchable. Several times last year I’ve said to myself, Gee I remember something about that in a WWDC video, but I need to see it again. Then I need to remember what video it was, try and remember what part, then shuffle back and forth until I find it. Oh, and copy/pasting sample code from videos doesn’t work very well.

    Documentation needs to be done sooner or later anyhow (although recently it’s been later and I’m worried that not everyone at Apple agrees with that statement). Doing it sooner would be better for both Apple and us. And I understand some radicals out there think that you get better, less buggy code if you write your documentation first. Hmmm.

  3. I share Greg’s concerns that requiring pre-booking might not work in practice. As anyone who’s been to the labs at WWDC before can attest, finding the right person is the biggest battle. A lot of the time it relies on luck, or serendipity – some other engineer, ostensibly unrelated to the technology in question, overhears a random conversation and offers a valuable insight or answer. Or similarly, one member of a team might be around, and they might not know the answer but tomorrow they can bring in the person from their team that does.

    There’s also a need, often, to have repeated meetings. At WWDC this would often amount to “I’ll take a look at it tonight, when I get back to the office, so come find me again tomorrow and I’ll let you know the results”. In some cases I was able to produce actual fixes and validate them against people’s code, in the labs. None of that is really plausible in a single session.

    But I like the idea in general, and I feel like that’s the way things are heading. The current onus on compressing everything into a single week is on the assumption that people want to “do” everything – see every session, visit every lab for every topic – which doesn’t make much sense when you boil it down to just lab time. If instead you assume it’s engineer contact time that’s important, you can indeed spread it out over several weeks, with varying themes over time (e.g. iOS vs Mac OS, and subcategories within). That in turns allows the Apple engineers to be pseudo-available for several weeks, but really only for the few days that focus on their areas. Of course, it has to be balanced with the realities that developers may have needs across multiple areas, so, like the WWDC labs to date, while there should be a stated “focus” at any given time, random engineers from other areas should still be available. But most engineers are happy to make extra time on subsequent days for any interesting problems.

    I’m not sure where that leaves the presentations and the 3rd party events, as well as some of the less business aspects of WWDC, like Stump the Experts or Brown Bag lunches or things of that nature… it certainly would be harmful to them to deliberate spread attendees out across time.

    I do think, though, that the presentations are valuable, so they should remain. It also makes sense to keep them together for the most part, rather than spread out over the year, both from a logistical perspective and from a logical perspective – the most interesting ones pertain to the new versions of Mac OS and iOS that are typically announced concurrently, so there’s a natural grouping. So having a big, all-together release on a specific date still makes sense.

    I caution that said date should be at least a week before any lab time. Many of the questions will consequently be on the new features, but people need time to disgest them before getting to the really meaty questions. It was always a little awkward at WWDC when people would come up to me and say “OMG that new feature is awesome, but I only just got the new Xcode installed and I haven’t had time to really play with it and I just know I’m going to hit all sorts of problems only after everyone goes home on Friday”. Yes. I know. I didn’t like it either. Unfortunately I wasn’t in charge of the schedule.

  4. I share Greg’s concerns that requiring pre-booking might not work in practice.  As anyone who’s been to the labs at WWDC before can attest, finding the right person is the biggest battle.  A lot of the time it relies on luck, or serendipity – some other engineer, ostensibly unrelated to the technology in question, overhears a random conversation and offers a valuable insight or answer.  Or similarly, one member of a team might be around, and they might not know the answer but tomorrow they can bring in the person from their team that does.

    There’s also a need, often, to have repeated meetings.  At WWDC this would often amount to “I’ll take a look at it tonight, when I get back to the office, so come find me again tomorrow and I’ll let you know the results”.  In some cases I was able to produce actual fixes and validate them against people’s code, in the labs.  None of that is really plausible in a single session.

    But I like the idea in general, and I feel like that’s the way things are heading.  The current onus on compressing everything into a single week is on the assumption that people want to “do” everything – see every session, visit every lab for every topic – which doesn’t make much sense when you boil it down to just lab time.  If instead you assume it’s engineer contact time that’s important, you can indeed spread it out over several weeks, with varying themes over time (e.g. iOS vs Mac OS, and subcategories within).  That in turns allows the Apple engineers to be pseudo-available for several weeks, but really only for the few days that focus on their areas.  Of course, it has to be balanced with the realities that developers may have needs across multiple areas, so, like the WWDC labs to date, while there should be a stated “focus” at any given time, random engineers from other areas should still be available.  But most engineers are happy to make extra time on subsequent days for any interesting problems.

    I’m not sure where that leaves the presentations and the 3rd party events, as well as some of the less business aspects of WWDC, like Stump the Experts or Brown Bag lunches or things of that nature… it certainly would be harmful to them to deliberate spread attendees out across time.

    I do think, though, that the presentations are valuable, so they should remain.  It also makes sense to keep them together for the most part, rather than spread out over the year, both from a logistical perspective and from a logical perspective – the most interesting ones pertain to the new versions of Mac OS and iOS that are typically announced concurrently, so there’s a natural grouping.  So having a big, all-together release on a specific date still makes sense.

    I caution that said date should be at least a week before any lab time.  Many of the questions will consequently be on the new features, but people need time to disgest them before getting to the really meaty questions.  It was always a little awkward at WWDC when people would come up to me and say “OMG that new feature is awesome, but I only just got the new Xcode installed and I haven’t had time to really play with it and I just know I’m going to hit all sorts of problems only after everyone goes home on Friday”.  Yes.  I know.  I didn’t like it either.  Unfortunately I wasn’t in charge of the schedule.

Comments are closed.