Borra más de lo que añades
Quitar es un acto de oficio de primer orden, no una limpieza. La complejidad es el enemigo y la simplicidad es algo hacia lo que cortas, así que el mejor cambio que puedes hacer es a menudo una eliminación.
Qué cambió›
- Capítulo nuevo — añadido en la reestructuración de junio de 2026.
Principio Nº Dos
La sustracción es diseño. El mejor cambio es a menudo una eliminación.
Nos entrenan para construir añadiendo. Más funciones, más opciones, más código — el progreso es algo que puedes ver amontonarse. Así que el movimiento que tuve que aprender a propósito, el que casi nunca sale de forma natural, es el opuesto: quitar. No como limpieza después del trabajo real, sino como el trabajo. La sustracción es un acto de diseño de primer orden, y un cambio netamente negativo — menos líneas, menos opciones, menos partes móviles, el mismo resultado — es una de las cosas más valiosas que puedes publicar.
La razón por la que importa tanto es que la complejidad es lo que de verdad mata el trabajo con el tiempo. Una definición útil: la complejidad es cualquier cosa que hace que un sistema sea difícil de entender y de cambiar. Se manifiesta como amplificación del cambio — una pequeña intención que obliga a editar en cinco lugares — y como carga cognitiva, la cantidad que debes mantener en la cabeza para tocar cualquier cosa con seguridad. Ambas se acumulan en silencio, y a ambas se las ataca más directamente no añadiendo ingenio sino quitando cosas.
Simple no es lo mismo que fácil
La trampa es que recurrimos a lo fácil — lo familiar, lo que está a mano, eso que ya sabemos cómo acoplar — y lo confundimos con lo simple. Son distintos. Simple significa des-trenzado: una sola preocupación, no enredada con otras tres. Fácil solo significa cercano a donde ya estás. Añadir la opción familiar se siente fácil, y trenza en silencio un hilo más en el nudo; el movimiento simple — separar los hilos, borrar el que no necesitaba estar ahí — es más difícil en el momento y mucho más barato para siempre después. Hay incluso un sesgo humano medido aquí: ante un problema, la gente recurre abrumadoramente a añadir y pasa por alto la solución que quita. El estándar que vale la pena conservar es el viejo: una cosa está terminada no cuando no queda nada que añadir, sino cuando no queda nada que quitar.
Evita
Añadir una bandera para preservar el camino muerto “por si acaso,” manteniendo ambas ramas vivas para siempre. La opcionalidad que no usas es pura carga cognitiva.
Haz
Borra el camino muerto. Si de verdad lo necesitas de nuevo, está en el historial — y lo volverás a añadir sabiendo que lo necesitas.
Dónde se tuerce
La sustracción es quirúrgica, no temeraria — el fallo de un lado es arrasarlo todo, arrancando cosas que en silencio sostenían el peso porque quitar se sentía virtuoso. Quitar bien significa saber qué estaba sosteniendo una parte antes de cortarla. El fallo del otro lado, mucho más común, es el acaparamiento: no borrar nunca nada, conservar cada opción y rama muerta “por si acaso,” hasta que el sistema es sobre todo andamiaje alrededor de un pequeño núcleo vivo. La disciplina es tratar la eliminación como un movimiento normal y frecuente — no una purga anual, sino algo que haces cada vez que notas algo que el trabajo ya no necesita.
Ponlo en práctica
Esta semana, encuentra una cosa que puedas quitar — una función que nadie usa, una opción que solo toma su valor por defecto, una dependencia traída por una sola función, un archivo que no hace nada — y quítala. Quédate con el resultado. Casi siempre el sistema se vuelve más claro, no más pobre, y habrás sentido directamente aquello de lo que trata este principio: que quitar es cómo haces sitio para lo que importa.
Basado en “Simple Made Easy” de Rich Hickey, A Philosophy of Software Design de John Ousterhout, Subtract de Leidy Klotz, y el viejo estándar de perfección de Saint-Exupéry.