En tu equipo, ¿Cualquiera puede tocar el software o sólo aquel quien lo desarrolló? La Propiedad Colectiva del Código (Collective Code Ownership)

En tu organización, así, entre nosotros, sin que nadie se entere… ¿Es sólo aquel que hace un trabajo (véase, programa algo, diseña, escribe, etc.), el padre (o madre) de la criatura, el que tiene la capacidad, y potestad, para cambiarlo, mejorarlo, tocarlo… y hasta entenderlo? ¿Es cada uno el único dueño y señor de aquello que hace? ¿Existe la ley no escrita de que nadie puede tocar lo que otro ha hecho?
Bueno, no sé que me vas a contestar (pero me lo imagino), yo, que será que tengo muy mala suerte, es lo que siempre, día sí y día no, me encuentro (y siento esta vez no haber tenido tiempo para detallártelo un poco más con una nueva edición del informe después de pasar por 80 empresas)
Tres o cuatro personas que en un equipo de, por ejemplo, veinte personas son las únicas que se reparten las piezas clave de una aplicación software. Cada uno de ellos tiene su parcela, cuentan como mucho con un “ayudante”, y nadie más osa jamás, ni puede, tocar esos “dominios”.
Y si el propietario, por cualquier razón, no está y hay que tocar su parte… tiembla. Como comentamos en su día en ¿Te has parado a pensar cuánto te cuesta que la gente se vaya de tu empresa?

Propiedad colectiva del código: el código es del proyecto, no de las personas, y todo el mundo es responsable de la calidad de todo el código

Propiedad Colectiva del Código (Collective Code Ownership), una de esas prácticas tan antiguas como olvidadas o como poco aplicadas. Una práctica ágil, ya que fue el “framework” ágil Extreme Programming quien la lanzó al mundo (si bien años antes Coplien ya habló del «Code Ownership», pero en lo hizo en el sentido contrario, evitando compartir).
La Propiedad Colectiva del Código (Collective Code Ownership) considera que el código pertenece al proyecto, no a una persona solo, no sólo a aquel quien lo programó. Y cualquiera puede tocar y modificar cualquier parte.
Y no sólo cualquier persona puede realizar cambios necesarios en cualquier lugar. Además, todo el mundo es responsable de la calidad del software, tanto si es de buena calidad como de si es de mala calidad.
Si alguien encuentra algo que no está muy fino… tiene la potestad, y responsabilidad, de arreglarlo, haya sido escrito por él o no.

Evitar egos y dependencias

La propiedad colectiva del código implica dejar de lado los egos. No estás orgulloso de “tu” código… estás orgulloso del código de tu equipo. No estás avergonzado de lo que alguien programó… vas y lo arreglas, o eres igual de responsable que aquel quién lo programó.
Pero es, además, una manera más de evitar la dependencia de unas pocas personas (como ya comentamos por aquí, los héroes). Por ello, en ocasiones, la propiedad de código compartida suele acompañarse del pair programming, y de varias otras técnicas más, para que más de una persona sepa tocar el código.
Hay por ahí una antigua y popular métrica “negra” llamada el “Factor Autobús”, que viene de decir que te preguntes cuantos desarrolladores tendrían que desaparecer en tu organización (en un supuesto y no deseable percance con un autobús) para que tu organización quede totalmente inoperativa. Si te salen pocos, vete replanteando la manera de hacer las cosas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba