Pourquoi les développeurs laissent-ils des bugs dans leurs applications ?

icon Tags de l'article :

Novembre 09, 2011

 

Une de mes collègues a posé plusieurs fois cette question ces derniers jours. Et je me suis rendu compte que c’était assez difficile à expliquer à un non informaticien. Mais pour cela, j’ai trouvé un parallèle plutôt simple :

Développer une application, c’est comme écrire un livre à la machine à écrire.

En effet, je vous défie d’écrire une page de texte à la machine sans faire de fautes. C’est très difficile. Il faut sans cesse réfléchir avant d’écrire, faire attention à ce qu’on écrit, se relire et corriger les fautes lorsqu’on a eu le malheur d’en faire. Et lorsqu’on se relit, on peut facilement rater des fautes qui auraient sauté aux yeux d’autres personnes.

Maintenant, quel est le lien avec le développement ? C’est exactement la même chose, avec un impératif de temps très serré en plus. 

Imaginez ceci : 

"Voici une machine à écrire. Je veux que tu me rédiges un roman de 500 pages avec. Je ne veux pas voir de blanc ou de fautes sur ce roman. Tu as 2 semaines."

Voilà, à peu de choses près, la vie d’un développeur.

Et après, on ose nous demander POURQUOI il reste toujours des bugs dans nos applications, et POURQUOI on n’a pas pu faire plus vite telle ou telle tâche.

Pfffff...

Enfin, vous savez tous qu'un livre doit avoir une bonne structure, être cohérent et offrir une histoire intéressante. L'auteur doit également faire attention au vocabulaire, aux répétitions, aux temps, à la formulation, ... Et bien c'est encore une fois la même chose pour le développement d'une application ! (Architecture de la solution, cohérence du code, parcours utilisateur agréable, optimisation des performances de l'application, factorisation du code, ...)

image modifiée de chefranden, sous licence CC

6 commentaires

Nico - 10/11/2011 à 08:38:12

Et le pire c'est quand on te demande de rajouter un paragraphe en plein milieu de la page 27 alors que tu as fini la rédaction du livre.

:D

@répondre #lien

Tommy - 10/11/2011 à 09:45:23

Oui, j'avoue que ça aussi, c'est pas mal !

:)

@répondre #lien

le hollandais volant - 11/11/2011 à 18:55:29

au début (en lisant le titre), je pensais que c'était encore un de ces journalistes qui aurait pu dire que les dev laissaient des bug pour pouvoir vendre des mises à jours (cf ça : http://lehollandaisvolant.net/index.php?2011/06/15/18/12/51-non-mais-je-reve )

Mais en fait, tu as raison : les bug dans un code, c'est comme des fautes d'orthographe dans un roman.
Aussi attention qu'on fasse, autant de fois qu'on relise, il restera toujours une faute que quelqu'un va trouver.

Et même quand tout marche, il arrivera un moment où l'on tombera sur un puriste qui voudra remonter dans les méandres de la grammaire pour chercher la minuscule faute qui va tout faire planter.

(exemple : « autant pour moi »(faux, mais toléré) VS « au temps pour moi » (vrai) ou « soient deux nombres A et B » (faux mais toléré) VS « soit deux nombres A et B » (vrai)).

@répondre #lien

Le petit Marocain - 11/11/2011 à 19:14:27

Je pense que l'exemple de la machine à écrire en est un mauvais.

Pourquoi ?

L’écrivain peut écrire un roman à main levé avant de le taper sur la machine à écrire. Sur la feuille écrite à main levé il pourra éditer, cocher et barrer ce qui ne va pas puis ensuite s'il pense que tout est bon, il tapera ça sur la machine à écrire une bonne fois pour toute.

Ce qui donne pour le développeur:

Bêtement: Tester l'application en locale avant de la mettre en ligne.

@répondre #lien

Tommy - 11/11/2011 à 21:10:15

@timo : Et oui. Et encore, à l'instar du processus d'impression des livres absolument incontrôlable par les auteurs, tout ce qui est hébergement, frameworks et bibliothèques peuvent contenir des bugs ! J'ai déjà eu affaire à une méthode du framework .Net qui ne marchait pas !
Il est toujours possible de faire du code sans bugs (je pense aux programmes dans les fusées et dans l'armée par exemple), mais le temps nécessaire est 10 à 20 fois supérieur au temps de développement qu'il faudrait normalement...

@Le petit Marocain :
Pour moi, l'exemple est toujours valable. Ce n'est pas parce qu'on recopie des notes papier qu'on ne fera pas de fautes, au contraire. En relisant le brouillon, on modifiera certaines choses et on sera moins attentif qu'à la première rédaction, car on sera, forcément, moins intéressé... Du coup il peut toujours y avoir des fautes...
Ensuite, pour une grosse application, c'est difficile voire impossible de tout tester en local.

Par exemple, au travail, on vient de terminer un site web sur lequel on travaille depuis 7 mois à 6 développeurs... On a eu 3 mois de tests réalisés par deux personnes à plein temps, et pourtant on a enchainé 2 nuits blanches pour sortir le projet à temps !

On a eu des problèmes dans le code, des cas un peu spécifiques non gérées, des changements métier de dernière minute, des problèmes avec notre hébergeur cloud, des problèmes de déploiement et des problèmes de compatibilité avec d'autres applications... Et pourtant on a fait tout ce qu'on pouvait, et tout a été testé trois fois (développement, recette et préproduction) !

Il y a toujours des bugs, qu'on le veuille ou non. Le seul moyen de les éviter, c'est d'augmenter au maximum les durées de développement et d'utiliser du mieux qu'on peut les bonnes pratiques (design patterns connus, tests unitaires, tests de non régression, relecture de code par quelqu'un d'autre, ...).

Et dans le monde du travail... disons que très peu (aucune ?) de sociétés vous donneront les délais nécessaires à l'élimination de la majorité des bugs. Malheureusement.

@répondre #lien

lap1.blanc - 09/08/2012 à 15:01:12

Je commente presque un an plus tard, mais même l'idée de "si on avait tout le temps nécessaire à l'élimination de la majorité des bugs" n'est pas viable. Ça permettrait effectivement d'avoir une application "sans bugs", mais ça donnera surtout une application dépassée voire ne répondant même plus au besoin.

Le problème des bugs n'est pas vraiment qu'ils apparaissent. C'est la communication et le temps de correction derrière qui sont importants au final. Viser le "Zéro bug", c'est comme le "risque zéro", ça plaît à ceux qui n'y connaissent rien et qui se chient dessus à longueur de journée, mais ce n'est pas viable pour ceux qui sont en charge de l'appliquer, ceux qui subissent ni pour ceux qui réfléchissent en termes pragmatiques et macroscopiques.

Après, il faut que la gestion de bugs fasse partie intégrante d'un projet (la TMA mais pas seulement). On voit fleurir ça et là des messages d'erreurs beaucoup plus sympas que "j'ai planté". Par exemple, un message un peu plus "fun", même en entreprise, passera beaucoup mieux.

"Oops, il semblerait que vous ayez pris en train de faire une bêtise. Pour nous aider à ce que ça ne se reproduise pas, contactez nous par téléphone ou mail en prenant soin de nous fournir les informations ci-dessous. Ça ressemble à un message codé, mais croyez nous, ça nous aidera grandement !", c'est le type de message que je rêve de mettre en place.

À vouloir trop bien faire du premier coup, on en oublie la partie à la fois informatique et humaine d'un projet informatique : gérer nos erreurs.

@répondre #lien

icon Flux RSS des commentaires de cet article

Les commentaires sont fermés pour cet article