Le chef d’orchestre du développement d’OS X

À peine son diplôme de l’université du Colorado à Boulder en poche, Ryan Nielsen a intégré Apple en tant que engineering project manager en charge de la supervision du développement d’OS X. En six ans à la tête du développement d’OS X, il a supervisé cinq versions majeures : Mac OS X 10.4 Tiger, Mac OS X 10.5 Leopard, Mac OS X 10.6 Snow Leopard, OS X 10.7 Lion et 0 S X 10.8 Mountain Lion.

« L’équipe Mac OS X avait la main haute sur tout ce qui touchait au système d’exploitation », explique-t-il, « du moins jusqu’à ce que le développement de l’iPhone entraîne une compartimentation plus stricte de certaines fonctions. » L’engineering project manager qu’il était alors ne devait pas s’assurer que le système sorte à temps, mais tout simplement « à ce qu’il sorte ».

« On voit souvent le project manager comme un "hub", mais c’est plutôt la colle qui tient tous les éléments de la société ensemble », poursuit-il. S’il repère un problème dans les couches les plus basses du système, il doit mobiliser des ressources pour le régler au plus vite, afin qu’une nouvelle build soit disponible au plus vite pour les équipes qui travaillent sur les apps, à plus haut niveau. Si une équipe est en retard, il doit estimer ce retard, prendre la décision de l’absorber, ou de le résorber en réallouant des ingénieurs, ou même de remettre une fonction à plus tard.

Bref, c’est un rouage essentiel, une sorte de chef d’orchestre qui a une vision globale de l’état du développement, alors que chaque équipe travaille de manière isolée. C’est un canal de communication entre les équipes, mais aussi des équipes aux dirigeants. Et c’est évidemment le responsable en cas de blocage, celui qui doit trouver une solution et la mettre en place.

Apple : un développement « organique »

De fait, le développement d’OS X est assez « naturel » : la structure générale est suffisamment lâche pour que les décisions soient prises de manière pragmatique, au cas par cas. Jusqu’à Lion, chaque version d’OS X était organisée autour d’« un thème » ou d’« un jeu d’objectifs » imaginés par la direction, le marketing et l’ingénierie.

Ce cadre est fixe : une fois que la décision de ne pas doter Snow Leopard de nouvelles fonctions a été prise, toutes les équipes n’avaient plus qu’un but, nettoyer et optimiser le système. Les détails d’implémentation, eux, peuvent évoluer : l’équipe en charge de GCD, dont les ingénieurs ont souvent été mobilisés pour d’autres projets, a été « autorisée » à prendre du retard. Et GCD est finalement arrivé à temps. « Il faut accepter que la réalité impose de ne pas respecter les règles, de faire des compromis, de revoir ses objectifs à la baisse », explique Nielsen : « au final, on obtient moins que l’on imaginait, mais mieux. »

Cette liberté relative et l’architecture générale d’OS X permettent d’intégrer assez rapidement les modifications des ingénieurs. Non seulement l’équipe en charge d’un logiciel obtient un retour immédiat sur son travail, mais les autres équipes peuvent immédiatement vérifier que ces modifications ne posent pas de problèmes à leurs propres travaux, ou inversement. Les systèmes de gestion de versions sont suffisamment robustes pour revenir sur ces modifications au besoin, voire les supprimer si elles doivent être reportées à un prochain système.

Cette jolie mécanique d’allers-retours du code ralentit à l’approche d’un keynote : tout devant parfaitement s’y dérouler, aucune instabilité ne peut être introduite dans le système. Le rôle du project manager est alors de choisir une build à la fois suffisamment stable et suffisamment complète pour la démonstration. Si une fonction cruciale a du retard, il doit donc particulièrement contrôler les contributions des ingénieurs responsables, pour s’assurer qu’ils parviennent à un état acceptable sans introduire d’instabilités au niveau du système.

Elle souffre aussi de ce que certaines applications sont implantées assez profondément dans le système : les équipes iLife ou iWork peuvent évoluer indépendamment des équipes OS X, pas les équipes Safari, Mail ou iTunes. Nielsen a toujours rêvé d’un système où toutes les apps seraient de véritables silos, dont le développement pourrait totalement être découplé de celui du système. Cela n’aurait que contribué à faciliter ce mode de fonctionnement.

Les choses ont sans doute changé depuis que le cycle de développement d’OS X est passé à un rythme annuel et que Nielsen a quitté Apple, mais ces grands principes de fonctionnement demeurent. Sans doute contraint par un accord de confidentialité, Nielsen pèse chacun de ses mots, mais il laisse à penser que le développement d’OS X approche désormais le principe de la rolling release.

Il fallait jusqu’à trois ans pour développer une version majeure d’OS X autour d’un grand thème. Au lieu d’attendre trois ans pour présenter une version d’OS X parfaitement intégrée à iCloud et communicant sans heurts avec iOS, Apple a présenté trois versions s’approchant chacune un peu plus du but (lire « Ship first, fix later » : un monde en bêta). En quelque sorte, Lion et Mountain Lion ont été des « instantanés » du développement de la version finale que sera Mavericks, avec toutes les incohérences flagrantes et les bogues frustrants que cela suppose.

Microsoft : une machine inflexible

Cette approche s’oppose radicalement à celle de Microsoft, dont Nielsen a eu quelques échos. L’exemple parfait est celui de la débâcle WinFS : sur le papier, cette extension de NTFS aurait été une véritable révolution, peut-être même le système de fichiers ultime. Cette merveille d’ingénierie a finalement été abandonnée après de nombreux retards : Microsoft a refusé « de ne pas respecter les règles, de faire des compromis, de revoir ses objectifs à la baisse ». Face à WinFS, Apple a présenté… Spotlight.

Ce n’est qu’une simple fonction, infiniment moins ambitieuse qu’un nouveau système de fichiers, mais qui a apporté des solutions concrètes et pratiques à une partie du problème que Microsoft essayait de résoudre. Revoir HFS+ aurait été infiniment plus complexe, même si Apple a un temps envisagé de le faire avec ZFS — une piste aujourd’hui définitivement abandonnée, selon ce que sous-entend Nielsen. La firme de Cupertino trouve donc d’autres solutions, comme Core Storage, une couche au-dessus du système de fichiers qui a ouvert la porte à Fusion Drive.

Le processus de développement de Microsoft, plus lourd et plus strict, reflète cette ambition. Lorsqu’un ingénieur soumet une modification, elle ne s’applique qu’à son dépôt local. Après vérification, elle remonte d’un niveau : son comportement face aux autres modifications est testé, avant de finalement intégrer le dépôt central. Une build officielle de Windows est alors compilée.

L’avancement et la stabilité des fonctions de cette build sont alors testées dans leur globalité, avant de redescendre d’un niveau. Les équipes transversales testent leurs propres fonctions, avant de donner leur feu vert à une nouvelle « descente » de la build. Au moment où l’ingénieur reçoit enfin la version de Windows qui contient sa modification, il a pu s’écouler plusieurs semaines, voire plusieurs mois.

Ce processus est indiscutablement plus solide : il permet à Microsoft de proposer régulièrement des nouveautés réellement importantes (qui pourrait sérieusement douter de la supériorité de NTFS sur HFS+ ?). Mais Apple est prête à sacrifier la beauté de la recherche fondamentale en informatique avec son processus plus souple : le fait est qu'au final, les utilisateurs obtiennent plus rapidement les fonctions qu'ils désirent. Selon Nielsen, Microsoft elle-même s'orienterait vers ce modèle, consciente de ses avantages certains.