Les bogues tuent-ils votre élan ?

Les bogues logiciels sont monnaie courante dans le monde de la technologie. Si vous avez déjà écrit plus de dix lignes de code, il y a de fortes chances que vous en ayez accidentellement causé une.

Maintenant, j'aimerais que vous pensiez à la dernière fois où vous avez reçu un message d'un client ou d'un collègue paniqué à propos d'un bogue. Comment ça s'est terminé? Le bug était-il si urgent que vous avez dû arrêter ce que vous faisiez ?

Dans cet article, nous allons essayer de remettre en question la pensée conventionnelle sur les bogues et d'explorer combien chaque bogue vous coûte, à vous et à votre équipe.

Sur moi

Salut 👋, je m'appelle Krste et je suis un développeur full-stack qui travaille dans des startups depuis plus de sept ans. Récemment, j'ai cofondé Bugpilot , une plateforme de surveillance des bogues qui alerte les équipes logicielles sur les bogues critiques rencontrés par les utilisateurs.

J'ai écrit cet article dans le but de remettre en question la pensée conventionnelle sur les bugs et le "nous devons le corriger dès que possible!" état d'esprit, remettant en question la nécessité d'explorer le coût réel de chaque problème.

Logiciel 100% sans bogue. Mythe ou réalité ?

L'objectif d'obtenir un logiciel 100% sans bogue a toujours été délicat. L'idée de créer une application sans bogue peut sembler idéale, mais est-ce réellement possible ?

La vérité est que les bogues logiciels sont inévitables en raison de la logique métier complexe, des erreurs humaines et des mises à jour continues de la technologie. Même avec des tests minutieux et des contrôles de qualité, il est difficile de les éliminer complètement.

Grâce à de nouveaux outils de développement et à des processus améliorés, les équipes proposent désormais de nouvelles fonctionnalités à un rythme fulgurant pour pouvoir rester pertinentes et compétitives.

Et, avec toute modification de la base de code, il est toujours possible de casser quelque chose. (Devoir prendre en charge de nombreux appareils et plusieurs navigateurs n'aide pas du tout.)

Bien sûr, il y a des cas où les bogues doivent être proches de zéro. Certaines industries, comme la banque, la médecine et l'aérospatiale, doivent s'assurer que les erreurs sont réduites au minimum, car elles pourraient potentiellement coûter des vies .

Cela explique pourquoi la plupart des logiciels de ces industries sont écrits dans des technologies d'il y a des décennies et pourquoi les gens hésitent maintenant à y toucher.

Mais en fin de compte, nous devons nous demander : " Est-ce que tout cela en vaut la peine ?"

Tous les bogues ne sont pas égaux

Imaginez que vous travaillez sur un site Web de commerce électronique et qu'un bogue interrompt le processus de paiement, empêchant les clients de finaliser leurs achats.

Il est douloureusement évident que ce bogue nécessite une attention immédiate car il a un impact direct sur la fonctionnalité de base et entraîne potentiellement des ventes perdues et des clients insatisfaits.

De même, nous ne pouvons pas traiter un bogue dans la page d'inscription qui empêche les nouveaux utilisateurs de rejoindre notre nouvelle application de covoiturage de la même manière qu'un problème lié à la mise à jour de la photo de profil .

Ces exemples en noir et blanc montrent que non seulement nous devons détecter, mais nous avons besoin d'un moyen de comprendre l'impact des bogues. Cependant, en réalité, les choses ne sont pas en noir et blanc. La plupart des situations se situent dans la zone grise. La question devient alors : comment savons-nous ce qu'il faut réparer ?

« NOUS DEVONS LE RÉPARER MAINTENANT OU LE CLIENT VA PARTIR »

J'ai remarqué que nous avons tendance à ajouter un sentiment d'urgence "supplémentaire" aux bugs que nos clients trouvent.

Vous avez probablement été dans une situation similaire lorsqu'un de vos plus gros clients a un problème mineur et que toute votre équipe est inondée de messages comme si le monde était en feu 🔥

”Giovanni s'est plaint de ne pas pouvoir aligner le texte à droite 11 1 C'est un client important. Nous devons corriger le bug MAINTENANT !"

- votre patron

D'après mon expérience, les rôles en contact avec les clients tels que la réussite des clients, le support et les ventes ont tendance à hiérarchiser les problèmes en fonction de la réaction du client et de la manière dont cela affecte sa réputation. C'est pourquoi tout peut leur sembler très important, ce qui est compréhensible.

Personne ne veut faire mauvaise impression ou avoir une mauvaise réputation, et c'est exactement ce que les bogues peuvent causer.

Plus il y a d'utilisateurs affectés par un bogue, plus il est (probablement) important de le corriger

Parfois, les problèmes de production sont traités au fur et à mesure qu'ils surviennent. Surtout nous, les développeurs, sautons immédiatement sur tout bogue ou erreur de codage qui arrive dans leur boîte de réception.

Vous ou votre équipe utilisez peut-être un outil tel que Sentry ou Bugsnag pour surveiller et être averti lorsque des erreurs se produisent. Lorsqu'une erreur est détectée, elle est rapidement attribuée à un développeur tandis que tout le monde attend avec impatience une mise à jour dans Slack.

Généralement, ces outils hiérarchisent les erreurs en fonction de leur fréquence et du nombre d'utilisateurs concernés.

Human.prioritizeBugs()

Cependant, la priorité de la plupart des bogues dans la plupart des équipes est probablement déterminée soit par le propriétaire du produit, soit par le développeur principal. Ces rôles comprennent généralement la logique métier, la technologie sous-jacente, la charge de travail actuelle et les priorités à venir et planifient en conséquence.

Leurs critères de priorisation pourraient ressembler à ceci :

Est-ce critique ou non ? Première question, mais ça devient déjà un peu délicat. Qu'est-ce qui est critique ? Critical n'a pas de définition claire. Si une fonction principale est inutilisable, il est assez évident que nous devons la réparer. Cependant, comme vous l'avez vu dans l'exemple ci-dessus, que se passe-t-il si un client important est affecté ?

Combien de clients cela impacte-t-il ? Juste un? Tout le monde? Sait-on même ? Lorsqu'un nombre important d'utilisateurs est impacté, vous souhaiterez peut-être résoudre le problème, même s'il est lié à une fonctionnalité mineure.

Combien de temps faut-il pour le réparer ? Ensuite, le propriétaire du processus "Bug Triage" demandera combien de temps il faut pour résoudre le problème. Si cela ne prend que quelques heures, ils trouveront des moyens de l'insérer dans le travail de cette semaine.

"Réparer (ASAP) ou ne pas réparer, telle est la question."

Les développeurs sont souvent confrontés à un dilemme lorsqu'ils traitent un bogue "urgent". Ils peuvent soit se précipiter pour terminer leur tâche en cours et corriger le bogue, en introduisant éventuellement de nouveaux bogues dans le processus ; ils ignorent fréquemment la surcharge de changement de contexte , car ils peuvent brusquement porter leur attention sur le bogue, abandonnant complètement leur tâche actuelle.

Il y a trois problèmes importants avec ces scénarios :

1. L'équipe établit des priorités de manière incorrecte, ce qui peut entraîner une perte de temps et la correction de bogues moins pertinents.

   
   

2. L'ajout d'une urgence inutile aux bogues non critiques oblige l'équipe à changer inutilement de focus.

   
   

3. Avant de traiter un bogue, il est important de considérer son coût . Alors, combien coûte réellement un bogue à l'équipe ? La réparation est-elle un coût raisonnable ?

Combien coûte la correction d'un bogue ?

Avez-vous déjà entendu parler de la phrase "Il n'y a pas de repas gratuit ?"

Lorsque nous parlons de coût, la première chose à laquelle nous pensons en tant que développeurs est le coût de l'infrastructure, le coût d'un serveur, d'une fonction Lambda, d'un cluster MongoDB, etc. Cependant, quand il s'agit de bugs, je parle d'un coût lié à l'humain : l'attention .

Changement de contexte

Si vous avez étudié l'ingénierie informatique ou si vous avez déjà lu sur le fonctionnement du système d'exploitation, vous avez probablement entendu parler du changement de contexte.

En informatique, un changement de contexte est le processus de stockage de l'état d'un processus ou d'un thread, afin qu'il puisse être restauré et reprendre l'exécution ultérieurement, puis de restaurer un état différent, précédemment enregistré.

(depuis [Wikipedia](https://Context switch https://en.wikipedia.org › wiki › Context_switch))

Un cas de commutation de contexte de système d'exploitation pourrait être le multitâche : la commutation de contexte est caractéristique du multitâche qui permet au processus d'être commuté depuis le processeur afin qu'un autre processus puisse être exécuté.

Où ai-je déjà entendu ces mots 🤔 ? - Ah oui:

"Je suis un maître du multitâche."

Le multitâche peut avoir lieu lorsqu'une personne essaie d'effectuer deux tâches simultanément, de passer d'une tâche à une autre ou d'effectuer deux tâches ou plus en succession rapide.

Faire votre lessive tout en discutant avec un ami fonctionnera probablement très bien. La partie délicate survient lorsque nous effectuons des tâches mentalement complexes, comme écrire du code.

Les psychologues ont mené de multiples expériences sur le changement de tâche pour déterminer ses coûts. Ils ont mesuré le temps qu'il faut aux gens pour accomplir des tâches et le temps qu'il leur en coûte pour passer de l'une à l'autre. Les résultats étaient les suivants :

“ Bien que les coûts de changement puissent être relativement faibles, parfois juste quelques dixièmes de seconde par changement, ils peuvent s'élever à des montants importants lorsque les gens passent d'une tâche à l'autre à plusieurs reprises. … passer d'une tâche à l'autre peut coûter jusqu'à 40 % du temps productif d'une personne.

"Avez-vous une minute?"

Imaginez ceci : vous êtes enfermé, complètement immergé, et rien ne peut vous empêcher de terminer cette nouvelle fonctionnalité brillante. Le monde extérieur n'existe même pas - c'est juste vous et votre code. Mais ensuite, vous entendez une sonnerie venue de nulle part... une nouvelle notification sur votre téléphone.

C'est ton ami qui t'invite à boire ce week-end. Et juste comme ça, pouf , les 20 prochaines minutes de ta vie sont passées.

Ou peut-être venez-vous de recevoir un message Slack de votre collègue vous demandant si vous avez une minute pour aider à résoudre un problème spécifique.

La seconde situation est-elle plus acceptable que la première ?

Bon, au final, ce n'est pas grave. Basé sur une analyse de 10 000 sessions de programmation enregistrées par 86 programmeurs utilisant Eclipse et Visual Studio et une enquête auprès de 414 programmeurs ( Parnin:10 ) trouvé :

• Un programmeur prend 10 à 15 minutes pour écrire plus de code après avoir repris le travail après une interruption.

• Lorsqu'il est interrompu lors de la modification d'une méthode, seulement 10 % des fois, un programmeur reprend son travail en moins d'une minute.

• Un programmeur est susceptible d'obtenir une seule session ininterrompue de 2 heures par jour.

Les développeurs ont tendance à éviter ( et à détester ) le changement de contexte lorsqu'il s'agit de réunions inutiles. Pourtant, je pense que nous pourrions être en quelque sorte aveugles lorsque nous changeons de contexte entre les «tâches de développeur» et ignorons complètement son effet négatif.

Dernières pensées

Dans le monde réel, nous avons toujours affaire à des ressources limitées, qu'il s'agisse d'argent, de temps ou d'attention .

La correction des bogues a un prix.

"Non" est non à une chose. "Oui" est non à beaucoup de choses. –Jason Fried

Dire "oui" à la correction d'un bogue signifie dire "non" à une fonctionnalité. Le multitâche peut sembler efficace à première vue, mais passer d'une tâche à l'autre prend plus de temps et introduit finalement plus de bogues.

Comprendre les coûts cachés du changement de contexte vous aide à faire de meilleurs choix sur les bogues qui valent la peine de tout supprimer et ceux qui ne le sont pas (la plupart ne le sont pas).

Devrions-nous arrêter de nous soucier des bugs ?

Et bien non. Cependant, nous devrions au moins être conscients du coût de la correction des bogues et nous demander : « Est-ce que cela vaut la peine de le réparer ? » Il peut être difficile de s'asseoir calmement et d'accepter les bugs.Nous avons tous un désir intérieur de produire un travail de haute qualité et de construire quelque chose dont nous pouvons être fiers.

Malheureusement, ces bogues embêtants gênent souvent.

Comme l'écrit Tom De Marco dans son livre "Peopleware" , cela pourrait expliquer pourquoi il est difficile d'arrêter de se soucier de la qualité :

Nous avons tous tendance à lier fortement notre estime de soi à la qualité du produit que nous produisons, non pas à la quantité de produit, mais à la qualité. (Pour une raison quelconque, il y a peu de satisfaction à produire d'énormes quantités de choses médiocres, bien que cela puisse être exactement ce qui est requis pour une situation donnée.)

– Peopleware

Devrions-nous consacrer plus d'efforts à la prévention des bogues ?

Comme je l'ai mentionné plus tôt, vous n'avez pas le choix dans de nombreuses industries. Là, vous devez prendre toutes les mesures nécessaires pour éviter que des erreurs ne se produisent et les corriger le plus rapidement possible.

Mais, pour la plupart des applications, l'effort supplémentaire en vaut-il la peine ?

PS À la fin de la journée, même si nous avions une baguette magique qui corrige tous les bugs, nos utilisateurs trouveraient toujours un moyen d'abuser de notre application 😅