-2000 líneas de código (2007)

LOC como KPI y la ley de Goodhart

• Hay un amplio consenso en que usar líneas de código (LOC/KLoC) como métrica de rendimiento es perjudicial: premia la verbosidad, la duplicación y la complejidad.
• Esto se presenta como un caso de libro de la ley de Goodhart: en cuanto LOC se convierte en un objetivo, los desarrolladores optimizan para escribir más código, no mejor código.
• Varios señalan que LOC es engañoso incluso cuando no es un KPI formal; aun así moldea los incentivos si los gerentes valoran implícitamente “más código”.

Qué indica realmente LOC (si es que indica algo)

• Algunos sostienen que LOC y el volumen de commits pueden ser una señal débil entre muchas: commits extremadamente pequeños y triviales durante meses pueden indicar que alguien está atascado o tiene bajo rendimiento.
• Otros responden que todo caso significativo (un bug difícil, trabajo de arquitectura, mentoría, evitar funcionalidades innecesarias) rompe esa correlación, así que LOC no aporta valor único más allá de revisar directamente el trabajo y los resultados.
• Se sugiere ΔSLOC (añadido + eliminado) como un proxy algo mejor de “cambio”, pero sigue siendo pobre para “productividad”.

LOC negativo y el código como pasivo

• Muchos celebran borrar grandes cantidades de código o sustituir miles de líneas por funciones pequeñas y claras como trabajo de alto valor.
• El código se describe repetidamente como un coste o un pasivo; el activo es la funcionalidad. El mejor código suele ser el que no se escribe.
• Varias anécdotas: enormes bloques duplicados reducidos a pequeñas funciones reutilizables; pruebas snapshot grandes o boilerplate eliminados; errores de larga data corregidos con cambios mínimos.

Gestión, proceso y cultura

• Fuerte crítica a la gestión que se apoya en métricas fáciles y superficiales (LOC, “impact launches”) en lugar de entender el trabajo.
• La buena gestión se describe como: técnicamente competente, leer código, ayudar con bloqueos, proteger a los ingenieros y ver la productividad de forma multidimensional.
• Los daily standups se debaten: algunos los encuentran útiles para la coordinación; otros los ven como rituales de estatus de “cargo cult” que deberían reemplazarse por mejor colaboración y revisión de código.

Poder, sindicatos y software artesanal

• La historia destaca que solo las personas de alto estatus pueden ignorar abiertamente malas métricas; los demás corren el riesgo de sufrir represalias.
• Se proponen sindicatos como protección frente al uso retaliatorio de métricas de rendimiento, aunque también se reconocen sus desventajas y su política interna.
• Algunos lamentan que los grandes entornos corporativos hayan expulsado el oficio de software “artesanal”, mientras que otros señalan que sigue prosperando en el código abierto y en pequeñas startups.

IA y volumen de código

• Los participantes vinculan la discusión sobre LOC con la generación de código por IA: herramientas que producen barato enormes cantidades de código mediocre pueden empeorar la falacia de “más código = más valor” en lugar de լուծionarla.