# El código barato es el código más caro El costo de cambiar el software no es constante — sigue una curva, y la forma de esa curva la define tu arquitectura. Saltarte SOLID, DRY, KISS y DI no ahorra dinero; mueve la factura para más adelante, con intereses. Aquí está la economía, con los números. - **Author:** Fedor Chishchin - **Published:** 2026-06-02 - **Tags:** architecture, methodology, business - **Source:** https://fedorthinks.com/es/blog/cheap-code-is-expensive --- He visto esta película más de una vez. Un equipo decide lanzar rápido y saltarse la arquitectura — "hagámoslo a lo bruto por ahora, es más barato, ya lo limpiaremos después". Primer mes, vuelan. Las funcionalidades caen a diario. Todos se felicitan entre todos. Noveno mes, ese mismo equipo necesita tres semanas para cambiar un botón, cada estimación se equivoca por un factor de tres, y nadie toca el código de pagos porque la última vez tumbó el checkout. La versión "barata" resultó ser la cara. Esto no es un cuento moral sobre hacer las cosas como Dios manda. Es economía. Y la economía es más brutal de lo que la mayoría de quienes construyen software se imagina. ## El costo del cambio es una curva, no un número Aquí está lo que casi nadie pone en el precio: **el costo de hacer un cambio en el software no es constante.** Agregar la misma funcionalidad es barato en una base de código y ruinosamente caro en otra. La diferencia es la arquitectura. Esto no es una opinión — es una ley observada. En los años 70, Meir Lehman estudió cómo evolucionan los sistemas grandes a lo largo de décadas, y una de sus [leyes de la evolución del software](https://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution) es la de la _Complejidad Creciente_: a medida que un sistema evoluciona, su complejidad aumenta **a menos que se haga un trabajo explícito para reducirla.** Cada cambio que haces agrega un poco de desorden. El siguiente cambio tiene que navegar ese desorden, así que cuesta un poco más. Luego agrega el suyo. El costo por cambio trepa. Esa es la curva. Esfuerzo por funcionalidad, graficado contra el tiempo. La buena arquitectura no hace que el cambio sea gratis — mantiene la curva plana. La mala arquitectura la deja volverse exponencial. ## Dos equipos, mismo producto Martin Fowler dibujó esto hace años como la [Design Stamina Hypothesis](https://martinfowler.com/bliki/DesignStaminaHypothesis.html). Imagina dos equipos construyendo el mismo producto. Grafica las funcionalidades acumuladas entregadas contra el tiempo. El equipo que se salta el diseño va **adelante al principio** — no están "perdiendo" tiempo en arquitectura. Pero las líneas se cruzan. Fowler lo llama la _design payoff line_. Después de ella, el equipo que invirtió en diseño se despega y nunca devuelve la delantera. La trampa es que la ventaja temprana es real y visible — la puedes mostrar en una demo. El cruce es invisible hasta que ya lo dejaste muy atrás. Para cuando sientes que la curva se dobla, ya entregaste tu "MVP" sobre una base que no aguanta un segundo piso. No ahorraste tiempo. Lo pediste prestado. ## El tiempo es la moneda, y la factura es enorme Cada hora que un desarrollador pasa peleando contra la base de código en lugar de construir en ella es dinero. Y son _muchísimas_ horas. - La encuesta [Developer Coefficient](https://stripe.com/files/reports/the-developer-coefficient.pdf) de Stripe encontró que los desarrolladores pasan alrededor del **42% de su semana** lidiando con deuda técnica y código malo — unas 13.5 horas en mantenimiento más ~4 más peleando específicamente con código malo. Solo el código malo lo estimaron en **85 mil millones de dólares al año** en productividad perdida. - La investigación de McKinsey sobre [deuda técnica](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity) la puso en el balance: los CIOs reportaron que **del 10 al 20% del presupuesto** destinado a nuevos productos se desvía silenciosamente a pagar la deuda técnica (un tercio de ellos dijo que es más del 20%), y que la deuda técnica vale **del 20 al 40% del valor total de su patrimonio tecnológico.** Las empresas que cargaban con _menos_ deuda hicieron crecer sus ingresos cerca de **un 20% más rápido** que las que cargaban con más. Lee esos números como una sola frase: **construir barato no elimina un costo, lo reubica.** Lo sacas del presupuesto de construcción — visible, de una sola vez, justo lo que intentabas reducir — y lo metes en el presupuesto de mantenimiento, que es invisible, permanente y compuesto. Cambiaste una compra por una suscripción, y no leíste las condiciones de renovación. ## El muro La curva no solo se vuelve empinada. Tarde o temprano se vuelve vertical. Hay un punto en el que agregar una funcionalidad toma tanto tiempo, o rompe tanto, que efectivamente _no puedes_ — el producto deja de ser capaz de evolucionar. Mientras tanto, el competidor que mantuvo su curva plana pasa caminando junto a ti agregando las cosas que tus clientes te están pidiendo. La versión dramática de esto es [Knight Capital](https://www.henricodolfing.ch/en/case-study-4-the-440-million-software-error-at-knight-capital/): años de código muerto dejado pudriéndose en producción, ninguna disciplina real de despliegue, y una mañana de 2012 un lanzamiento mal hecho reactivó código que debía haberse borrado. En **45 minutos** la firma disparó millones de órdenes no intencionadas y perdió **440 millones de dólares** — y dejó de existir como compañía independiente. La mayoría de los equipos nunca estalla de forma tan espectacular. Hacen algo más silencioso y, en total, más caro: se frenan hasta detenerse. Y entonces llega el proyecto más caro que una empresa puede intentar — el Big Rewrite. Nadie reescribe porque el código viejo sea feo. Reescriben porque la curva se volvió vertical y no queda otra jugada. La reescritura no es la enfermedad; es la factura de la arquitectura que no compraste, llegando toda de golpe, en el peor momento posible. ## "Pero ir rápido significa sacrificar calidad" — no La objeción que más escucho es que la arquitectura es el impuesto que pagas por ser lento y seguro, y que las startups no se lo pueden permitir. Los datos dicen exactamente lo contrario. Una década de [investigación de DORA](https://www.multitudes.com/blog/dora-metrics) (el programa _Accelerate_) sigue encontrando lo mismo: los equipos que despliegan **más rápido** también tienen las tasas de fallo **más bajas.** Velocidad y estabilidad no son un trade-off que equilibras — son dos salidas de la misma causa: una base de código que puedes cambiar con confianza. La buena arquitectura es lo que compra esa confianza. La elección "rápido vs. bueno" es falsa; los equipos baratos simplemente no consiguen ninguna de las dos, lentamente. ## Dónde las reglas mueven la palanca de verdad Esta es la parte que importa en la práctica. SOLID, DRY, KISS, DI no son gusto académico. Cada una es una palanca sobre la forma de esa curva: - **Responsabilidad única** (la S de SOLID): un cambio toca un solo lugar, no nueve. El radio de impacto de cada edición se mantiene pequeño — la diferencia entre "dos horas" y "dos semanas más una regresión en el checkout." - **DRY — una sola fuente de verdad por cada hecho:** cuando una regla vive en exactamente un lugar, la cambias una vez. Cuando está copiada y pegada en ocho, la cambias ocho veces y se te escapa la novena — y la novena es el bug que llega a producción. - **KISS:** lo más simple que funciona es lo más barato de entender, y la mayor parte del costo del software no está en escribirlo, está en _leerlo_. Cada pizca de astucia que agregas hoy es un impuesto que paga cada lector futuro — incluido tú, dentro de seis meses, sin recuerdo alguno de por qué. - **DI — inyección de dependencias:** cuando las partes dependen de contratos en lugar de concreciones, puedes intercambiarlas, probarlas y cambiarlas de forma aislada. (Cambié el proveedor de IA detrás de este mismo sitio cambiando un solo valor de configuración, sin reescribir la funcionalidad. Eso es DI comprando una curva plana.) Ninguna de estas trata sobre elegancia. Cada una trata sobre evitar que el esfuerzo por cambio siga trepando. ## Por qué es tan difícil de vender La razón por la que "hagámoslo a lo bruto" sigue ganando la discusión es un truco contable: **el ahorro es inmediato y visible; el costo es diferido e invisible — y recae sobre otra persona.** El fundador que dijo "barato por ahora" se anota la victoria este trimestre. El equipo que hereda la base de código paga los intereses durante años. Esa asimetría es la razón por la que la opción barata gana la reunión, justo hasta que pierde la empresa. Que es también por la que casi nadie se lo cree con un ensayo. Se lo creen después de haberlo vivido una vez — después de la reescritura, después del trimestre en el que el roadmap no se movió, después de que el ingeniero senior renunció porque cada cambio se había vuelto una pelea. La buena arquitectura es la lección que aprendes por las malas y que luego nunca desaprendes. Su valor llega junto con las cicatrices. Puedes pagar la arquitectura por adelantado, en una moneda que controlas: un poco más de tiempo de diseño, un poco más de disciplina, unos pocos principios sostenidos con consistencia. O puedes pagar por su ausencia más tarde, en una moneda que no controlas: velocidad perdida, estimaciones reventadas, un producto que ya no puede moverse, y eventualmente una reescritura que quizás no termine a tiempo. La factura llega de cualquier forma. Lo único que estás eligiendo es la tasa de interés. "Barato" nunca fue la opción barata.