Magnus Manske est un développeur inconnu du grand public, on lui doit pourtant des contributions nombreuses et décisives pour le développement initial de Wikipédia, sa maintenance continue et son ingénierie, au point que les wikipédiens célèbrent chaque 25 janvier le Magnus Manske Day.
On imagine aisément à quel point ses journées sont bien remplies, d’autant qu’il donne son temps et son énergie pour le Libre sur son temps… libre !
Dans l’article dont nous vous proposons la traduction, il explique avec un brin de malice pourquoi les bugs apparemment les plus simples à traiter peuvent s’avérer les plus longs à régler… Deux minutes de lecture pour un petit article qui parlera à nos amis développeurs (ces indispensables travailleurs de l’ombre) comme il a parlé à Luc, notre tech warrior tout-terrain…
Non, je n’ai pas corrigé ton bogue, voici pourquoi
par Magnus Manske – article original : Why I didn’t fix your bug
Photo par Jason Krüger [CC BY-SA 4.0], via Wikimedia Commons
Et je n’ai rien fait. Je n’ai même pas répondu.
Rien n’indique que j’ai vu le problème.
C’est frustrant, je sais. Tu veux juste que ce petit truc soit réparé. En tout cas, tu te figures que c’est un tout petit changement à opérer.
Voyons maintenant les ressources disponibles, ce qui, en l’occurrence, est mon temps. En commençant par les gros travaux (estimations générales, des variations saisonnières sont inévitables) :
Il y 24 h dans une journée
– 9 h de travail (y compris le trajet en voiture)
– 7 h de sommeil (j’espère en tout cas)
– 2 h de vie privée (manger, faire de l’exercice, prendre une douche, lire, passer du temps avec ma copine, etc.)
= il reste 6h
On ne peut pas discuter avec ça, n’est-ce pas ? Maintenant, 6h qui restent, c’est une estimation haute, évidemment ; le travail et la vie privée peuvent (et ça arrive) prendre bien plus de temps, sur une base quotidienne et très variable, comme c’est le cas pour chacun de nous.
Alors je peux régler ton problème, c’est ça ?
Voyons voir :
6h
– 1h de maintenance (redémarrage des outils, mise à jour des pages GLAM, ajout et correction des catalogues mix“n”match, etc.)
– 3h de développement/réécriture (parce que c’est de là que viennent les outils)
= il reste 2h
Deux heures par jour, ça fait beaucoup, non ? En réalité, c’est beaucoup moins, mais restons-en là pour l’instant. Quelques-uns de mes outils n’ont pas de problèmes, mais beaucoup en ont plusieurs en cours, donc supposons que chaque outil en a un :
2h = 120 min
/130 outils (estimation basse)1
= une moyenne de 55 secondes par outil
C’est assez de temps pour trouver et aborder le problème, ouvrir le(s) fichier(s) de code source, et… zut le temps s’est écoulé ! Désolé, problème suivant !
Donc, au lieu de tous les traiter, je m’occupe de l’un d’entre eux. Jusqu’à ce que ce soit réglé ou que j’abandonne. L’un ou l’autre peut prendre des minutes, des heures, voire des jours. Et pendant ce temps, je ne me penche pas sur les centaines d’autres problèmes. Parce que je ne peux rien faire pour eux à ce moment-là.
Alors, comment puis-je choisir un problème sur lequel travailler ? C’est une heuristique complexe calculée à partir des facteurs suivants :
- Nombre d’utilisateurs concernés
- Gravité (« problème de sécurité » vs « faute d’orthographe »)
- Opportunité (ce qui signifie que je l’ai remarqué lorsqu’il a été déposé)
- Disponibilité (est-ce que je me concentre sur autre chose lorsque je remarque le problème ?)
- Plaisir possible et humeur du moment (eh oui, car je suis bénévole, ça vous dérange ?).
Aucun événement particulier n’a été à l’origine de la publication de ce billet. Je le garderai en référence pour en donner le lien, quand l’occasion se présentera.
