Sandi Metz: duplicación vs abstracción incorrecta para CTOs

¿Por qué la duplicación de código puede salvar tu startup?

Sandi Metz, una de las voces más influyentes en desarrollo de software, lo dijo claramente en 2016: "la duplicación es mucho más barata que la abstracción incorrecta". Para un CTO o founder técnico en 2026, esto significa que tolerar duplicación temporal es preferible a bloquear tu código en una abstracción prematura que acumulará condicionales y se volverá inmantenible.

Si estás construyendo un SaaS y tu equipo está presionado por lanzar features, esta perspectiva puede ahorrarte meses de refactorización dolorosa y evitar que tu deuda técnica se convierta en un freno al crecimiento.

¿Qué es exactamente "la abstracción incorrecta"?

Una abstracción se vuelve "incorrecta" cuando comienza a acumular parámetros, banderas y condicionales para comportarse de manera diferente según quién la llame. En lugar de simplificar el código, termina centralizando la complejidad en un solo lugar que se vuelve frágil y difícil de modificar.

Según Metz, los síntomas clásicos son:

• Un módulo compartido que necesita cada vez más parámetros para funcionar
• Condicionales dentro del código abstracto que dicen "si viene de X, haz esto; si viene de Y, haz aquello"
• Cada nuevo caso de uso requiere modificar la abstracción existente en lugar de extenderla limpiamente
• El equipo tiene miedo de tocar ese código porque "siempre se rompe algo"

Esto no es solo código feo: es deuda técnica activa que ralentiza cada iteración futura.

El método de Sandi Metz para salir del problema

Cuando identificas que tienes una abstracción incorrecta, Metz propone un camino contraintuitivo pero efectivo: volver atrás. El proceso tiene tres pasos:

1. Reintroducir la duplicación: Haz inline del código abstracto en cada lugar donde se llama
2. Podar por caller: Dentro de cada caller, usa los parámetros que se pasan para determinar qué subset del código inlined realmente ejecuta ese caller específico
3. Eliminar lo innecesario: Borra los bits que no se necesitan para ese caller particular

Esto elimina tanto la abstracción como los condicionales, reduciendo cada caller solo al código que realmente necesita. Una vez que removiste completamente la vieja abstracción, puedes empezar de nuevo, re-aislando duplicación y re-extrayendo abstracciones cuando el patrón sea claro.

Metz lo resume así: "Cuando la abstracción es incorrecta, el camino más rápido hacia adelante es hacia atrás". Esto no es retroceder, es avanzar en una mejor dirección.

¿Cuándo está bien tolerar duplicación?

Para founders y CTOs en 2026, la pregunta práctica es: ¿cuándo debo permitir duplicación y cuándo debo abstraer? El research actual sugiere estas heurísticas:

Tolerar duplicación cuando:

• Estás en etapa temprana y el dominio del problema aún no está claro
• Tienes dos copias de código simple y similar
• La duplicación es de código stateless o utilidades en proyectos/microservicios separados
• Mover rápido es más valioso que tener código perfectamente DRY

Considerar refactorización cuando:

• Tienes tres o más copias con drift comportamental real
• La duplicación se convierte en un hotspot de cambios repetidos
• Puedes nombrar un concepto compartido real, no solo similitud visual
• El costo de mantener la duplicación supera el costo de abstraer

Una regla práctica para CTOs: dos copias de código simple suelen ser más baratas que una mala abstracción. Pero tres o más copias con comportamiento divergente son señal de investigar un mejor diseño, no necesariamente de abstraer inmediatamente.

¿Qué significa esto para tu startup?

Si eres founder técnico o CTO de una startup en 2026, esto tiene implicaciones directas en cómo gestionas tu equipo de ingeniería y tu roadmap técnico:

Acción 1: Implementa tags de "DUPE" en lugar de refactorizar prematuramente

Cuando veas duplicación durante el desarrollo rápido, agrega un comentario // DUPE: [ID único] en lugar de forzar una abstracción inmediata. Esto te permite:

• Mantener track de dónde está la duplicación
• Priorizar refactorización cuando el patrón sea estable
• Evitar el sunk cost fallacy de defender abstracciones incorrectas

Muchos equipos usan esto similar a los tags TODO, con un identificador único que vincula las piezas duplicadas para volver a ellas en el momento adecuado.

Acción 2: Establece un criterio de "tres copias" para tu equipo

Define una política clara: permitir duplicación hasta que haya tres instancias con comportamiento similar real. Antes de eso, el costo de una abstracción prematura (complejidad, acoplamiento, miedo a cambiar) suele superar el beneficio. Después de tres copias, programa tiempo de refactorización en el sprint.

Acción 3: Audita tus abstracciones existentes cada 6 meses

Revisa los módulos compartidos que han acumulado condicionales. Si encuentras código que necesita muchos parámetros para comportarse diferente según el caller, considera aplicar el método de Metz: inline, podar, y re-extraer solo cuando el patrón sea claro.

El contexto de 2026: ¿sigue vigente este consejo?

Sí, y más que nunca. En un ecosistema donde las startups necesitan iterar rápido y pivotar frecuentemente, la flexibilidad del código es más valiosa que la elegancia prematura. Las abstracciones incorrectas son especialmente peligrosas en 2026 porque:

• Los equipos son más pequeños y el conocimiento está más concentrado
• El tiempo de mercado es crítico y la deuda técnica frena la velocidad
• Las abstracciones prematuras dificultan integrar IA y automatización que requieren código claro y predecible

Como señala Metz, el objetivo no es eliminar toda duplicación, sino evitar bloquear el código en una abstracción antes de que el dominio se estabilice. La duplicación es deuda técnica, pero una abstracción incorrecta es deuda técnica con intereses compuestos.

Conclusión

El consejo de Sandi Metz de 2016 sigue siendo fundamental para CTOs y founders técnicos en 2026: prefiere duplicación sobre la abstracción incorrecta. Cuando una abstracción acumula condicionales y parámetros, el camino más rápido hacia adelante es volver atrás, reintroducir duplicación, y refactorizar solo cuando el patrón sea claro.

Para tu startup, esto significa:

• Tolerar duplicación temporal mientras el dominio no está claro
• Usar tags DUPE para trackear dónde refactorizar después
• Aplicar la regla de "tres copias" como trigger para investigar abstracción
• Auditar abstracciones existentes que han acumulado complejidad

La clave no es evitar toda duplicación, sino evitar el sunk cost fallacy de defender abstracciones que ya no sirven. Como dice Metz: "Esto no es retroceder, es avanzar en una mejor dirección".

Fuentes

• The Wrong Abstraction - Sandi Metz
• When Code Duplication is the Right Answer w/ Sandi Metz
• The Wrong Abstraction - Seb Pretzer