Catégorie : traductions

Les choses que vous ne devriez jamais faire

Par Joel Spolsky, le 6 avril 2000.

Vous trouverez l’original ici

Netscape 6.0 est sur le point de publier sa première version beta. Il n’y a jamais eu de version 5.0. La derniere version majeure était la 4.0, dévoilée il y a presque trois ans. Trois ans, c’est une durée horriblement longue dans le monde Internet. Pendant ce temps, Netscape était assis, sans rien pouvoir faire d’autre que de voir leurs ventes s’écrouler.

C’est un peu ingrat de ma part de les critiquer sur le temps d’écart entre les versions principales. Ils ne l’ont pas fait volontairement, n’est-ce pas ?

Eh bien si, c’était volontaire. Ils ont fait la seule et unique, la pire erreur stratégique qu’une entreprise puisse faire :

Ils ont décidé de réécrire le code en entier.

Netscape n’était pas le première société à faire cette erreur. Borland a fait la même erreur lorsqu’ils ont acheté Arago et essayé de l’intégrer dans dBase pour Windows, un projet maudit qui a pris tellement de temps que Microsoft Access a mangé leur déjeûner, et puis ils l’ont recommencé avec Quattro Pro, en repartant à nouveau de zéro, en épatant les gens sur le nombre impressionnant du peu de possibilités qu’il avait. Microsoft a fait presque la même erreur, en essayant de ré-écrire Word pour Windows à partir de zéro, dans un projet lui aussi maudit appelé Pyramid qui a été stoppé, jeté, balayé et caché sous le tapis. Par chance pour Microsoft, ils n’ont jamais cessé de travailler sur le vieux code, donc ils ont eu quelque chose à vendre, transformant tout ça simplement en un désastre financier, et non pas un désastre stratégique.

Nous sommes des développeurs. Les développeurs sont, au plus profond d’eux-mêmes, des architectes, et la première chose qu’ils veulent faire quand ils arrivent dans un chantier est de tout raser, et de faire quelque chose de grand. Nous ne sommes pas excités par la rénovation incrémentale : le bricolage, l’amélioration, et planter des parterres de fleurs.

Il y a une raison subtile qui explique pourquoi les développeurs veulent systématiquement tout jeter et recommencer. La raison est qu’ils pensent que le vieux code est bordélique. Est c’est là que vient une observation intéréssante : ils se trompent très certainement. La raison pour laquelle ils pensent que le code est un bazar, est dûe à une loi de programmation simple, cardinale et fondamentale :

C’est toujours plus dur de lire du code que de l’écrire.

C’est pourquoi réutiliser du code est si difficile. C’est pourquoi dans votre équipe, chacun a sa propre fonction, unique, qu’il aime utiliser pour casser des chaines en tableau d’autres chaines. Ils écrivent leur propre fonction parce que c’est plus facile et plus sympa à faire que d’essayer de comprendre comment on se sert de la vieille fonction.

Un corollaire de cet axiome est que vous pouvez demander à pratiquement n’importe quel développeur aujourd’hui ce qu’il pense du code qu’il sur lequel il travaille. « C’est un bordel total, » vont-ils vous dire. « La seule chose que j’aimerais vraiment est de tout jeter et recommencer proprement. »

Pourquoi est-ce un foutoir ?

« Eh bien, » vous disent-ils, « regarde cette fonction. Elle s’étale sur deux pages ! Il n’y a rien dedans qui appartient réellement à la fonction ! Je ne sais même pas à quoi sert la moitié des appels faits aux API. »

Avant que la nouvelle brochure de Borland pour Windows ne sorte, Philippe Kahn, le fondateur très coloré de Borland, a été cité souvent dans la presse en vantant à quel point Quattro Pro serait meilleur que Microsoft Excel, parce qu’il avait été entièrement ré-écrit. Que du nouveau code source ! Comme si le code source pouvait rouiller.

L’idée qu’un code nouveau est meilleur qu’un code ancien est foncièrement absurde. Le vieux code a été utilisé. Il a été testé. Plein de problèmes ont été soulévés, et ils ont été résolus. Il n’y a aucun problème avec ça. Il ne va pas créer de nouveaux bogues juste en restant assis dans le disque dur sans bouger. Au contraire, baby ! Est-ce qu’un programme est supposé être comme une voiture, il rouille inévitablement ? Est-ce qu’un programme est comme une peluche qui devient grossière et laide si elle n’est pas faite avec un nouveau matériel ?

Revenons à notre fonction qui s’étale sur deux pages. Oui, je sais, c’est juste une fonction très simple qui affiche une fenêtre, mais elle a un peu grandi et semble avoir grossi inutilement, et personne ne sait pourquoi. Eh bien je vais vous le dire, pourquoi : ce sont des résolutions de bogues. L’un deux résoud le problème que Nancy a eu lorsqu’elle a essayé d’installer le programme sur un ordinateur qui n’avait pas Internet Explorer. Un autre résoud ce bogue qui ne sort que dans les cas où on a très peu de mémoire. Un autre résoud le problème du fichier qui est sur un périphérique externe (disquette, clé USB) et qui se voit retirer en plein milieu d’une opération d’écriture. Cet appel à LoadLibrary semble pourri mais le code fonctionne aussi sur des anciennes version de Windows 95.

Chacun de ces bogues a pris des semaines et des semaines d’usage intensif en situation réelle avant qu’ils n’aient été trouvés. Le développeur peut avoir passé plusieurs jours avant de réussir à reproduire le bogue dans le laboratoire, et de l’avoir résolu. Si c’est comme la plupart des résolutions de bogues, la solution ne prend qu’une ligne, ou tout juste la modification de quelques caractères, mais un travail énorme a été fait dans ces « quelques caractères ».

Quand vous jetez du code et recommencez tout à zéro, vous jetez aussi toute cette connaissance qui va avec. Toutes ces corrections de bogues. Des années de travail de programmation.

Vous jetez en réalité ce qui fait que vous êtes en tête dans votre catégorie. Vous donnez, comme ça, gratuitement, un ou deux ans à vos concurrents, et croyez moi, c’est une durée énorme quand on parle de logiciels informatiques.

Vous vous mettez vous-même dans une position extrêmement dangereuse, dans laquelle vous allez continuer à livrer une vieille version avec du vieux code pendant encore quelques années, quelque chose qui sera donc voué à ne pas évoluer et à ne pas réagir à des nouvelles choses que le marché va demander, parce que vous ne pourrez pas intégrer un nouveau code. Si vous n’avez pas les reins solides, vous risquez carrément de couler et de fermer votre boîte.

Vous perdez une somme d’argent colossale à réécrire du code qui existe déjà.

Est-ce qu’il y a une alternative ? Il faut tout de même admettre que le vieux code de base de Netscape était vraiment très mauvais. Eh bien, dans tous les cas, il pouvait être mauvais mais vous savez quoi ? Il fonctionnait super bien sur un nombre impressionnant d’ordinateur différents, dans le monde entier.

Lorsque les développeurs vous disent que leur code est un bordel pas possible (c’est toujours le cas à un moment ou à un autre), il y a trois choses qu’il faut inspecter.

  1. Il y a des problèmes de conception. Le code n’est pas correctement conçu. Le code concernant les échanges réseaux ouvre ses propres boites de dialogue n’importe quand ; cela aurait dû être mieux géré, et surtout ailleurs. Ces problèmes peuvent être résolus, un par un, en déplacant le code avec précaution, en le mettant à jour, et en généralisant à un seul endroit l’affichage des boites de dialogue. Un seul et unique développeur qui travaille sérieusement et qui vérifie un à un, pas à pas, chacun de ses changements, peut faire cela. Je dis un seul, pour que les autres ne soient pas dans l’impossibilité de travailler. Même les changements majeurs d’architecture peuvent être faits sans changer complètement le code. Sur le projet Juno, nous avons passé plusieurs mois à ré-architecturer autour d’un point central : simplement déplacer le code, le nettoyer un peu, créer des classes de base dont le nom et le principe de fonctionnement soit logique, et créer des interfaces d’échanges claires et précises entre les différents modules. Mais on l’a fait précautionneusement, avec notre code de base, et nous n’avons généré aucun nouveau bogue, et cela sans jeter quoi que ce soit de notre vieux code.
  2. Les développeurs pensent que leur code n’est pas optimisé et qu’il est lent. Une rumeur disait que le moteur de rendu de Netscape était lent. Cela n’affectait qu’une petite partie du projet, qu’il était possible d’optimiser ou de ré-écrire. Il n’était pas nécessaire de tout ré-écrire. Lorsqu’on optimise pour la vitesse, 1 % du travail vous donne 99 % des résultats attendus.
  3. Enfin, le code est devenu, avec le temps, illisible. Un projet sur lequel j’ai travaillé avait un type de données appelée ChaineEnBordel. Un autre projet avait commencé en utilisant, par convention, l’écriture de toutes les variables membres par un underscore, puis a changé plus tard pour quelque chose de plus standard, « m_ ». Donc la moitié des fonctions commencaient par « _ » et l’autre moitié par « m_ ». Ce qui rendait le code difficilement lisible. Honnêtement, c’est le type de chose que vous résolvez en 5 minutes avec une macro dans Emacs, pas la peine de repartir de zéro.

Il est très important que vous vous souveniez de cela : lorsque vous repartez de zéro, il n’y a aucune raison de croire que vous allez faire un meilleur boulot que celui que vous avez fait la première fois. Premièrement, vous n’aurez peut-être pas la même équipe de développeurs à gérer. Si cela se trouve, ce ne sera même qu’une équipe de nouveaux développeurs, et donc il n’auront pas « plus d’expérience ». Vous allez dans ce cas refaire à nouveau les mêmes erreurs, et à l’inverse créer de nouveaux problèmes qui n’existaient pas dans la version originale.

Le vieux mantra « construirez en un puis jetez le » est très dangereux, et encore plus lorsqu’il concerne des grosses applications commerciales. Si vous écrivez du code de manière expérimentale, vous voudrez peut-être supprimer la fonction que vous avez écrit la semaine précédente, parce que vous venez de penser à un meilleur algorithme. Très bien. Vous voudrez peut-être factoriser une classe pour la rendre plus facile à utiliser. Très bien aussi. Mais jeter complètement programme est une folie furieuse, et si Netscape avait eu une hiérarchie, et une hiérarchie qui supervisait le projet de manière adulte, avec une expérience dans le domaine du logiciel industriel, ils ne se seraient peut-être pas tiré une balle dans le pied si violemment.

Est-ce si difficile de se couler ? Voilà cinq méthodes efficaces.

Cet article vient d’ici

Il y a un nombre énorme de projets technologiques qui finissent mal. C’est une nouveauté pour personne. Que vous démarriez une compagnie qui vend un programme avec plein de travaux de programmation à venir, ou que vous possédiez une compagnie pas du tout technique qui loue des consultants ici et là afin de vous aider à intégrer des choses dans votre système, vous avez dû très certainement faire face à ce problème. Délais dépassés, budgets explosés, et échecs techniques sont si courants dans le monde informatique, en réalité, que c’est pas si choquant que ça, finalement, quand un gros projet a quelques années de retard et dépasse le budget prévu de plusieurs millions.

En 2003, par example, j’avais pris l’avion pour Los Angeles afin d’assister à une des conférences que Microsoft (NASDAQ:MSFT) organise occasionnellement pour les développeurs. Pendant l’événement, Microsoft a fait tout un tas d’annonces super excitantes au sujet de nouveautés hallucinantes sur le point de sortir pour la prochaine version de Windows. En revoyant mes notes, je vois qu’une des nouveautés vraiment importantes concernait quelque chose appelé WinFS. Je vous évite les détails ennuyeux, mais grossièrement WinFS proposait de combiner un système de fichiers du système d’exploitation (stocker des fichiers et des répertoires sur disque dur) avec des possibilités de base de données (ranger des enregistrements individuels de données pour une recherche et une récupération rapide) en un seul et unique gloubiboulga « fichier-base-de-données ».

C’était une entreprise on ne peut plus ambitieuse. WinFS était, en termes techniques, globalement la réorganisation du système de transport national pour donner la priorité aux bus volants. Oui, cela détruirait les compagnies aériennes, et oui, tous les garages auraient besoin de faire d’énormes travaux pour être élargis afin de pouvoir accueillir ces autobus nouvelle génération qui auraient des ailes, mais, hé, bon, c’est rien, ou le sortira en un an. Bon, au pire deux, allez, tope là !

Trois années se sont écoulées. Un manager à Microsoft, Quentin Clark pour ne pas le nommer, a écrit sur son blog que WinFS ne pouvait tout simplement pas être livré dans les temps, et qu’il était en train de retarder le lancement du dernier système d’exploitation de Microsoft. Donc, WinFS allait être retardé et livré, « peut-être », en tant que fonctionnalité super originale dans une base de données à venir, validant par là le fait qu’il n’allait pas combiner base de données et système de fichiers, ce qui était la seule chose qui le rendait intéréssant. Donc, dites moi, comment pouvez-vous dire quand un de vos projets technologiques est destiné à être un autre WinFS ? Voici mes 5 premiers conseils qui vous assurent un échec sur un projet :

Erreur numéro 1 : débuter avec un équipe de développeurs médiocres.

Créer un programme, l’inventer et construire est une tâche difficile, et malheureusement plein de gens s’auto-proclamment développeurs et pourtant n’y arrivent pas du tout. Malgré le fait qu’une mauvaise équipe de programmeurs soit à mon sens la cause numéro 1 des échecs des programmes informatiques, vous ne pouvez pas le prédire en faisant une étude détaillée des CVs. Dans tous les domaines, en partant du programme, en passant par la logistique, jusqu’au service après vente pour le client, les gens sont beaucoup trop gentils entre eux pour parler du manque de compétence de l’un ou de l’autre, surtout s’ils travaillent côte à côte. Vous n’entendrez jamais personne dire « l’équipe n’était pas suffisamment perspicace, ou n’avait pas assez de talent pour sortir le produit. » Pouquoi blesser les gens ? C’est bien simple : si les personnes qui font partie d’un projet donné ne sont pas très bons dans ce qu’ils font, ils vont venir tous les jours au travail et malgré ça le programme ne sera pas fini. Et surtout, gardez bien en tête que cela ne sert à rien de lorgner du côté des compagnies off-shore prêtes à vous louer, ou vous trouver des personnes pour vous aider à avancer : dans la plupart des cas, je vous garantis qu’ils ne vont rien faire de plus que vous, et ne pourront pas empêcher le fait que vous embauchiez quelqu’un qui ne tient pas la route.

Erreur numéro 2 : posez un jalon par semaine.

Imaginons que vous refassiez votre cuisine. Que le type que vous avez engagé pour faire le travail a déjà fait plein de cuisines avant la vôtre, et peut estimer le coût du projet sans vous sortir les choses dans le détail. Tout ça c’est bien beau, mais il faut avoir conscience que les développeurs de programmes construisent systématiquement des choses qu’ils n’ont jamais construites auparavant. Si c’était le cas, il n’auraient qu’à vous vendre une copie sur un CD de leur programme. Des estimations à la louche sont impossibles. Ils ont un besoin impératif d’avoir un plan détaillé avant qu’ils commencent à écrire du code. Que vous soyiez le client, ou le chef de projet de l’équipe, votre boulot est de vous assurer qu’il y a un plan détaillé. Quand vous demandez à un développeur de donner une estimation à un plan, presque tous vous répondront en faisant un planning grossier, qui découpe les processus en semaines de travail. Ca pourrait sembler raisonnable, mais ça ne l’est pas. Si vous laissez une équipe faire un tel planning, avec des estimations grossières par gros paquets, (par gros paquets j’entends quelque chose qui prend plus de deux jours de développement), vous pouvez être pratiquement certain qu’ils ne prennent pas en compte chaque petit détail qui aura besoin d’être implémenté, et ce sont ces détails qui vont ajouter un énorme délai au projet.

Erreur numéro 3 : négocier la fin du projet.

Quoi de pire que d’accepter une planification dont l’échelle est si grossière qu’on parle, sur un projet informatique, en semaines ? Une chose : demander que l’équipe s’engage à terminer son travail beaucoup plus tôt que les estimations. Avec mon expérience, je vous certifice que la plupart des developeurs sont optimistes et vont vous suivre en s’engageant dans des négociations du genre « découper-tout-ça-autrement ». Vous serez super content, vous aurez un très zoli projet, sur lequel tout le monde s’est mis d’accord, et vous n’allez absolument jamais y coller.

Pensez à cela en ces termes : la mère du veau vêle entre le 15 et 16ème mois. Vous pourriez demander à cette mère de s’engager à 15 mois maximum et elle pourrait tout à fait dire « No problem ! » Ou vous pourriez dire, « Quinze mois ? Vous êtes folle ? Il nous faut ça pour dans huit mois ! » Bien sûr, beugler comme ça ne peut pas accélérer les choses, et même si vous réussissez à faire accepter ce délai à la maman, je vais vous confier un petit secret : elle ne vêlera jamais au huitième mois. Vous pouvez avoir un planning qui dit onze mois, mais vous aurez votre bébé en 15 mois, parce que dans tous les cas c’est le temps qu’il faut pour faire un veau. Seize mois, parfois.

Erreur numéro 4 : diviser les tâches équitablement.

Voilà une superbe façon de torpiller votre projet. Faites une liste de tous les travaux à faire, et, en milieu de projet, redistribuez-les à des personnes différentes afin de tout équilibrer. Si Marie a trop de travail, donnez quelques unes de ses tâches à John. Ca a l’air tout à fait logique, donc personne ne vous contredira.

Je vous promet qu’à moyen ou long terme, cela va inévitablement causer des problèmes. C’est parce que lorsqu’un développeur doit en remplacer un autre, on peut raisonnablement penser qu’il va avoir une efficacité d’un dizième par rapport à son prédécésseur. John va passer des heures entières à essayer de comprendre toutes les choses que Marie connaît déjà sur le bout des doigts dans son propre code. Et John ne résoudra jamais aussi rapidement les problèmes dans le code de Marie que Marie elle-même parce que notre Marie sait où sont cachées toutes les petites astuces et trappes à éviter.

Erreur numéro 5 : travailler jusqu’à minuit.

Imaginons qu’un projet doit prendre six mois à raison de 40 heures par semaines, pour être terminé. Si vous disiez à tout le monde de travailler 60 heures par semaine, vous pourriez finir le développement en quatre mois. L’équipe de programmation devrait même avoir envie de réussir ce challenge parce qu’ainsi ils auront la sensation d’être de vrais héros. (« Incroyable, cette équipe de mamans qui vont vêler en 4 mois, ils sont là même le week-end ! »). Ca devrait fonctionner, non ? Devinez quoi. Il y a des centaines de livres qui établissent un fait qu’on ne peut plus nier : travailler plus d’heures n’aide en rien à sortir quelque chose plus vite. Edward Yourdon, directeur d’une bonne équipe de développeurs, et écrivain, a donné un petit nom à ce genre de projet : « marche funèbre. »

Le développement d’un programme demande un gros effort intellectuel. Même les meilleurs programmeurs peuvent rarement soutenir un niveau d’effort qui atteint quelques heures par jour. Derrière tout ça, ils ont besoin de se changer les idées, car c’est une façon d’aider le cerveau à se reposer, c’est pourquoi on a toujours l’impression qu’ils sont en train de se ballader sur Internet ou en train de jouer à des jeux quand on jette un coup d’oeil à ce qu’ils font

Les forcer à passer plus d’heures devant leur ordinateur ne va jamais se traduire par plus de production, ou si c’est le cas, ce sera de la mauvaise production. Quand leurs cerveaux sont complètement frits, les développeurs créent plus de problèmes qu’ils n’en réparent, en écrivant du mauvais code ou en créant des bogues à n’en plus finir. Et si vous bannissez Internet et les jeux multijoueurs pour les forcer à garder la tête dans le guidon et à écrire du code après les heures où, normalement on se couche, eh bien, il vont très certainement démissionner. Faire une « marche funèbre » n’est pas la seule manière de faire exploser les délais, le budget ou les deux. Mais c’est une manière certaine d’y arriver.

Si ce sont toutes les choses à éviter, comment peut-on s’assurer qu’on projet va dans le bon sens ? En premier lieu, vous avez intérêt à embaucher des superstars. A Fog Creek, on lis en moyenne 400 CVs avant une embauche en CDI, parce qu’un bon développeur peut être dix fois plus productif qu’un développeur normal.

Deuxièmement, demandez une découpe très précise des tâches à faire à chaque developeur. Oui, c’est difficile pour un développeur de prédire le temps qu’il faut pour une nouvelle application. C’est pour cela qu’il faut qu’ils fassent vraiment de bons plans, bien fiables, avant chaque début de projet.

Une fois que vous avez le planning entre les mains, n’essayez pas de réduire la durée. Si le projet ne peut pas être achevé dans une durée que vous estimez raisonnable, la solution est de négocier un planning qui vous convient mieux, mais ne pas toucher à la durée totale. Ou bien éventuellement d’annuler quelques évolutions. Ou, enfin, de mettre de côté certaines options qui ne sont pas forcément nécéssaires.

Pendant le projet vous allez être tenté parfois de réassigner le travail en pensant que cela ira plus vite. Dans ce cas faites très attention. De nouveaux développeurs mettent toujours du temps avant de trouver leur vitesse de croisière et d’arriver, s’ils y arrivent, à la vitesse de leur prédécésseur. C’est bien entendu positif de faire tourner les développeurs sur différents types de travaux, ainsi de cette façon personne n’est irremplacable, mais je le fais très précautionneusement et je réserve dans ce cadre trois semaines complètes sur le planning pour le développeur qui arrive et qui prend la nouvelle place, et une semaine de plus pour celui qui s’en va car il va devoir apprendre le code à son remplacant.

Finalement, encouragez votre équipe à travailler au maximum 40 heures par semaine. Non non, je ne blague pas. Sérieusement. A part de manière vraiment occasionnelle, où nous avons des impératifs vitaux, l’équipe de Fog Creek travaille 8 heures par jour au maximum. Dans notre monde qui devient de plus en plus technologique, il est vital de considérer un gros projet comme un marathon et non pas comme un sprint.