Ces petites phrases de l'IT qui m'agacent
Dernièrement, j’ai publié sur Twitter un petit message d’humeur et j’ai été très surpris de l’écho que ce dernier a eu.
Visiblement, je ne suis pas le seul à en avoir assez d’entre cette phrase très (trop) souvent.
Du coup, je me suis dit que j’allais vous compiler quelques-unes de ces fameuses phrases qui m’agacent, en développant un peu sur le pourquoi.
On a toujours fait comme ça
Phrase par excellence que nous avons tous déjà entendu, et visiblement d’après les réactions sur mon Tweet, cela va bien au-delà de l’IT.
Faire quelque chose parce que c'est le standard de l’entreprise est normal, toutefois, je considère qu’il est sain de questionner les process et la raison de leur mise en place.
Faire quelque chose parce qu’on a toujours fait ainsi, mais que ça n’a pas ou plus de sens soit juste stupide. Il est important de remettre en cause les choses régulièrement. Une solution pouvait être adaptée à sa mise en place, mais ne plus l’être aujourd’hui.
Cela ne signifie pas que cette solution est ou a été mauvaise (en tout cas pas forcément), mais plutôt qu’elle doit évoluer pour s’adapter au fonctionnement actuel de la structure dans laquelle on est.
Tu veux des infos sur [application], vas voir [untel] !
Je suis le premier à dire que l’aspect humain de nos métiers est souvent oublié, toutefois très souvent cette phrase indique un énorme point : le manque de documentation.
J’ai travaillé dans nombre d’entreprises qui avaient ce souci : la tradition de la transmission de la connaissance à l’oral…
La documentation est très souvent le parent pauvre des applications, alors que celle-ci est primordiale, il est indispensable d’avoir une documentation à jour en permanence.
Dans le cas de l’architecture, il est même important que cette documentation soit terminée avant la moindre ligne de code (applicatif ou infra as code).
Pour en savoir plus sur la documentation, je vous invite à lire l’excellent billet de Damy.R à ce sujet :
On fera ça après/C’est temporaire
On sait tous comment se terminent ces deux phrases :
- Rien ne bougera par la suite
Le fix temporaire qui reste des années est un classique, le "on va en prod, on documentera après" se finit souvent sans documentation.
Pourquoi ?
C’est assez logique en fait : une fois en production, on considère souvent qu’un sujet est clos et qu’il ne reste que le MCO (Maintien en Condition Opérationnelle). D’ailleurs, on passe souvent sur un autre sujet ensuite. C’est pourquoi il est important d’avoir une checklist complète de mise en production et de ne jamais mettre un point primordial de côté.
Chez moi ça marche
Même si l’ère des conteneurs et du cloud computing a pas mal changé les choses sur cet aspect, voici l’une des phrases qui avait le plus de capacité à m’agacer lorsque j’étais Ops.
Le principe est simple, j’ai testé sur mon poste donc ça marche. On oublie souvent :
- Les contextes applicatifs qui ne sont pas les mêmes
- Les droits système
- Les overlays réseau
- Les ressources
Et j’en passe…
C’est pourquoi il faut toujours tester en s’approchant le plus possible des cibles finales, c’est d’ailleurs l’un des intérêts du DevOps, pouvoir travailler tout du long avec les outils les plus cohérents possibles !
C’est une erreur normale
Ah l’erreur normale, un classique…
Je ne compte plus le nombre de fois où je voyais des erreurs dans des logs, mais "c’est normal". NON un niveau de log ERROR est fait pour indiquer des… erreurs ! Si on veut renvoyer des "erreurs normales" (ou non bloquantes), on renvoie un WARN, c’est fait pour.
On notera aussi le corolaire du bug normal, j’ai connu des entreprises dont les batches plantaient quotidiennement, mais ce n’était pas gênant, en les reprenant (à la main bien sûr) ça fonctionnait…
Dans les deux cas, cela veut dire la même chose : un bruit, un parasite. Résultat, si un vrai problème survient, on ne le verra pas et la réaction sera bien plus lente.
Tu peux m’aider ? Il y en a pour deux minutes !
L’art de déranger deux minutes qui en fait dérange bien plus.
Aujourd’hui, nous avons l’outillage nécessaire pour travailler efficacement en mode asynchrone. Cela signifie que des outils comme Slack par exemple ne sont pas faits pour échanger en temps réel, mais plutôt pour échanger de manière désynchronisée, sans immédiateté.
Déranger quelqu’un, cela signifie :
- Interrompre ce qu’il fait
- Obliger à revenir ensuite sur le sujet d’origine
- Perte de concentration
- Efficacité moindre
C’est pourquoi il est important d’utiliser les canaux asynchrones qui permettent de fait d’augmenter la productivité des équipes.
CommitStrip avait d’ailleurs bien résumé la situation :
Tout le monde fait ça
L’argument d’autorité, on fait quelque chose parce que tous les autres le font, mais on ne sait pas pourquoi.
L’exemple que j’ai directement en tête est la mode du Kubernetes partout et surtout quand il ne sert à rien.
On veut du Kube parce que c’est à la mode, mais pas parce qu’on en a besoin. Il est important de chercher pourquoi les entreprises vont vers certaines technologies/méthodes/solutions, etc.
Une solution adaptée à une structure comme Netflix ne l’est pas forcément pour Waze (par exemple).
Comme d’habitude, le but est de comprendre, non pas de suivre bêtement les "modes" de l’IT, poussées par des structures qui ont tout à gagner à faire du vendor locking.
En conclusion
Je me suis un peu lâché aujourd’hui par rapport à mes billets habituels, mais je pense que ça peut être sain d’échanger sur ces aspects et de comprendre pourquoi cela crée parfois des frustrations.
Et vous, quelles sont les phrases que vous avez trop entendues ?
Comments ()