Un estudio en Google vincula la calidad del código con la productividad
El trabajo analiza 39 factores en desarrolladores de la compañía y sostiene que la calidad percibida del código antecede a la productividad, y no al contrario.
Código de calidad, menos deuda técnica, mejores herramientas internas y una comunicación de equipo que funcione. Un artículo académico firmado por investigadores de Google sostiene que esos factores no solo acompañan a la productividad de un desarrollador: la empujan. El trabajo, que analiza 39 factores distintos, señala la calidad del código como el más determinante de todos.
El estudio va en dos partes. En la primera, los autores usan datos de panel —las mismas personas medidas en varios momentos— para ver qué se mueve junto con la productividad autodeclarada. Aparecen seis bloques: calidad del código, deuda técnica, herramientas y soporte de infraestructura, comunicación del equipo, objetivos y prioridades, y cambios organizativos o de proceso. Todos ellos, según los autores, vinculados causalmente con la productividad que los propios desarrolladores dicen tener.
La segunda parte es la interesante. Ahí aplican un análisis de panel con retardo, que mira qué ocurre antes y qué ocurre después. El resultado: cuando sube la calidad del código, después suele subir la productividad. Al revés no pasa. Eso es lo que les permite afirmar que la dirección de la flecha va de la calidad al rendimiento individual, y presentarlo como la evidencia más fuerte hasta ahora de esa relación.
El matiz está en los adjetivos
Conviene fijarse en los dos términos que se repiten en el resumen: calidad percibida y productividad autodeclarada. Lo que se mide no es un commit por hora ni un tiempo de ciclo sacado del sistema de integración continua, sino lo que el desarrollador opina sobre la base de código y sobre su propio rendimiento. Los autores lo dejan claro en el texto, pero el titular que se queda el lector es el de la causalidad, y esa causalidad se apoya en percepciones declaradas.
También llama la atención lo que entra en el mismo saco: herramientas de infraestructura y soporte, comunicación del equipo, cambios de organización y de proceso. Es decir, la productividad individual no sale solo de escribir mejor código; sale también de que la plataforma no estorbe y de que la organización no esté reordenándose cada trimestre.
La metodología tiene su mérito y los propios autores la sitúan. La literatura previa o bien buscaba correlaciones en entornos reales, o bien aislaba causas en laboratorio con condiciones muy controladas. Este trabajo intenta cubrir el hueco con datos internos de una empresa grande y con un diseño que ordena temporalmente las variables.
Para quien gestiona equipos de ingeniería, la consecuencia práctica es incómoda: invertir en calidad de código puede tener retorno en productividad, pero no hay una métrica barata que lo demuestre, porque la medición se queda en la encuesta. Para quien solo escribe código, la lectura es más sencilla: si el entorno es un desastre, ninguna herramienta de moda lo arregla.
