Comment la bureaucratie de bureau affecte la qualité du code [fermé]

Je m'intéresse aux histoires où la bureaucratie de bureau a eu un effet direct sur le résultat final de la qualité du code .

Par exemple, un ami vient de me dire que sur son lieu de travail précédent, le système de contrôle de version était si encombrant que les programmeurs n'étaient pas autorisés à créer de nouveaux "modules" (répertoires racine dans l'arborescence source) sans demander les autorisations aux dieux VCS. Le résultat a été que les programmeurs n'étaient pas disposés à passer par l'étape supplémentaire bureaucratique et au lieu de correctement composant leurs services, ils ont fini par empiler des fonctionnalités non liées au-dessus des modules existants même lorsque la fonctionnalité était simplement liée à distance à la définition actuelle du module ou au nom du module. était bien dans le passé. (sans oublier de renommer un module ...)

Je suis intéressé par des histoires similaires de bureau, d'exploitation ou de toute autre bureaucratie qui, éventuellement, ont peut-être involontairement affecté la qualité des logiciels

Je m'intéresse aux histoires où la bureaucratie de bureau a eu un effet direct sur le résultat final de la qualité du code.

Je ne pense pas que la bureaucratie ait autant d'effet sur la qualité du code que la dynamique personnelle et la politique de bureau. La bureaucratie a à voir avec le processus. Lorsqu'un processus existant est mal effectué (ou exploité négativement ... voir plus loin), il a le potentiel d'affecter négativement la capacité de livraison ou de réagir à des changements soudains. Cependant, un manque de processus aura un impact certain et significatif sur la qualité du code. Ou pour être plus précis, un processus qui ne régit pas la qualité du code (également interprété comme un manque de processus de qualité du code) affecte la qualité du code.

C'est-à-dire que ce n'est pas la bureaucratie elle-même, mais les trous spécifiques de la bureaucratie liés à l'assurance qualité qui affectent la qualité du code lorsqu'elle est exploitée (accidentellement ou de manière néfaste).

Cependant, la dynamique personnelle et la politique de bureau sont beaucoup plus responsables d'un mauvais code. La dynamique personnelle implique avant tout un manque d'éthique professionnelle. Je n'accepte pas vraiment l'argument selon lequel les gens écrivent du mauvais code parce qu'ils ne savent pas mieux ou n'ont pas été correctement formés . J'ai vu des gens sans degrés liés à CS écrire du code décent. C'est un état d'esprit et une affaire personnelle d'organisation et de minutie.

La politique de bureau joue un rôle encore plus terrible. Les patrons qui poussent ne pensent pas, codent simplement le mantra (bien qu'il y ait des moments où nous devons simplement coder, expédier et nettoyer les corps plus tard); les développeurs qui insistent pour livrer ce qu'ils pensent être le code parfait même si sortir quelque chose de la porte est maintenant essentiel; réviseurs de code qui sont un ** trous; guerres de cabines et autres. Ces choses exacerbent les dynamiques personnelles problématiques. La combinaison des deux s'infiltre dans toute fissure du processus (la bureaucratie) ou son absence, provoquant une rupture de l'assurance qualité du code.

Le trou dans la bureaucratie pourrait être résolu s'il existe une culture des examens post morten et de l'amélioration continue. Cependant, une dynamique personnelle négative et une politique de bureau destructrice empêchent de telles corrections sur le processus, perpétuant ainsi les problèmes existants (y compris ceux liés à la qualité du code).

La bureaucratie en elle-même n'est que rarement le coupable d'une mauvaise qualité de code. Je dirais en fait que la qualité du code et la bureaucratie sont toutes deux négativement affectées par la dynamique personnelle négative et la politique de bureau.

J'ai arrêté de travailler sur certains modules particuliers du projet parce que le réviseur de code était un Smart A $$

Sur un projet récent, les personnes de qualité avaient de nombreuses exigences concernant les tests unitaires formels (traçabilité, règles de codage, revues formelles, ...). Les codeurs n'écrivent plus de tests unitaires, ils ne font que déboguer leur code. C'est la même tâche qui vient d'être renommée, conduit aux mêmes résultats techniques, mais sans les tracas administratifs.