“Là on va entrer dans une période de crunch. Plus question de binômes. Une personne par story.” (Delivery Manager)

“Le binômage, c’est lorsqu’une personne programme, et l’autre personne observe.” (Consultant Méthodo)

“S’il vous plaît, pas de refactoring durant ce sprint. Vous vous ferez plaisir après la MEP.” (Product Owner)

“Préparez-vous, les programmeurs seront remplacés par l’IA dans pas longtemps.”

(Influenceur Linked In)

Vous l’avez peut être reconnue, c’est la simplification numéro 1 :

Programmer, c’est écrire du code.

Il y a bien sûr une part de vérité dans ce cliché. Pas d’écriture de code → pas de programme créé ou mis à jour.

Mais dans un contexte professionnel, s’en tenir à une telle simplification tient de la cécité.

En observant l’activité de programmation, on peut comprendre d’où vient la réduction :

1) Le code est un matériau facile à identifier (“tu as installé la dernière version ?”) et à mesurer quantitativement (en Ko, Mo, Go…). Lorsque la complexité et l’ambiguïté inhérentes à tout projet de développement se traduisent en anxiété, et que la pression pour des résultats se fait sentir, la quantité de code permet de présenter une apparence de résultat.

2) Réaliser un petit projet implique peu de code à écrire, réaliser un gros projet, beaucoup. Ce constat mène naturellement à un modèle qui fait du temps de programmation un fongible : pour organiser un projet contenant 400 stories, prenez 5 développeurs, et donnez leur 80 stories à réaliser.

3) La programmation est un art qui exerce notre capacité à résoudre des problèmes conceptuels, à trouver des idées originales, à communiquer par l’écrit, à faire preuve d’élégance et d’intelligence. Le code cristallise ces compétences. Programmer c’est écrire du code, mais pas n’importe quel code.

Pour mettre fin à ce cliché, voici un modèle alternatif :

Programmer c’est traduire un système d’idées (une conception) en un autre système, lequel permet des interactions avec une machine.

Traduire, c’est bien plus qu’écrire. Aucun·e programmeur·se ne se contente d’écrire du code. Ce n’est même pas son activité principale.

Voici ce que j’attendrais d’une personne qui affirme savoir programmer :

  • comprend et choisit les besoins et contraintes que le programme pourra satisfaire
  • comprend et résout ou contourne les difficultés posées par ces besoins et contraintes
  • identifie, comprend et choisit des besoins complémentaires ou indirects
  • conçoit un système intermédiaire entre “l’idéal” et le programme executable à l’aide de représentations plus ou moins formelles
  • élabore et met en œuvre des stratégies de vérification du programme
  • élabore et met en œuvre des stratégies de recherche des problèmes dans ce programme
  • documente ce programme afin de faciliter sa future évolution

Pas vous ?

publié sur Linked In le 27/02/2024

#qualitymanagement