C’est peut être une variante de l’Erreur Fondamentale d’Attribution, qui consiste à juger comme incompétentes des personnes raisonnablement expérimentées et bien disposées mais qui se trouvent aux prises avec un système médiocre.

Moi même, je me dis souvent : Ces deux préhistos ont dû se donner un mal fou pour se fabriquer des roues carrées, les idiots.

Quand on est abonné à Linked In, on sait bien que

  • la plupart des développeurs ne savent pas écrire du code propre 🧐
  • les managers sont dépassés par l’évolution des technologies 🤓
  • le métier n’a pas la moindre idée de ce qu’il veut 😜

🙃

Commençons par enfoncer une porte d’ouverte : c’est très banal, mais si vous travaillez dans le logiciel, alors vous allez très probablement rencontrer des problèmes de retard et/ou de dépassement de budget, ainsi que des problèmes de qualité.

Cela n’a rien à voir avec vos compétences ou vos dispositions, mais vient plutôt de la façon dont l’activité est organisée, c’est à dire du système de développement dans lequel vous intervenez.

Avec un peu de recul, et en mettant de côté les considérations individuelles accidentelles (leadership, passion, courage, focus, bienveillance, assiduité, obstination, sacrifice etc.) on trouve 3 traits essentiels à ce système :

♻️ Turn-over : les entreprises s’adressent à un marché du travail et un marché du service régis par une révolution technologique permanente. Songez donc : InfoQ classe des techniques comme CQRS, Event Sourcing, ou Domain-Driven Design dans son segment “Late Majority” ! C’est à se demander s’il ne leur manque pas un segment “Decrepit Fossil” pour C++ et COBOL.

🤝 Mode de coopération : 3 acteurs aux objectifs distincts mais complémentaires (Métier, Technique, Management) cherchent à réussir ensemble un projet de développement. L’entreprise place entre eux des barrières de communication inextricables : silos, transferts implicites de responsabilités et de risques, drama.

📝 Mode d’apprentissage : on considère le développement de logiciel comme de la fabrication de produit. On cherche donc à optimiser la vitesse de production, en s’appuyant sur la stabilité factice offerte par les outils de CI/CD. Or réaliser du logiciel, c’est traduire des idées en provenance de systèmes vers d’autre systèmes, dont certains comprennent du code. Le code n’est pas le bout de la chaîne : c’est une traduction parmi d’autres.

Pour améliorer l’état de l’art dans une entreprise qui développe du logiciel, il faut apprendre ensemble. Pour apprendre ensemble, il faut pratiquer la double boucle d’apprentissage chère à Argyris :

  • boucle #1 : améliorer notre production en fonction de règles de décisions basées sur nos modèles mentaux
  • boucle #2 : améliorer la boucle #1 en examinant ses résultats et en changeant nos modèle mentaux

Une entreprise sujette aux modes technologiques, qui travaille en silos, et où 3 ans = long-terme ne peut pas apprendre efficacement.

Stay Tuned!

publié sur Linked In le 03/05/2023