Una verdad incómoda: la mayor parte de los bugs que arreglamos existen porque alguien escribió código que no necesitaba escribir.
No por negligencia, sino por inercia. Uno aprende a programar agregando — una función más, una abstracción más, un parámetro opcional por si acaso. Y esa inercia se queda: el código crece, los proyectos también, y un día el equipo pasa más tiempo peleándose con el andamio que construyendo.
La regla del “por si acaso” cuesta
Cada bandera opcional, cada capa de indirección, cada hook “por si luego lo necesitamos” es una apuesta. Si gana, te ahorra media hora en el futuro. Si pierde — que es lo normal — te cuesta cada lectura, cada refactor, cada persona nueva que entra al código.
Hacemos el cálculo al revés. Preguntamos:
- ¿Esto resuelve un problema que ya existe hoy?
- Si lo quito, ¿algo deja de funcionar?
- Si lo dejo, ¿qué costo acumulo por mes?
La mayor parte del tiempo la respuesta honesta es: no, no y sí.
Borrar es una habilidad
En el lab, borrar código es tan valorado como escribirlo. Tenemos una regla informal que funciona sorprendentemente bien: si en una revisión alguien identifica 30 líneas que podemos quitar sin perder comportamiento, esas 30 líneas se van antes de mergear.
No porque sean malas. Porque son deuda. Y la única deuda que no genera intereses es la que nunca existe.
Qué sí es pereza
Para que no se malinterprete: menos código no es menos trabajo. Es más pensamiento por línea.
Es más fácil escribir una abstracción genérica que entender tres casos reales y elegir el mínimo común. Es más fácil meter un try/catch grande que leer qué errores son posibles. Es más fácil aceptar un PR extenso que pedirlo partido en dos.
El código breve casi siempre viene de pensar más tiempo, no menos.
Una métrica que usamos
Cuando terminamos un proyecto, miramos cuántas líneas escribimos por semana. Si el número crece constantemente sin que el alcance haya crecido, algo está mal. El producto se vuelve más complejo por defecto, no por diseño.
Los mejores sprints son aquellos en los que las líneas netas son negativas: limpiamos más de lo que agregamos, y aún así entregamos valor.
No pasa siempre. Pero cuando pasa, se nota en cómo envejece el proyecto.
TL;DR — escribir menos código no es un lema estético. Es una herramienta de gestión de riesgo. El código que no existe no falla, no hay que mantenerlo, y no cuesta onboarding. Si puedes resolver un problema con la mitad de las líneas, probablemente ya resolviste también la mitad de los bugs del próximo trimestre.