Notre capacité à documenter, améliorer, transmettre, en un mot faire vivre un état de l’art quel qu’il soit n’a jamais été aussi grande.

Elle ne semble dépassée que par notre motivation à remplacer ce que nous construisons le plus rapidement possible.

🏁 🏎 🔥 🚒

10/04/23, 15h40 : Je cherche un exemple qui illustrerait mon assertion nº1. L’exemple qui me vient en tête : les tables de hachage.

10/04/23, 15h42 : J’ai sous les yeux la section References de la page wikipedia “Hash Table”. Elle contient 54 liens. 📚🔑💡

Si je choisis mes sources avec discernement, que j’éloigne les distractions, et que je me définis une feuille de route même sommaire…

  • en 3 heures je peux savoir de quoi il en retourne
  • en 3 jours, je peux savoir d’expérience comment ça fonctionne
  • en 3 mois, je peux écrire ma propre librairie
  • en 3 ans, je peux développer une expertise exceptionnelle sur le sujet

⌚️ 🕰 🗓

Lors d’une récente présentation à la fin de laquelle je recommandais de lire ces livres :

  • Pragmatic Programmers – D. Thomas et A. Hunt
  • Becoming a Technical Leader – G. Weinberg
  • Legacy Code: First Aid Kit – Nicolas Carlo

un des partipants a lancé :

— excuse moi, mais est-ce qu’il y a encore des gens qui lisent des livres ?

Sur le moment j’ai bafouillé une blague. Mais maintenant que j’y réfléchis : le monde dans lequel nous vivons est basé sur l’écrit comme tu n’as pas idée.

📚📖📓

Mais lire ou écrire des livres : le logiciel en entreprise n’en demande pas tant. Simplement, documenter, améliorer et transmettre un état de l’art serait déjà très bien.

🗺🪜🧯

Toi qui a disons 5 ans d’expérience : combien de temps as-tu passé dans un projet où les pratiques suivantes avaient cours :

  • CR des décisions de Cadrage de Projet
  • Architecture Decision Record (à jour)
  • Document Général d’Architecture (à jour)
  • Diagrammes de données, de conception (à jour)
  • Documentation d’Exploitation (à jour)
  • Tests Fonctionnels autovérifiants (lisibles, à jour)
  • Tests autovérifiants (à jour)
  • Rapports de Tests exploratoires
  • Rapports de Rétro-analyse des incidents

Avant de rejoindre le chœur des récriminations sur l’air de “Ah là là ces développeurs”, j’aimerais poser 4 autres questions à propos de ces projets :

  • Qui en a construit l’argumentaire technologique ?
  • Qui en a défini le calendrier et le budget ?
  • Qui s’est assuré que l’état de l’art survivrait après la 1ère livraison ?
  • Est-ce que ces 3 acteurs formaient d’après toi une équipe ?

Pour résoudre les problèmes que posent le développement de logiciel en entreprise, il faut des équipes compétentes et résilientes, capables de réparer une conception et de la faire vivre.

Ce que propose avant tout notre industrie c’est de la nouveauté technologique.

“Nouveau ! Dans un monde où la seule constante est le changement… bla, bla, bla…”

🎇🎢🎪

Pas complètement en dehors de la plaque, mais pas loin.🤸🕳

publié sur Linked In le 11/04/2023