Les 7 familles de bugs

Ca-y-est, c’est la panique ! Le client est bloqué et menace de rompre le contrat si les problèmes ne sont pas résolus avant la fin de la semaine. Le directeur informe alors le responsable qui convoque le chef de projet (ou de produit) pour qu’il réquisitionne immédiatement ses développeurs afin de corriger les bugs au plus vite.

Déjà-vu ? Sans blague ! Et oui, encore une fois, les développeurs vont se mettre à l’œuvre, modifier quelques lignes de code qui seront livrées au client pour le débloquer. Et au final, que retiendra-t-on de cet évènement ? Qu’il restait un bug dans le code.

Alors c’est ça la fin de l’histoire ? Les départements informatiques, les équipes projets et les R&D grouillent de gens plus expérimentés, plus respectés, et mieux payés que les développeurs, mais au final, le bug et sa résolution resteraient le fait du développeur ?
Eh bien non ! C’est faux. Ils ne sont pas les seuls à faire des bugs. En voici pour preuve les 7 familles dans lesquelles il est possible de classer la quasi-totalité des bugs :

1. Le bug du débutant : il s’agit le plus souvent d’une mauvaise gestion des cas limites dans l’implémentation des algorithmes : non vérification de la valeur des paramètres d’entrée d’une fonction, dépassements de capacité d’une pile ou d’un tableau, tentative d’accès à une ressource non disponible. Ces bugs doivent être éliminés par les tests unitaires. A noter que ces bugs peuvent également apparaître lorsque le développeur est optimiste ou trop pressé.

2. Le bug du collègue : les développeurs s’appuient parfois sur le travail d’un collègue pour ne pas avoir à redévelopper une fonction, une classe ou un composant. Si le code du collègue contient des bugs, ceux-ci seront immanquablement intégrés dans le logiciel final. Depuis quelques années, la démocratisation des frameworks Open-Source a poussé la réutilisation de code jusqu’à un niveau jamais atteint. Dans ce cas, il s’agira plutôt d’un confrère que d’un collègue.

3. Le bug du testeur : le testeur doit mettre en place un environnement reflétant les futures conditions d’utilisation du logiciel. Il doit faire en sorte que la couverture fonctionnelle qu’il adresse soit complète, que les jeux de données ou les scénarii qu’il utilise soient représentatifs et permettent de couvrir tous les chemins possibles. Il doit tester dans les conditions réelles d’utilisation : versions de SGBD, serveur d’application, OS, middleware….

4. Le bug du release manager : le release manager est responsable de la production des livrables à partir du code source. Il doit veiller à utiliser la bonne version des sources et les bonnes options de compilation. Ces opérations, peuvent être jugées triviales, mais elles sont en réalité particulièrement délicates lorsqu’il s’agit de produire des correctifs de type Hot-fix, ou lorsque le même code source est destiné à produire plusieurs versions des livrables (multi OS, 32bits/64bits).

5. Le bug de l’architecte : ses symptômes peuvent être très variées : difficultés lors de l’intégration dans l’écosystème cible, incapacité à supporter la montée en charge, impossibilité d’intégrer des évolutions fonctionnelles pourtant « raisonnables ». De plus, il apparaît souvent tard dans le cycle de vie du logiciel, parfois bien après la mise en production. C’est pourquoi il est souvent difficile à diagnostiquer. Pourtant, ses causes sont souvent les mêmes : non respect des principes de base (KISS, SOLID, etc.), choix de composants tiers non adaptés, définition d’architectures non scalables ou difficilement testables, etc.

6. Le bug du chef de projet : l’incapacité à collecter une expression du besoin complète, l’incapacité à chiffrer correctement la charge de développement, l’incapacité à négocier un planning raisonnable avec le client, l’incapacité à maîtriser les évolutions du périmètre alors que les développements sont déjà en cours sont les bugs typiques du chef de projet.

7. Le bug du directeur : certains directeurs refuseront probablement d’admettre qu’eux aussi font des bugs, mais soyons réalistes ! Le refus d’approuver l’achat d’un composant à 1 000 € qui permettrait pourtant d’éviter un développement de 50 jours à faible valeur ajoutée ou complètement en marge du projet et qui ne pourrait de toute façon pas être testé correctement est clairement une source de bugs. Idem pour le refus d’investir dans des plates-formes matérielles ou logicielles qui reflètent les conditions réelles d’utilisation du logiciel.

Bref, pour résumer, les débutants font des bugs de débutant, les développeurs expérimentés ne font plus de bugs, et tous les autres bugs sont produits par des intervenants non développeurs ! Et pourquoi pas ?

Eh bien non ? Ca aussi c’est faux ! Et disons-nous le une bonne fois pour toutes, du débutant au directeur, tout le monde fait des bugs ! Et ce n’est pas parce qu’un développeur peut bricoler en quelques heures une parade à une anomalie bloquante que c’est lui qui était à l’origine du bug.

La vague de Google est un raz-de-marée !

Hier, Google nous a conquis en ouvrant des chantiers qu’aucun autre acteur n’avait osé ouvrir auparavant, en tous cas pas dans des proportions équivalentes. Certaines des applications qui en ont résulté sont devenues incontournables, en allant la plupart du temps bien au-delà de ce que l’on pouvait imaginer :

Qui pensait qu’il serait possible d’indexer la quasi totalité du web mondial et de ses images ? Google l'a fait ;
A une époque où le SaaS se résumait souvent à des White Papers, qui avait réellement besoin d'une suite bureautique complète en mode hébergé ? Google a fait Google Docs ;
Qui avaient réellement besoin de pouvoir naviguer sur un planisphère et de zoomer au point de pouvoir compter le nombre de piscines dans sa rue ? Google a fait Google Maps,
Nous rêvions tous d’un client de mail léger, simple et rapide. Google a fait LE client de mail ultime : GMail.

Aujourd’hui, Google nous livre au travers de ses Vagues une vision des communications révolutionnaire où le mail, la messagerie instantanée, le forum, le réseau social, la suite bureautique et le wiki se combinent avec une intuitivité hors norme, et bien-sûr, dans notre navigateur !
Lars RASMUSSEN – le père de Google Maps – présente ses Vagues avec passion et beaucoup d’humour dans une très looooongue vidéo. De prime abord, son accent australo-écossais est déroutant, mais on s’y habitue rapidement.

« Google redéfinit la relation entre l’utilisateur et le logiciel. »

Au-delà des robots, gadgets et autres extensions que la communauté des développeurs a déjà commencé à apprivoiser (voir mon premier robot), c’est toute une philosophie que Google nous propose et qui dessinera certainement le contour des logiciels de demain :
La relation entre utilisateur et logiciel est redéfinie : ce n’est plus l’utilisateur qui interroge son application, mais c’est cette dernière qui diffuse l’information pertinente dès quelle est disponible.
L’information devient indépendante de sa forme et de son support. Il est possible d’intégrer indifféremment du texte, des images, des tableaux, des éléments de conversation, des gadgets (éventuellement connectés au Web) au même document. Le concept vieux de 25 ans de cette suite bureautique où un programme ne sait manipuler qu’un seul type de donnée est obsolète.
Les flux d’entreprise seront simplifiés : à quoi bon continuer à modéliser la circulation des documents entre différents contributeurs dès lors que ceux-ci peuvent effectuer à volonté des mises à jour chirurgicales qui seront historisées et instantanément répercutées vers tous ceux qui ont accès au document ?

« Une vague et quelques robots pourraient à eux seuls remplacer un ESB ! »

L’implémentation dans les applications métiers du Google Wave Federation Protocol permettra à terme de dépasser le cloisonnement existant aujourd’hui entre les applications d’entreprise : le vieux schéma où un collaborateur utilise sa messagerie ou des fichiers d’échange pour exporter des informations d’une application à l’autre va disparaître. Une vague et quelques robots pourraient à eux seuls remplacer un ESB !

« L’Entreprise 2.0 a trouvé son framework ! »

Enfin, l’utilisateur d’applications métiers ne sera plus isolé ; il sera désormais membre de communautés métiers, verticales ou transversales. Il ne subira plus son environnement, mais en sera l’acteur principal. Les applications seront moins rigides ; elles seront connectées entre elles. L’Entreprise 2.0 a trouvé son framework !

Google a une fois de plus fait un pas de géant et bouscule au passage des habitudes et des standards vieux de 30 ans. Et c'est le quotidien des développeurs d’applications qui promet d’être plus passionnant encore !

Oui au wiki !

Voici comment j'ai proposé au manager de mon équipe d'utiliser d'un Wiki:

L’équipe de développement dans laquelle je travaille comporte une dizaine de personnes : un consultant Oracle, des fonctionnels SAP, des développeurs ABAP et des spécialistes du développement traditionnel dont je fais partie.

Nous ouvrons en ce moment même un chantier de développement qui durera un an au moins et dont l’objectif est de livrer une version majeure de notre gamme de logiciels :

• Unification des accès à tous les applicatifs à travers un portail d’accès unique,
• Rationalisation de tous les flux de communication inter-applications (notamment avec SAP et Oracle eBusiness Suite),
• Création d’un framework permettant de plugger des « Business Solutions » orientées circulation de documents (factures, demandes d’achat).

L'ampleur de la tâche qui nous attend est immense !

Lors des réunions communes de cadrage qui ont eu lieu l’été dernier, je me suis souvent rendu compte du décalage culturel qui existait entre tous les membres de notre équipe. SAP est un domaine tellement vaste qu’à ma connaissance, aucun consultant n’en a fait le tour. Personnellement je n’y connais rien du tout, et jusqu’à présent j’ai très bien vécu ainsi. Mais j’ai également été surpris de voir que certains programmeurs ABAP ne connaissaient rien ou presque de ce qui fait mon quotidien : XML, HTTP, Service Web, .NET, Java… Tout ceci était du chinois ! Eh bien ces personnes et moi allons devoir collaborer étroitement.

De plus, qui a déjà essayé de faire valider par mail un compte-rendu de réunion à 10 personnes sait que cela relève de la prouesse visuelle.

Tes remarques, c’était celles en mauve ?

- Non ! moi, c’était les violettes ?

Daltoniens s’abstenir !

Le mode révision de Word montre également bien vite ses limites, dès que l’on commence à modifier des schémas, ou lorsqu’il faut intégrer les modifications de 3 collègues en même temps.

Je suis convaincu que le succès des projets ambitieux repose sur des critères autres que techniques.

La communication, la collaboration, la documentation, l’implication, la visibilité sont les clés de la réussite. J’ai donc cherché à proposer une organisation qui mettrait ces notions au centre de notre vie de tous les jours, et j’ai identifié l’outil pour ça : un wiki.

Après quelques recherches, j’ai donc téléchargé et installé sur un de nos serveurs Foswiki qui présente l’avantage d’être open-source, gratuit, et bien adapté au travail en entreprise avec la possibilité d’authentifier les utilisateurs et de contrôler finement les accès. Après environ 2 jours de paramétrages, j’ai fait une démo hier au manager de notre équipe qui a immédiatement été convaincu par la pertinence de cette solution.

Nous allons présenter cet outil aux autres membres de l’équipe cet après-midi. A suivre…