La ilusión de la productividad: Por qué más líneas de código significan, casi siempre, peor software.

“Si hubiera tenido más tiempo, te habría escrito una carta más corta”

Esta frase (atribuida a Pascal) resume perfectamente el desafío de la ingeniería de software moderna.

Escribir mucho código es fácil. Copiar, pegar, crear funciones gigantes y commits de 3.000 líneas es rápido. Pero escribir código conciso, limpio y mantenible es difícil. Requiere tiempo, pensamiento abstracto y refactorización.

En la industria, todavía existe el mito de que un desarrollador que entrega 1.000 líneas de código al día es “más productivo” que uno que entrega 100. O peor, uno que entrega -500 (borrando código inútil).

En Atelier Busco, tenemos una métrica diferente: El mejor código es el que no se escribe.

Por qué las Líneas de Código (LOC) son una métrica de vanidad

El código tiene un costo de mantenimiento perpetuo. Cada línea que agregas es una línea que:

1. Puede tener bugs.
2. Debe ser leída y entendida por otro humano.
3. Debe ser testeada.
4. Debe ser actualizada cuando cambie la tecnología.

Si tu equipo está optimizando para “cantidad”, están construyendo un monstruo de deuda técnica. Un sistema con 50.000 líneas que hace lo mismo que uno bien arquitecturado de 10.000 líneas, no es 5 veces mejor. Es 5 veces más caro de mantener.

El peligro de los “Mega-Commits”

Otro síntoma de baja calidad son los commits gigantes.

Un desarrollador trabaja en silencio durante dos semanas y sube un cambio de 45 archivos y 2.500 líneas. Lo llama “Feature X terminada”. Esto es una pesadilla para la calidad por tres razones:

1. Imposible de Revisar: Nadie puede revisar 2.500 líneas con atención. El revisor se cansa, hace scroll y aprueba sin mirar. Los bugs entran por la puerta grande.
2. Riesgo de Regresión: Si algo falla, ¿dónde está el error? Buscar una aguja en un pajar de 2.500 líneas es costoso.
3. Bloqueo de Equipo: Mientras ese código no se integre, el resto del equipo está trabajando sobre una versión obsoleta, garantizando conflictos de fusión (merge conflicts).

Nuestra Obsesión: Atomicidad y Claridad

En nuestro estudio, preferimos 10 commits pequeños y aburridos antes que un commit “heroico”.

• Atomicidad: Cada cambio debe hacer una sola cosa. Si arreglas un bug y añades una feature, son dos commits.
• Complejidad Ciclomática Baja: Medimos qué tan “enredada” es la lógica. Si una función tiene demasiados if/else anidados, se refactoriza o se rechaza. No importa que “funcione”. Si es difícil de leer, es mala calidad.

Paga por Cerebro, no por Teclado

Cuando contratas a un socio técnico, no estás pagando por mecanografía. Estás pagando por criterio.

A veces, la mejor semana de un Arquitecto de Software es aquella donde logró eliminar un módulo entero y simplificar la operación, reduciendo el código total del proyecto.

La calidad sobre la cantidad no es un eslogan estético. Es la única estrategia financiera sostenible para un producto de software a largo plazo.