Archives pour septembre, 2009

Qui conduit dans le fossé y tombera le premier

J’ai constaté encore récemment l’étonnement que pouvait susciter chez certains une phrase du genre : « Ha non ! La nouveauté que tu cherches est dans la production n°27, mais pas dans la 28. » Allons bon. On fait du développement logiciel incrémental, et pourtant les productions se suivent mais ne se ressembleraient pas ? À cela, tout simplement je répondrai : « Oui. Et pire, c’est voulu. » Mais laissez-moi le temps de m’expliquer, avant de m’envoyer la sécurité pour que je débarasse mon bureau et libère ma place de parking.

Tous les jours, différentes équipes de développement vont vous fournir des altérations du logiciel : nouveau développement, correction de bogue, mise-en-place d’interfaces pour le futur, etc. Si vous mettez tout ça dans une seule et même production, vous n’avez simplement aucune plus-value ! Le plus probable est que vous obteniez un exécutable qui plante rapidement, voire très rapidement. Ce qui fait qu’une seule altération empêche tous les autres d’être testés. Aprêtez-vous à ouvrir le bureau des plaintes.

Justifiez votre salaire, et aidez les développeurs :

Faites plusieurs productions à la fois, en séparant les différentes altérations en plusieurs groupes.

Par exemple, les moins risquées ensemble (les correctifs simples), et les nouveaux développements à part, voire jusqu’à isoler chacun. La limitation haute étant, évidemment, la capacité de production de vos infrastructures. Ainsi, vous minimiserez le risque qu’une minorité bloque une majorité.

Une fois que vous aurez obtenu un certain nombre d’altérations validées, vous pourrez alors les intégrer toutes dans un seul et même exécutable, vérifier sommairement son fonctionnement, et publier une nouvelle version stabilisée. Ce qui, vous le constaterez, est bien plus apprécié que de publier des versions de moins en moins fonctionnelles.

Tags: , ,

Chose promise est dûe

C’est jour de livraison. Aux temps immémoriaux d’un monde archaïque, vous auriez déjà stabilisé un exécutable il y a une semaine, et celui-ci serait depuis inspecté minutieusement par l’équipe de validation. Personne n’aurait cherché à introduire des correctifs de dernière minute, car chacun sait qu’il vaut mieux une livraison quasiment fonctionnelle aux défauts caractérisés à une I.B.M.I. (Infâme Bouillie Mal Identifiée). Réveillez-vous, ce temps-là est révolu : vous êtes devenu un programmeur de l’extrême, du genre agile, à développer selon les principes de l’industrie automobile (!) Il est grand temps pour vous de redécouvrir la joie du stress de dernière minute.

Petite remise en situation : nous sommes le jour J, il est 8h du matin, et l’exécutable ne démarre même pas. Il va falloir stopper la machine à perdre rapidement si vous ne voulez pas que toute l’équipe passe à la Gatling ! En ce qui vous concerne, voici le commandement qui vous incombe :

Ne travaillez jamais sur un coin de table.

Ça a l’air stupide, n’est-ce pas ? Pas plus que de mettre au point un exécutable à l’arrache (seule méthode fonctionnelle, à défaut d’être efficace) et de devoir avouer quelques jours plus tard qu’on ne sait plus quel est le code qui a servi à la livraison. Ou comment l’exécutable a été obtenu. «Mais enfin !», me diriez-vous, «seul un imbécile en arriverait là !» Ah bon ? Pas si sûr. Vu le maelström qui va se mettre en place jusqu’à tard dans la nuit, vous avez intérêt à vous assurer que personne ne sortira des ornières que vous aurez tracé. Bien entendu, oubliez momentanément une bonne partie de votre processus habituel de développement/livraison. Mais ne lâchez pas les fondamentaux :

L’intégralité du code servant à produire l’exécutable final est connu de l’outil de gestion de configuration.

L’exécutable livré est obtenu uniquement à partir de la chaîne de production officielle.

Vous pouvez même pousser le vice à fournir un gigantesque espace de patch que tout le monde ira bidouiller comme il le souhaite, mais cet espace est en conf. Demain, vous pourrez (faire) remettre au propre tout ça, demander des livraisons officielles des composants qui intègrent ces correctifs de dernière minute. Les développeurs pourront alors se poser la question si tel ou tel patch écrit en urgence est vraiment pertinent. Mais au moins ils auront une base claire de travail. Sans cela, vous passerez la semaine qui suit la livraison à retrouver vos petits, sous les quolibets de l’équipe de spécification et les remarques incendiaires des développeurs qui ne comprennent pas pourquoi ils devront faire deux fois le travail. Pas évident à vivre, surtout quand il faut livrer tous les mois.

Tags: ,

À chaque saint sa chandelle

Loutil des gagnants

L'outil des gagnants

N’hésitez jamais à contredire l’architecte du projet. Déjà parce que ça fait un bien fou. Ensuite parce qu’il n’a pas toujours raison, malgré ce qu’il peut penser. L’architecte moyen imagine et définit le logiciel comme il doit être à terminaison, et oublie toutes les étapes par lesquelles celui-ci doit passer avant d’être achevé. Comme une bonne partie des informaticiens, il ne prend pas en compte la problématique de l’intégration. La loi de Murphy étant ce qu’elle est, l’architecte vous pondra à coup sûr une organisation du logiciel qui vous empêchera de l’intégrer. Voilà un premier ennemi clairement identifié et facilement repérable.

Petit exemple récent, bien navrant : un premier livrable, fournissant interface et implémentation homogènes, est fourni par une seule et même personne. Par contre, grâce à la magie de la gestion de configuration, et sur décision de l’architecte qui défini  le découpage modulaire du logiciel, ce code est saupoudré dans tout un tas d’autres composants qui l’hébergent. Donc, ils le relivrent, puisqu’il est chez eux ! Question à deux francs six sous : comment l’intégrateur va-t-il garantir l’intégrité de ce livrable ? Autre question : comment utiliser une nouvelle version de ce livrable sans attendre de relivraison des autres composants ? Parfois, les outils de gestion de configuration déployés sur votre projet pourront vous aider à résoudre ce problème, plus ou moins élégamment, mais toujours de façon un peu alambiquées Un alambic étant de loin le dernier outil dont vous ayez besoin pour sortir un logiciel, soyez ferme, et encore une fois, exigez :

Le logiciel doit être découpé et organisé en composants dissociés livrés indépendamment.

Ne nous méprenons pas, il reste malgré tout à assurer la cohérence des différents bouts de logiciels entre eux (vous n’espériez quand même pas être payé à ne rien faire non mais hé !), mais au moins, chaque bout du logiciel est identifié de façon unique et vu par tous de la même manière.

Vous pourriez rétorquer, comme l’architecte en question, que le premier livrable n’est qu’une chimère, un artifice de travail, et que ce qui compte, c’est ce que publient les autres composants qui chacun embarquent une partie du code. Ça pourrait effectivement être le cas si un dernier composant ne se basait pas uniquement et intégralement sur la soit-disant chimère diluée dans tout le logiciel. Pour ce dernier composant, l’artifice est une réalité concrète, un tout indivisible. Et puis, ce serait de toute façon oublier un peu vite le besoin de cohérence du premier livrable. Refusant d’admettre un seul instant qu’il aurait pu oublier une hypothèse de travail dans son raisonnement parfait par essence, l’architecte, sûr de son fait, vous assène un fantastique « Miroir magique ! De toute façon c’est plus logique d’avoir le découpage que notre bon vouloir aura imposé à terme ! » Certes, mais le projet est encore loin d’être terminé. Si, quand tout marchera parfaitement, l’architecte souhaite ranger les fichiers dans les répertoires qu’il souhaite, vous serez prêt à lui offrir un accès toutes zones. Mais la route est encore longue et sinueuse, la pente plutôt raide… et l’architecte déjà retourné dans son bureau après avoir soigneusement refermé sa porte.

À ce stade de la conversation, Lucifer vient généralement vous tapoter l’épaule en vous souhaitant bon courage d’un air condescendant mais satisfait. L’enfer est pavé de bonnes intentions. Et les architectes s’occupent de l’entretien des voies.

Tags: ,

Ne nous associons qu’avec nos égaux

Vu ce à quoi vont ressembler vos journées, il est important qu’elles se passent sans énervement excessif. À cela, rien de plus simple : posez vos conditions ! Pas n’importe lesquelles bien sûr, mais au moins celle-ci :

Il faut au moins un responsable derrière chaque livrable, et plus d’un serait pêché.

Rien de plus agaçant en effet que de recevoir un bon de livraison, de se poser une question, voire de n’y rien comprendre, et de vouloir casser le nez en discuter avec… qui justement, si personne n’est identifié derrière cette livraison ? Bien entendu, il y a un piège : généralement, celui qui publie le bon de livraison n’est pas celui qui a fait le code ou connaît les contraintes induites par cette livraison. Celui que vous cherchez n’est pas non plus le responsable de l’équipe, qui gère la planification, les sous et l’avancement. Ou alors c’est un coup de pot inimaginable, vous êtes tombé sur quelqu’un de compétent sur son poste, dépêchez-vous de travailler avec lui avant qu’il ne soit muté à quelque chose de totalement inadéquat pour lui !

Non, il vous faut identifier celui – ou ceux, mais ne rêvons pas – qui connaît tout le contenu de la livraison, ses dépendances et ses implications. C’est cette personne que vous irez voir quand le doute vous étreindra (dois-je intégrer cette version en même temps que la nouvelle version de tel composant ? avez-vous bien pensé à reporter telle partie essentielle du correctif lambda ?) et qui vous répondra à peu de frais, et à coup sûr. Plutôt que de vous envoyer voir Perrin, qui a regardé la partie qui vous intéresse, à moins que ce ne soit Michel…

Et s’il y en a plus d’un qui peut tenir ce rôle, qu’il existe un autre indispensable ? Déjà, il doit toujours être fourré avec le premier. Dans ce cas, c’est facile, ils ne forment qu’une entité. Sinon, essayez de vous adresser toujours au même. Ça légitimera son statut dans le projet sans pour autant dénigrer l’autre. Et ça évite tout bruit de fond (désynchronistation entre eux, désaccord, etc.) C’est d’ailleurs ce qui justifie la seconde partie de la règle, dont voici le corollaire :

Pas plus d’une source d’information par donnée.

Pourquoi tout ceci est si important ? Parce qu’une personne forme à elle seule un consensus, à moins que vous ne travailliez avec des schizophrènes. Si vous posez une question à quelqu’un, il y a toutes les chances du monde qu’elle vous réponde toujours la même chose (jusqu’à ce qu’elle s’énerve. Et là…) Deux personnes sont toujours amenées à discuter un peu, peser le pour et le contre, s’interroger, même par pure réthorique, pour obtenir ce même consensus.  Vous n’avez pas envie d’assister à ces litanies. Donc, si vous identifiez la personne qui a toujours la plus grande probabilité de vous répondre correctement à tous les coups, vous irez de toute façon naturellement poser vos questions à celle-ci. Elle ne vous fera pas perdre votre temps, et vous ne ferez pas en perdre inutilement à toute son équipe. Et oui, tout le projet ne tourne pas autour de vous, ne l’oubliez pas non plus !

Tags: ,

Mieux vaut vivre seul que mal accompagné

Un grand logiciel (comprendre volumineux) ne se fait pas seul. Tout un microcosme est mis en place autour de lui pour lui permettre d’émerger, puis d’évoluer. C’est une sorte de société féodale, avec ses paysans et ses notables. Si j’essaie de vous dépeindre ça de façon posée et balancée, je dirais qu’on y retrouve, pêle-mêle :

  • des développeurs, qui constituent de loin le groupe le plus nombreux. Les roturiers par excellence. Ils sont souvent dénigrés, voire totalement ignorés par les autres groupes, qui oublient tout de même qu’ils sont la cheville ouvrière du projet et que sans eux, rien ne fonctionnerait non plus. Mais ça ne les excuse pas de profiter de la première opportunité pour tenter de rouler les autres groupes, en livrant des demies versions, ou en se détachant de toute responsabilité quand un problème technique survient ;
  • des experts, dans tout un tas de domaines. Plus le domaine est pointu et abscons, plus l’expert est fier et détaché du monde réel, parce qu’il pense être légitimement respecté. Ce qui serait le cas si ses chevilles faisaient office de lest, et son intérêt pour le projet était plus marqué ;
  • des architectes. Le rôle de l’architecte est d’avoir un avis sur tout qui fait office de loi. Un représentant de l’Église en somme. Faire respecter la loi est dégradant à ses yeux, il ne s’en charge donc pas. Ce qu’il ignore, c’est que personne ne le fera à sa place. Il est donc tout aussi utile qu’un expert ;
  • des intégrateurs. Ils sont les vrais dépositaires du pouvoir et font vivre le projet. Alors, conscients de leurs responsabilités, en bons régents de l’état, ils occupent sagement leurs journées,  en terrorisant les développeurs, en envoyant les architectes manger du foin, et en dénigrant les experts qui sont toujours à parler du cinquième bit du huitième octet de l’entête de la trame réseau ;
  • des gestionnaires de configuration. Ils gèrent le code et toute la documentation associée. Ces moines copistes répliquent, reprennent, rangent, sans vraiment comprendre ce qu’ils font. Ils introduisent de l’entropie, en portant à moitié des correctifs, en en perdant d’autres. Ils font bien entendu retomber la faute sur les développeurs. C’est aussi grâce à eux que le projet n’avance pas trop vite. Un bon gestionnaire de configuration sait freiner les autres au-delà du raisonnable, sous couvert d’une bonne excuse technique (« ho ! le serveur a encore rendu l’âme ! Vivement que le support technique installe le patch n°561831 ! ») ;
  • des spécificateurs. Ils pensent connaître le produit, qu’ils appellent système pour pouvoir survivre en milieu mondain. Mais comme ils ne discutent pas avec les développeurs, ces sales paysans boueux qui passent leurs journées les mains dans la fange du code, il y a souvent un certain écart entre la théorie et la pratique. Un moment d’humour sans cesse renouvelé consiste à coller un spécificateur devant un banc de validation ;
  • des vérificateurs. Ils utilisent des plans de test écrits par les spécificateurs pour valider un logiciel qui ne démarre même pas. Ils passent ainsi toute leur vie assis entre deux chaises, en disant « amen » à tout ce que demande le client, juste avant de se prendre une révolte paysanne bien méritée dans les dents, pour avoir enterriné l’idée que ce serait mieux si le programmateur de machine-à-laver qu’il faut livrer dans deux jours savait aller récupérer le temps de cuisson du poulet sur l’Internet (oui, j’écris l’Internet, ça énerve tout le monde, moi y compris).

Bien entendu, la vérité est bien pire ! J’aurais l’occasion d’y revenir par la suite.

Tags: