¿Cómo afecta la burocracia de oficina la calidad del código [cerrado]

Estoy interesado en historias donde la burocracia de la oficina ha tenido un efecto directo en el resultado final de la calidad del código .

Por ejemplo, un amigo acaba de decirme que en su lugar de trabajo anterior el sistema de control de versiones era tan voluminoso que a los programadores no se les permitía crear nuevos "módulos" (directorios raíz en el árbol de origen) sin pedir permisos a los dioses de VCS. El resultado fue que los programadores no estaban dispuestos a pasar por el paso burocrático adicional y, en lugar de componentes de sus servicios, terminaron acumulando funcionalidades no relacionadas en la parte superior de los módulos existentes, incluso cuando la funcionalidad estaba remotamente relacionada con la definición actual del módulo o el nombre del módulo. fue en el pasado. (sin mencionar cambiar el nombre de un módulo ...)

Estoy interesado en historias similares de burocracia de oficina, operativa o de cualquier otro tipo que eventualmente afecten involuntariamente la calidad del software.

Estoy interesado en historias donde la burocracia de la oficina ha tenido un efecto directo en el resultado final de la calidad del código.

No creo que la burocracia tenga tanto efecto en la calidad del código como la dinámica personal y la política de la oficina. La burocracia tiene que ver con el proceso. Cuando un proceso existente se realiza incorrectamente (o se explota negativamente ... ver más abajo), tiene el potencial de afectar negativamente la capacidad de entrega o reaccionar ante cambios repentinos. Sin embargo, la falta de proceso tendrá un impacto cierto y significativo en la calidad del código. O para ser más precisos, un proceso que no gobierna la calidad del código (también interpretado como una falta de proceso de calidad del código) afecta la calidad del código.

Es decir, no es la burocracia en sí misma, sino agujeros específicos en la burocracia relacionados con el control de calidad que afectan la calidad del código cuando se explotan (ya sea accidental o nefastamente).

Sin embargo, la dinámica personal y la política de la oficina son mucho más culpables del mal código. La dinámica personal implica la falta de ética profesional en primer lugar. Realmente no comprendo el argumento de que las personas escriben códigos incorrectos porque no saben mejor o no han recibido la capacitación adecuada . He visto personas sin títulos relacionados con CS que escriben código decente. Es un estado mental y una cuestión personal de ser organizado y meticuloso.

La política de la oficina juega un papel aún más terrible. Los jefes que empujan a los que no piensan, solo codifican el mantra (aunque a veces debemos codificar, enviar y limpiar los cuerpos más tarde); desarrolladores que insisten en entregar lo que creen que es el código perfecto, aunque sacar algo de la puerta ahora es esencial; revisores de código que son ** agujeros; guerras de cubículos y tal. Estas cosas exacerban las dinámicas personales problemáticas. La combinación de ambos se filtra a través de cualquier grieta en el proceso (la burocracia) o la falta de ella, lo que provoca un colapso en el aseguramiento de la calidad del código.

El agujero en la burocracia podría resolverse si existe una cultura de revisiones post-mortales y una mejora continua. Sin embargo, la dinámica personal negativa y la política destructiva de la oficina impiden que se realicen tales correcciones en el proceso, perpetuando así los problemas existentes (incluidos los relacionados con la calidad del código).

La burocracia por sí sola rara vez es la culpable de la mala calidad del código. De hecho, diría que la calidad del código y la burocracia se ven negativamente afectadas por la dinámica personal negativa y la política de la oficina.

Dejé de trabajar en algunos módulos particulares en el Proyecto porque el revisor del código era un Smart A $$

En un proyecto reciente, las personas de calidad tenían muchos requisitos con respecto a las pruebas unitarias formales (trazabilidad, reglas de codificación, revisiones formales, ...). Los codificadores ya no escriben pruebas unitarias, solo depuran su código. Esta es la misma tarea que acaba de cambiar de nombre, conduce a los mismos resultados técnicos, pero sin la molestia administrativa.