Couche abstraite pour le développement

From The Joel on Software Translation Project

Jump to: navigation, search
Article original: The Development Abstraction Layer
Date de publication: 11 Avril 2006
Traducteur: Non-communiqué
Vérifié par: Non-communiqué
Navigation: Retour à Main Page Retour à French FrenchFlag.png




Un jeune homme arrive en ville. Il est raisonnablement élégant et il a un peu d'argent en poche. Il n'a pas de mal avec les femmes.

Il ne parle pas beaucoup de son passé, mais il est clair qu'il a travaillé beaucoup de temps pour une grosse entreprise sans âme.

Il est plutôt sympathique et ouvert, tranquillement sûr de lui sans être arrogant. Et il trouve sans problème des petits boulots de programmation parmi ceux proposés régulièrement sur le panneau à annonces du café du coin où les programmeurs ont l'habitude de se réunir. Mais il se désintéresse bientôt des projets de bases de données pour assureurs, des pages web sans intérêt de femme au foyer, et des moteurs de calculs financiers.

Au bout d'un an, il calcule qu'il a économisé suffisamment pour tenir un an avec son train de vie modeste. Puis, après s'être entretenu avec son fidèle berger allemand, il installe son ordinateur dans une chambre ensoleillée de son appartement de location au-dessus de l'épicerie et installe une liste d'outils triés sur le volet.

Il appelle ses amis un à un, et les prévient que s'il semblera distant les mois suivants, c'est qu'il est à fond dans son travail.

Et il commence à mouliner du code.

Et quel code. Sans un pli, sans une tache, sans bogue, c'est de l'élégance et de l'art. L'interface utilisateur épouse si intimement la pensée de l'utilisateur que les personnes auxquelles il montre son produit au café des programmeurs voient à peine qu'il y a une interface. C'est une oeuvre de génie.

Encouragé par les retours de ses collègues, il monte son entreprise et se prépare à recevoir les commandes.

Sa modestie exclut toute attente exagérée, mais après un mois la situation de son compte bancaire ne semble pas encourageante. Jusque là, seules trois commandes ont été prises : une de sa mère, une de la part d'un mécène anonyme du café des programmeurs, et celle qu'il a passée lui-même pour tester son système de vente.

Le deuxième mois, aucune commande n'arrive.

Ça surprend notre homme et la mélancolie le saisit. Dans la grosse entreprise, de nouveaux produits étaient créés régulièrement, et même s'ils étaient maladroits et convenus, ils se vendaient raisonnablement bien. Un des produits sur lequel il a travaillé a même fait un carton.

Quelques mois passent, sa situation financière semble un peu précaire. Son chien le regarde tristement ; sans vraiment comprendre de ce qui ne va pas, il voit bien que son maitre fait plus triste mine que d'habitude, et qu'il semble incapable de rassembler l'énergie pour sortir avec ses amis, ou pour faire les courses qui pourraient remplir un buffet dangeurerusement vide, ou même pour se laver.

Un mardi matin, l'épicier refuse de lui rallonger son ardoise, et son banquier refuse depuis longtemps de le rappeler.

La grosse entreprise ne se montre pas rancunière. Ses chefs valorisent le talent, et sont heureux de le réembaucher, à un salaire plus élevé. Bientôt, il a meilleure forme, il a de nouveaux vêtements et retrouve confiance en lui. Mais quelque chose, quelque part, lui manque. Une étincelle dans le regard. L'espoir de devenir le maître de sa propre destinée s'est envolé.

SCal2.PNG

Où a-t-il échoué ? Il est à peu près sûr de le savoir. « Le marketing », dit-il. Comme beaucoup de jeunes techniciens, il a tendance à dire des choses comme : « Microsoft a de moins bons produits mais un meilleur marketing. »

Quand il est prononcé par un développeur de logiciel, le terme « marketing » désigne en fait tout ce bazar du monde de l'entreprise commerciale : tout ce qu'ils ne comprennent pas en réalité sur la création de logiciel et leur vente.

Ce n'est pas ce que signifie vraiment « marketing ». En fait, Microsoft est assez minable question marketing. Vous voyez un peu ces pubs avec les dinosaures convaincre quelqu'un d'acheter Microsoft Office ?

Le logiciel est comme un dialogue entre le développeur et l'utilisateur. Mais pour que ce dialogue puisse avoir lieu, il faut bien du travail en plus du simple développement logiciel. Il faut bien entendu du marketing, mais aussi du commercial, des relations publiques, et un bureau, et un réseau, et une infrastructure, et la climatisation dans le bureau, et le service client, et la comptabilité, et tout un tas d'autre tâches de support.

Mais que font les développeurs de logiciel ? Ils conçoivent et écrivent des programmes, ils configurent des interfaces, ils déboguent, ils intègrent, et ils balancent des mises à jour dans le gestionnaire de code source.

Le niveau auquel un développeur de code source travaille (disons, Emacs) est trop abstrait pour faire tourner une entreprise. Les développeurs travaillant au niveau de la "couche abstraite pour le développement" ont besoin d'une couche d'implémentation en-dessous d'eux, d'une organisation qui prenne leurs programmes et les transforme en produits. Mylène Farmer, qui travaille au-dessus de la couche "chantage de jolie chanson", a elle aussi besoin d'une couche d'implémentation impressionnante, pour éditer les disques, réserver les salles de concerts et vendre les billets, mettre en place la sono, faire la publicité des disques et percevoir les droits d'auteurs.

SCal3.PNG

Une entreprise de logiciels réussie sera toujours constituée d'une mince couche de développeurs, qui créent le logiciel, assis au-dessus d'une grosse organisation administrative qui reste entièrement abstraite pour eux.

Cette abstraction existe seulement dans le but de créer l'illusion que les activités quotidiennes d'un programmeur (concevoir et écrire du code, mettre le code dans l'outil de gestion des versions, déboguer, etc...) suffisent par elles-mêmes à créer des produits logiciels et à les mettre sur le marché. Ce qui nous mène à l'idée la plus importante de cet article :

Votre première priorité, en tant que chef d'une équipe de développement logiciel, est d'établir cette couche abstraite pour le développement.

Beaucoup de nouveaux chefs de projets logiciels loupent complètement le coche. Ils pensent toujours au modèle de gestion traditionnel "Ordonner et Conquérir", qu'ils ont appris en regardant les films d'Hollywood.

Selon le modèle "Ordonner et Conquérir", les gestionnaires-tiret-leaders déterminent la marche à suivre de la société, puis émettent les décrets appropriés à leurs lieutenants pour faire marcher la société dans cette direction. Ces lieutenants à leur tour divisent les tâches en plus petits morceaux et ordonnent à leurs subalternes de les mettre en oeuvre. Ce phénomène se poursuit en descendant la hiérarchie jusqu'à ce qu'en fin de compte, quelqu'un en bas de l'échelle fasse effectivement le boulot. Dans ce modèle, le programmeur est un rouage du modèle: une dactylo qui exécute sa portion des ordres de la direction.

Il y a bien des sociétés qui marchent sur ce modèle. On sait tout de suite qu'on a affaire à une telle société quand la personne que vous avez en face de vous fait quelque chose d'horripliant et de stupide, qu'elle le sait, qu'elle en est même désolée, mais qu'elle ne peut rien y faire. C'est la compagnie aérienne qui perd à jamais un client de toujours parce qu'elle a refusé de changer son billet non remboursable pour qu'il puisse retourner chez lui pour une urgence. C'est le FAI dont l'accès a plus souvent des bas que des hauts, et qui continue à vous facturer après que vous ayez résilié votre compte, et à vous facturer, et à vous facturer, et à vous facturer ; et puis quand vous les appelez pour vous plaindre, vous devez appeler un numéro surtaxé et êtes mis en attente pendant une heure, et après ça ils refusent encore et toujours de vous rembourser, tant que vous n'écrivez pas un blog pour raconter combien ils sont mauvais. C'est le fabriquant d'automobiles de Detroit qui a oublié depuis longtemps comment concevoir des voitures que les gens auraient envie d'acheter, et qui errent d'une stratégie marketing à une autre, comme si la seule raison pour laquelle nous n'achetons pas leur voitures pourries était parce que la remise n'était pas assez importante.

SCal1.PNG

Assez !

Laissez tomber ce modèle. Le système de gestion autoritaire et hiérarchique a bien été essayé, et il a eu l'air de marcher pendant un temps dans les années 1920, quand il était en concurrence avec des marchants ambulants poussant leur chariot, mais il n'est pas assez robuste pour le 21ème siècle. Les éditeurs de logiciel ont besoin d'utiliser un modèle différent.

Chez un éditeur de logiciels, la première priorité du management doit être la réalisation de cette abstraction pour les programmeurs.

Si un programmeur quelquepart se préoccupe d'une chaise cassée, ou bien poireaute au téléphone avec Dell pour commander un nouvel ordinateur, c'est qu'il y a une fuite dans la couche d'abstraction.

Pensez à votre couche d'abstraction pour développeurs comme à un magnifique et énorme yacht pourvu de moteurs d'une puissance inouïe. Il est impeccablement entretenu. Des repas trois-étoiles y sont servis avec la précision d'une horloge. Des femmes de ménage passent deux fois par jour dans les quartiers d'habitation. Les cartes de navigation sont toujours mises à jour. Le GPS et le radar fonctionnent toujours, et s'il venait à y avoir une panne, il y a des équipements de secours en cale. Sur le pont, il y a des programmeurs qui ne se soucient vraiment que de la vitesse, du cap, et de décider si ce sera saumon ou thon pour le déjeûner. Pendant ce temps, une nombreuse équipe de professionnels, vêtus de blancs uniformes amidonnés, s'affaire en silence dans la cale, s'occupe de faire tout tourner, s'assure que les réservoirs d'essence soient bien remplis, grattent la coque pour en détacher les bernacles et repassent les serviettes pour le déjeuner. Le personnel de support connaît bien son boulot, mais il leur est dicté par un vieux chnoque désagréable qui ne fait que hocher la tête de temps en temps dans telle ou telle direction, orchestrant ainsi le ballet grâce auquel les programeurs peuvent faire abstraction complète de tout ce qui se passe dans le vaisseau, à part la vitesse, le cap et ce qu'il y aura au déjeuner.

Le management, chez un éditeur de logiciels, est responsable en premier lieu de créer des abstractions pour les programmeurs. On construit le bateau, on entretien le bateau, on est le bateau, mais on ne barre pas le bateau. Tout ce qu'on fait se résume à fournir une abstraction étanche aux programmeurs, pour qu'ils puissent écrire de super programmes et que ces programmes puissent parvenir aux clients qui en bénéficient.

Les programmeurs ont besoin d'un gestionnaire de versions Subversion. Qui dit gestionnaire de versions Subversion dit réseau et serveur, qui doivent chacun être achetés, installés, sauvegardés, alimentés continûment en puissance électrique, et comme le serveur génère beaucoup de chaleur il doit être dans une pièce avec un climatiseur supplémentaire, et ce climatiseur supplémentaire a besoin d'un accès à l'extérieur du bâtiment, ce qui implique l'installation d'un ventilateur de 40 kg sur le mur extérieur du bâtiment, ce qui n'enchante pas les propriétaires, alors ils font venir leur technicien pour négocier l'emplacement du climatiseur (décision : sur le mur extérieur, au 18ème étage, à l'endroit le moins pratique qui soit), et le gérant de l'immeuble fait intervenir ses avocats parce qu'il faut accepter de vendre l'âme de son premier-né si on veut pouvoir faire ça, et puis l'installateur de climatiseurs arrive avec des attaches de sécurité qui ont l'air de jouets Barbie, ce qui rend notre contremaître nerveux, il lui interdit de se suspendre à la fenêtre du 18ème étage attaché par un bout de plastique rose Mattel d'un centimètre d'épaisseur faisant office de harnais, je le jure devant Dieu qu'on dirait la ceinture de Barbie Disco, et quelqu'un est obligé de rappeler le gérant de l'immeuble pour comprendre pourquoi ces idiots viennent seulement de se rendre compte, 12 semaines après le démarrage du projet de construction, qu'un autre amendement au bail va être nécessaire pour ce satané climatiseur dont ils sont au courant depuis Noël dernier et ils viennent seulement de le comprendre, et si vos programmeurs passent ne serait-ce qu'une minute à s'occuper de ce problème c'est une minute en trop.

Du point de vue des développeurs de logiciels qui composent votre équipe, tout cela doit être rendu aussi abstrait que de taper la ligne de commande svn commit.

C'est bien la raison pour laquelle le management existe.

C'est pour gérer le genre de choses qu'aucune société ne peut éviter, mais qui, si elles occupent l'esprit de vos programmeurs, sont un signe de l'échec du management, de même qu'un yacht de 30 mètres est un échec si le propriétaire millionnaire est obligé d'aller dans la salle des machines pour... euh... fabriquer le moteur.

Vous avez la société typique, créée par d'ex-vendeurs de logiciels, où tout ce qui compte c'est les Ventes, les Ventes et les Ventes, et notre existence n'a pour but que de faire de nouvelles ventes. Ces sociétés peuvent être repérées à l'état sauvage à ce qu'elles font une version 1.0 de leur logiciel (elles se débrouillent d'une façon ou d'une autre pour y arriver) puis perdent tout intérêt à développer de nouveaux logiciels. Leur équipe de développement est affamée ou inexistante, parce qu'il n'est jamais venu à l'esprit de personne de construire la version 2.0... Tout ce que le management sait faire, c'est vendre plus.

A l'autre extrême, vous avez l'éditeur de logiciel typique lancé par d'ex-programmeurs. Ces sociétés sont plus difficiles à repérer, parce qu'en général elles sont assez discrètes, occupées à peaufiner leurs programmes quelquepart dans un grenier ; jamais personne ne vient les trouver, et elles finissent par tomber sans bruit dans l'oubli, juste après la Grande Réécriture en Ruby, leur projet révolutionnaire de refactorisation du code qui finalement n'a pas été apprécié à sa juste valeur par Les Gens.

Ces deux genres de sociétés peuvent aisément être balayées par une société qui est pilotée par les programmeurs et organisée pour mettre les programmeurs à la barre, mais qui ont une excellente abstraction qui fait tout le boulot en cale pour convertir des programmes en produits.

Un programmeur est optimalement productif dans un bureau privatif sans bruit, avec un super ordinateur, une réserve de boissons illimitée, une température ambiante comprise entre 68 et 72°F (Ndt: 20 et 22°C), pas de reflet sur l'écran, une chaise si confortable qu'on ne la sent pas, un assistant qui leur apporte leur courrier et achète leurs livres et manuels, un administrateur système qui s'occupe de rendre Internet aussi facilement accessible que l'oxygène, un testeur pour trouver les bugs qu'ils ne peuvent pas voir tout seuls, un graphiste pour faire de belles interfaces, une équipe de marketing pour faire en sorte que les foules veuillent acheter leurs produits, une équipe de ventes pour s'assurer que les foules puissent effectivement acheter ces produits, des employés de support technique saints de patience qui aident les clients à faire en sorte que le produit marche chez eux et aident les programmeurs à comprendre quels problèmes sont à la source des appels, plus encore une douzaine d'autres fonctions de support et administratives qui, mises ensemble, finissent dans une société typique par représenter environ 80% de la masse salariale. Ce n'est pas une coïncidence si l'armée romaine avait un ratio de 4 serviteurs par soldat. Ce n'était pas la décadence. Les armées modernes en sont probablement à un ratio de 7 à 1. (Voici quelque chose que Pradeep Singh m'a appris aujourd'hui : si seulement 20% de tes employés sont des programmeurs, et si tu peux économiser 50% sur les salaires en externalisant la programmation en Inde, alors quel avantage concurrentiel peut-on espérer réellement dégager à partir de cette économie de 10% ?)

La responsibilité principale du management d'un éditeur de logiciels, c'est de créer l'illusion qu'écrire du code peut suffire à faire tourner la boutique. Et on pourrait s'en passer, si l'on trouvait des programmeurs qui fassent aussi vendeurs, graphistes, administrateurs système et cuisiniers... mais c'est irréaliste. C'est comme d'essayer d'apprendre le chant à un cochon, on perd son temps et le cochon s'ennuie.

Microsoft fait un travail tellement excellent dans la création de cette abstraction que les anciens salariés de Microsoft sont connus pour avoir des difficultés à démarrer leurs propres sociétés. Il tombent des nues en se rendant compte de tout ce qui se passait dans la cale, et ils n'ont aucune idée de la façon dont ils pourraient le reproduire.

Personne n'attend de Mylène Farmer qu'elle sache brancher un microphone. Il y a toute une infrastructure incroyable de managers, de musiciens, de techniciens-son, d'éditeurs de disques, de roadies, de coiffeurs et d'attachés de presse qui sont là pour créer l'abstraction grâce à laquelle il lui suffit de chanter pour que des millions de personnes entendent sa chanson. Toute cette équipe de support et de management, qui rend possible l'existence même de Mylène Farmer, a accompli sa mission lorsqu'elle a réalisé l'abstraction la plus parfaite : l'illusion complète que Mylène chante pour nous. C'est sa chanson. Quand vous l'écoutez sur votre iPod, il y a une énorme infrastructure qui rend cela possible, mais la meilleure chose que puisse faire cette infrastructure est de disparaître complètement, de fournir une illusion étanche que Mylène Farmer est là qui chante, en privé, pour nous.

Personal tools