Dès que vous commencez à avoir peur de votre technologie, de nouvelles raisons de craindre apparaîtront bientôt.

La boucle de peur se resserre comme ceci:

1. Des modifications mineures entraînent des conséquences imprévisibles, effrayantes ou coûteuses.
2. Nous commençons à craindre le changement.
3. Nous essayons de rendre toutes les modifications aussi petites et locales que possible.
4. La base de code est remplie de correctifs, d'exceptions et de cas spéciaux.
5. La peur s'intensifie.

La peur commence lorsqu'une modification inoffensive cause un problème de manière inattendue. Temps d'arrêt en production ou simplement un bug ennuyeux. Une erreur peut attirer l'attention de la direction. Rien n'inspire la peur comme une réunion des administrateurs à propos de votre défaut dans le code!

Il y avait un tel problème, car le développeur ne pouvait pas prévoir toutes les conséquences du changement. Peut-être que la suite de tests était insuffisante. Ou un cas spécial est apparu qui n'est observé qu'en production. (Par exemple, un seul client dont les paramètres de données sont différents de tous les autres). Quelle que soit la raison spécifique, le résultat est: "Je ne savais pas que cela arriverait."

Plusieurs événements similaires - et maintenant les développeurs et les chefs de projet ne veulent rien toucher en dehors de leur sphère étroite. Ils cachent leur tête dans le sable comme des autruches.

Le problème est que ce comportement aura des conséquences. Inévitablement, la base de code commencera à se détériorer, le besoin de changements majeurs augmentera et le volume de refactoring dans les builds sans publication augmentera.

Le cercle vicieux se ferme lorsque l'une de ces autruches devient le coupable du bug de quelqu'un d'autre. À partir de ce moment, le cycle de la peur devient auto-entretenu. Le prix de changements, même minimes, continue de croître sans cesse. Le temps nécessaire pour publier les modifications augmente également.

Point de basculement

Cela peut se terminer de trois manières:

1. Refonte du code cardinal (généralement avec une équipe différente) sous la devise «maintenant, nous allons le faire correctement !» Voir aussi: Syndrome du deuxième système et «Ce qui ne peut jamais être fait, partie I» .
2. Externalisation à grande échelle.
3. Vendre les actifs affectés à une autre société.

Comment éviter la boucle

Le cycle de la peur commence lorsque les gens perçoivent un problème technique comme un problème personnel. Pour la première fois, lorsqu'un simple changement de code a entraîné des conséquences importantes et imprévisibles, vous devez appeler les "forces spéciales techniques" - une équipe de spécialistes. Ils détermineront pourquoi le système a permis cela et quels changements techniques permettront d'éviter cela à l'avenir.

Le tribunal est la pire réponse à l'échec.

La différence entre les «forces spéciales techniques» et le tribunal réside dans la façon dont certaines personnes abordent ce problème. Pour éviter la boucle de la peur, des conseils avisés sont nécessaires. Recherchez des personnes ayant de l'expérience en DevOps et en gestion de projets techniques.

Comment rompre une boucle

Comme de nombreuses boucles renforcées, le cycle de la peur est incroyablement difficile à briser. Jusqu'à présent, je n'ai observé aucun cas de sortie réussie. Si cela a commencé dans votre entreprise, j'aimerais connaître votre expérience!