Dans le sillage des récents licenciements de personnel chez Twitter, nous explorons pourquoi la simplicité du code est vitale pour la productivité de l’industrie technologique.
Avec toute l’agitation autour de la Twitter Les licenciements – y compris les rumeurs selon lesquelles le « Chief Twit » lui-même, Elon Musk, a licencié des technologues en se basant uniquement sur les lignes de code soumises (ce qui n’est certainement pas vrai à 100 %) – ont rouvert une vieille blessure. L’éternelle énigme « comment mesurer la productivité des développeurs ? » a refait surface.
Cependant, ne devrions-nous pas aller encore plus loin et poser des questions plus pertinentes telles que « devrions-nous » et « comment » mesurer la productivité des développeurs, et « qui » exactement devrait la mesurer ?
Quand les mesures cessent d’être bonnes
L’histoire a montré que les lignes de code, le nombre de bogues corrigés, etc. sont un exemple de la loi de Goodhart – « quand une mesure devient un objectif, elle cesse d’être une bonne mesure » – en action. Lorsque des entreprises ont emprunté cette voie dans le passé, cela a conduit à des comportements aberrants tels que la création de bogues dans le seul but de les corriger, ou l’alourdissement de la base de code.
À la base de toute cette controverse, il y a le fait que les dirigeants ne comprennent pas vraiment le génie logiciel et la valeur que les ingénieurs (surtout les plus expérimentés) apportent à la table. Il ne s’agit pas d’un travail à la pièce ; nous ne remplissons pas des enveloppes ou n’expédions pas des colis (même s’il n’y a rien de mal à faire ce genre de travail). Il s’agit d’un processus de création et de résolution de problèmes où moins peut parfois être beaucoup plus.
>Voir aussi : Combattre les idées fausses sur la carrière de développeur
Reste simple, idiot !
Souvent, lorsque je travaillais sur le code, je passais ma soirée à supprimer des lignes de code de la solution pour la rendre plus simple, plus facile à lire et à maintenir. Car la solution la plus simple, pour autant qu’elle réponde aux exigences fonctionnelles et non fonctionnelles, est souvent la meilleure.
Ajoutez à cela le fait que la technologie se développe si rapidement que de nombreux problèmes sont déjà résolus, et cela devient un cas de sélection de la bonne solution existante, plutôt que d’écrire réellement le code.
Retirez vos mains du clavier pendant un moment
Je dis souvent que je suis plus heureux d’embaucher des gens qui n’écrivent pas de code. Pourquoi ? Parce qu’il y a beaucoup de considérations importantes à faire avant de commencer à coder, et que vous risquez d’aggraver le problème.
Voici une liste de questions que je me pose avant de commencer à coder, et j’encourage les autres à faire de même :
- Comprenez-vous le problème que vous essayez de résoudre ?
- Ce problème a-t-il déjà été résolu ?
- Comprenez-vous les contraintes de la solution, de la conception et des modèles dans lesquels vous travaillez ?
- Comprenez-vous les implications de ce que vous êtes sur le point d’écrire dans le code-base ?
- Comprenez-vous les implications de votre changement en dehors de la base de code (tierces parties, etc.) ?
- Pouvez-vous écrire ceci sans élargir la base de code ?
- Pouvez-vous le garder aussi simple que possible (KISS) ?
- Devez-vous d’abord refactoriser quelque chose ?
- Pouvez-vous faire en sorte que cette pièce réponde à la définition de Done ?
- Êtes-vous mentalement prêt à résoudre le problème ?
- Avez-vous pensé aux tests, en espérant les écrire d’abord ?
- Faut-il les écrire maintenant ?
- Faut-il l’écrire tout court ?
Ce filtre, bien que verbeux, peut aider un ingénieur logiciel à faire le travail le plus simple et le moins lourd. Dans de nombreux cas, la solution existe déjà, et le choix d’une solution standard, SaaS ou open source est l’approche la plus raisonnable. Elles conduisent toutes à des améliorations dans des domaines tels que la qualité plutôt que la quantité, et c’est sur ce point que nous devrions, selon moi, nous concentrer : sur la qualité de la solution.
Il y a aussi le « travail non planifié » (ou la dette technique, qui est un terme très malmené, et le remaniement nécessaire). Souvent, en ingénierie, nous devons passer du temps à nettoyer le terrain de camping afin de rendre durables les changements ou améliorations futurs. Pour reprendre les mots immortels de Kent Beck : « Pour chaque changement souhaité, rendez le changement facile (attention : cela peut être difficile), puis faites le changement facile ».
>Voir aussi : Comment la troisième génération de code faible peut combler le déficit de livraison de l’informatique.
Moins, c’est souvent plus
La correction d’une base de code peut ne pas ajouter de fonctionnalités, et peut même la réduire. Vous pouvez vous retrouver avec quelque chose qui, à première vue, ne ressemble pas à grand-chose. Cependant, c’est la chose éthique et durable à faire dans de nombreux cas.
Par exemple, si vous regardez certaines des activités les plus critiques que nous faisons en tant qu’ingénieurs, beaucoup d’entre elles n’impliquent pas d’écrire beaucoup de code, comme la sécurité, l’évolutivité, la performance et la fiabilité. Si vous découragez ces activités et que vous alimentez entre-temps une culture dans laquelle l’écriture de code est synonyme de valeur/productivité, vous vous retrouverez rapidement dans le pétrin.
Le vieil argument est que « tout le monde n’a pas besoin d’une solution Rolls Royce », ce qui est vrai quand on parle de laisser de côté les tapis en peluche et le tableau de bord en noyer. Mais j’espère que nous sommes d’accord sur le fait que nous ne voulons pas, et ne devrions pas pouvoir, omettre les ceintures de sécurité de nos voitures. C’est là qu’en tant qu’ingénieurs, nous devons être féroces et courageux, en protégeant la qualité de ce que nous produisons, car cela a presque toujours pour effet de protéger également la productivité.
Comment nous devrions utiliser les métriques
Les mesures de la productivité des développeurs devraient être destinées à l’équipe de développement dans son ensemble (pour comprendre la dynamique de l’équipe), et à l’individu, afin qu’il puisse travailler sur sa propre productivité, en suivant la collaboration, le temps passé en ligne, la vélocité personnelle, le temps passé à attendre des évaluations, etc. Il ne s’agit pas d’un bâton pour battre les gens, mais d’un moyen d’utiliser les données pour alimenter l’amélioration continue, tant au niveau personnel qu’au sein des équipes. Il ne s’agit pas d’un bâton pour battre les gens, mais d’un moyen d’utiliser les données pour alimenter l’amélioration continue, tant sur le plan personnel que sur celui des équipes.
Mais il y a d’autres choses que nous devrions prendre en compte lorsqu’il s’agit de la « productivité » des développeurs, comme le temps passé à encadrer et à conseiller, à jumeler, à réviser, à contribuer à des projets internes ou open source. En tant qu’individu, nous ne sommes qu’un seul fil ; même un développeur 10x ne peut pas faire grand-chose en une journée, mais en faisant grandir les autres, nous pouvons multiplier notre capacité à fournir des produits de qualité à un rythme soutenu.
Twitter pourrait perdre ses meilleurs talents à cause de cette situation, et en tant qu’industrie, nous devrions tirer des leçons de cette débâcle. La leçon la plus importante que nous pouvons tirer est la suivante : il faut s’efforcer de mesurer les bons types de choses, pour les bons types d’objectifs.
Et enfin, pas d’impression s’il vous plaît, nous ne facturons pas au kilo ici.
Jeff Watkins est directeur des produits et de la technologie chez xDesign.
Voir aussi :
Quatre façons de développer les talents techniques – Face à l’incertitude économique et à la pénurie constante de compétences qui affectent les entreprises, voici quatre façons dont les organisations peuvent développer les talents techniques.
5 entreprises tech for good qui embauchent en ce moment – Les entreprises tech for good s’attaquent aux plus grands problèmes de la planète, notamment le changement climatique, l’inégalité alimentaire et l’injustice sociale. Voici 5 entreprises qui embauchent en ce moment.