Quelque chose auquel je reviens constamment : chaque équipe d’ingénierie a un facteur bus, qu’elle l’admette ou non. Plus les connaissances critiques résident dans la tête d’un petit nombre de personnes plutôt que d’être écrites quelque part, plus l’ensemble devient fragile. Et ce ne sont jamais les grandes catastrophes qui le révèlent, mais les petites choses. Quelqu’un est en vacances, malade, ou simplement dans des réunions bout à bout, et soudain, une question de deux minutes devient un blocage de deux jours. Pourquoi ce service a-t-il été conçu ainsi ? Qu’est-ce qui dépend réellement de cette API avant de la modifier ? Ce problème exact a-t-il déjà été résolu il y a huit mois par quelqu’un qui a quitté l’équipe ? Aucune de ces réponses ne devrait nécessiter de retrouver « la seule personne qui le sait ». Mais sur la plupart des équipes, c’est exactement ainsi que ça fonctionne. C’est une des raisons pour lesquelles @CNPYNetwork et https://t.co/ZZmN9Y6mOV m’ont marqué. L’opportunité intéressante n’est pas seulement de construire un assistant de codage plus intelligent, mais de rendre ce type de connaissance institutionnelle disponible pour n’importe qui sur l’équipe, à la demande, au lieu de la laisser vivre et mourir dans la mémoire d’une seule personne. Les équipes les plus fortes ne sont pas celles qui ont la meilleure mémoire individuelle. Ce sont celles qui ont construit quelque chose qui se souvient à leur place.