it-swarm-es.com

¿Cómo afecta la burocracia de la oficina a la calidad del código?

Me interesan las historias en las que burocracia de la oficina ha tenido un efecto directo en el resultado final calidad del código.

Por ejemplo, un amigo me acaba de decir 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 fuentes) sin pedir permiso a los dioses VCS. El resultado fue que los programadores no estaban dispuestos a pasar por el paso burocrático adicional y, en lugar de componenteizar adecuadamente sus servicios, terminaron acumulando funcionalidades no relacionadas sobre los módulos existentes, incluso cuando la funcionalidad estaba relacionada de forma remota con la definición actual del módulo o el nombre del módulo. estaba en el pasado. (sin mencionar el cambio de nombre de un módulo ...)

Estoy interesado en historias similares de oficina, operativa o cualquier otra burocracia que eventualmente, quizás sin querer, afectaron la calidad del software.

22
Ran

Me interesan las historias en las que 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 de manera incorrecta (o se explota negativamente ... ver más abajo), tiene el potencial de negativamente afectar la capacidad de dar a luz o reaccionar a cambios repentinos. Sin embargo, una falta de proceso tendrá un cierto y un impacto 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 relacionados con la garantía de calidad en la burocracia que afectan la calidad del código cuando se explotan (ya sea de forma accidental o nefasta).

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 ante todo falta de ética profesional. Realmente no compro el argumento de que la gente escribe código incorrecto porque ellos no saben mejor o no ha sido debidamente capacitado . He visto gente sin títulos relacionados con la informática escribiendo código decente. Es un estado de ánimo 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 el no piensan, solo codifican el mantra (aunque hay ocasiones en las que debemos codificar, enviar y limpiar los cuerpos más tarde); desarrolladores que insisten en entregar lo que piensan es el código perfecto a pesar de que sacar algo de la puerta ahora es esencial ; revisores de código que son unos idiotas; guerras de cubículos y tal. Estas cosas exacerban la dinámica personal problemática. La combinación de ambos se filtra a través de cualquier grieta en el proceso (la burocracia) o la falta de ella, provocando una falla en la garantía de calidad del código.

El agujero en la burocracia podría resolverse si existe una cultura de revisiones post-morten y mejora continua. Sin embargo, las dinámicas personales negativas y las políticas destructivas de la oficina impiden que se produzcan 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 afectadas negativamente por la dinámica personal negativa y la política de la oficina.

6
luis.espinal

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

1
Geek

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 recién renombrada, conduce a los mismos resultados técnicos, pero sin problemas administrativos.

1
mouviciel