Ma première rencontre avec la productivité a eu lieu en 1989 :

— Voilà, on a ce projet en dBase IV…
— Et dBase IV ne marche pas. (Facile, il suffisait de lire la presse spécialisée).

— Précisément. Vous connaissez dBase IV ?
— Je connais bien dBase III. Il y a un équivalent qui s’appelle Clipper.
— Et vous connaissez Clipper ?
— Pas très bien, mais si vous avez la documentation…
— Oui, mais nous si on vous prend, ce n’est pas pour lire de la doc !

🤝 J’ai été pris quand même. Ironiquement, ma première tâche a consisté à lire la spécification du projet (3 documents de 150 pages). 📚

L’idée de mesurer la productivité des développeurs en comptant les lignes de code produites a été remise en cause il y a déjà un certain temps. (par ex. dans Capers Jones — Software Assessments, Benchmarks and Best Practices — 2000).

Peu d’entreprises à vrai dire semblent faire attention au nombre de lignes de code des projets. En général, pour jauger la productivité des développeurs on s’appuie plutôt sur l’équation :

temps passé seul devant l’écran / temps passé à d’autres activités

équation basée sur l’idée que les développeurs ont pour mission de produire du code, et qu’il font mieux cela en restant concentrés devant leur écran plutôt qu’en faisant autre chose. 🖥

C’est cette idée qui rend suspectes des pratiques comme pair programming ou ensemble programming. 🧐

Bien sûr, rester seul devant l’écran ne garantit pas en soi la productivité. Mais en l’absence d’une meilleure heuristique, celle qui domine, c’est que dialoguer alors qu’on pourrait se concentrer seul devant l’écran, c’est perdre en productivité.

Mon idée à moi de la productivité est connotée à une métrique malheureusement impossible à mettre en œuvre : la VBD.

La Vitesse de prise des Bonnes Décisions 🤓

C’est une métrique d’équipe, évidemment. C’est même ce qui motive la création d’une équipe. (Au sens complet, i.e incluant Métier, Technique et Management. Sans cette inclusion, votre VBD en prend déjà un coup).

Je ne sais pas mesurer la VBD, mais je peux l’imaginer en train de baisser quand…

  • on n’arrive pas à déchiffrer la règle métier parce que le code est trop touffu, trop génial, trop tordu, pas assez clair 🤯
  • on ne recevra pas de retour des utilisateurs avant plusieurs semaines et on se contente de présupposer ou de projeter ce qui leur serait utile 🏝
  • on prend des décisions structurantes sur la base d’opinions ou de convictions sans mesurer quoi que ce soit de la situation en cours 🔮
  • on s’enferre dans les débats d’idées au lieu d’améliorer le code et le standard 🤺
  • on pose des verrues ça et là faute de tests pour refactorer le code et étendre la conception 🪣🪠
  • on travaille dans l’urgence et le fait accompli au lieu de se poser pour réfléchir 🚨
  • on essaie de faire tout seul au lieu de demander de l’aide 🕳
  • on bricole une solution faute d’ouvrir les bons livres 🕳📚
  • on se réadapte en permanence au lieu d’apprendre en continu 🥵

publié sur Linked In le 27/04/2023