La abstracción equivocada: por qué los ingenieros de software deben preferir la duplicación a una abstracción prematura

Todos los equipos de software conocen el lema: « DRY — Don't Repeat Yourself », « No te repitas ». Durante décadas se ha presentado como la piedra angular de la calidad del código. En una breve entrada de blog de 2016, Sandi Metz sostuvo que la regla se ha aplicado masivamente mal: la abstracción equivocada cuesta mucho más que la duplicación. Esta semana, el ensayo ha vuelto a lo alto de Hacker News, generando miles de comentarios.

Metz es una de las plumas más conocidas del diseño orientado a objetos y de la comunidad Ruby; su libro « Practical Object-Oriented Design in Ruby » es material de curso estándar. « The Wrong Abstraction » ocupa sólo nueve párrafos, pero su perdurabilidad merece atención.

La tesis de Metz es sencilla. Cuando se ven patrones similares repitiéndose en un código, es tentador extraer inmediatamente una abstracción común — una función auxiliar, una clase abstracta, una interfaz genérica. Pero esa decisión prematura es arriesgada: aún no se sabe cómo divergirán los patrones en el futuro. Con los años, la abstracción se dobla un poco para cada nuevo llamador, los parámetros se acumulan, la lógica condicional se cuela — y la abstracción acaba siendo mucho más compleja que el problema inicial.

Su fórmula: « La duplicación es barata. La abstracción equivocada es muy cara de revertir. » Porque, una vez que el equipo ha construido alrededor de la abstracción equivocada, deshacerla significa desenredar todas las llamadas, encontrar la verdadera línea de separación y reconstruir el código del otro lado. Eso es muchas veces más trabajo que simplemente copiar-pegar.

Metz reconoce que la duplicación da miedo a los ingenieros: « Ver las mismas 20 líneas en tres sitios, la voz en tu cabeza diciendo 'DRY this up' es normal. Resistir ese instinto va contra el reflejo que nuestra formación de ingeniería ha reforzado. » Su recomendación: esperar a que el patrón se repita tres o cuatro veces antes de extraerlo. Para ese momento, se puede ver qué partes son realmente compartidas y cuáles son específicas del contexto.

En la era de los microservicios y las API esto importa aún más. Cada nueva biblioteca compartida es un acoplamiento entre equipos; con el tiempo, ese acoplamiento se convierte en un componente sustancial de la deuda técnica. Hyrum Wright, antiguo ingeniero de Google y editor de Wikipedia, formalizó el principio ahora conocido como ley de Hyrum: « Con un número suficiente de usuarios de una API, todos los comportamientos observables del sistema — no sólo los del contrato — serán dependidos por alguien. » Por eso el coste real de la abstracción equivocada es tan alto.

El ensayo de Metz ha recuperado actualidad en 2025-2026 porque las herramientas de codificación asistidas por IA — GitHub Copilot, Claude Code, Cursor — pueden ser muy agresivas con la detección de patrones y la sugerencia de abstracción. Un comentarista en Hacker News escribió: « Copilot me sugiere constantemente 'DRY' tres funciones; las tres funciones aún sirven dominios genuinamente distintos. La consolidación prematura es un error mucho más común en la era de la IA. »

La réplica de Metz: la abstracción es producto de entender las diferencias, no de reconocer las similitudes: « Que dos cosas se parezcan no significa que deban abstraerse. Cartografía primero las dimensiones en las que difieren; sólo abstrae cuando puedas decir 'todas esas diferencias se mantendrán fijas en el futuro.' » Esa frase es una de las más citadas de la ingeniería de software de la última década.

En la práctica, deshacer la abstracción equivocada suele suponer « la mitad de la deuda técnica ». El antiguo ingeniero principal de Stripe Patrick McKenzie hizo una observación similar en un ensayo de 2024: « Las decisiones de ingeniería más caras de los primeros años de Stripe fueron abstracciones compartidas tomadas demasiado pronto. Cada una nos costó seis meses de media para deshacerla. »

La razón de la longevidad del ensayo de Metz es que es independiente del lenguaje y la stack. C++, Java, Python, Rust o TypeScript — Ruby o Go — da igual. La abstracción equivocada es una propiedad no del lenguaje sino de la propia decisión de ingeniería. Por eso un ensayo de 2016 sigue impactando con la misma utilidad fresca a un lector de 2026. Un matiz importante: Metz no dice « DRY siempre es incorrecto » ni « la duplicación siempre es correcta ». Lo que sostiene es que el coste real de una decisión de abstracción es mucho mayor del que la mayoría de los ingenieros estima.