Planea el funeral antes de construir
Planea el funeral antes de escribir el código. La mayoría de los equipos son excelentes construyendo y pésimos eliminando — así cada flag "temporal", cada endpoint improvisado y cada abstracción ingeniosa se acumula hasta que nadie se atreve a tocarlo. La solución es una sola pregunta en tiempo de diseño: ¿cómo borraríamos esto en tres años? Hazla antes de comprometerte, y la respuesta cambia lo que construyes.
Por qué la eliminación empieza en el diseño
La eliminación se decide mucho antes de que alguien abra un PR de borrado. Como lo plantea el equipo de ingeniería de Google en Software Engineering at Google, "choices of programming language, software architecture, team composition, and even company policy and culture all impact how easy it will be to eventually remove a system." No puedes agregar la capacidad de borrado después — o la diseñaste o no.
Dos fuerzas hacen difícil la eliminación, y ambas son más baratas de combatir desde el inicio:
- La Ley de Hyrum. Mientras más consumidores tiene un sistema, más de ellos dependen de comportamientos que nunca prometiste, "and the harder it will be to deprecate." Una interfaz estrecha y explícita tiene un radio de impacto pequeño; una que se filtra es un campo minado.
- Costo de mantenimiento invisible. El mantenimiento es silencioso y continuo; el costo de eliminar es ruidoso y de una sola vez. Esa asimetría explica por qué "funding and executing deprecation efforts can be difficult politically" — la factura por no eliminar nunca aparece en un tablero.
Las preguntas de diseño
Antes de escribir algo nuevo, responde estas en papel:
| Pregunta | Cómo se ve una buena respuesta |
|---|---|
| ¿Cómo lo apago? | Un flag, una línea de configuración — no un redespliegue en cinco servicios. |
| ¿Quién dependerá de esto? | Una interfaz nombrada y documentada; los internos quedan privados para que nadie se acople a ellos. |
| ¿Cómo migran los consumidores? | Existe un camino de reemplazo antes del lanzamiento, no después del correo de deprecación. |
| ¿Puedo eliminarlo por partes? | Sí — el sistema es descomponible, así el borrado es incremental, no de golpe. |
Si alguna respuesta es "no estoy seguro", encontraste la parte que será cara de eliminar.
Los flags son inventario, no son gratis
Los feature flags son el ejemplo clásico de construir-barato, eliminar-caro. El equipo de Martin Fowler los presenta como inventario con un costo de acarreo: "It's very important to retire release flags once the pending features have bedded down in production. This involves removing the definitions on the configuration file and all the code that uses them. Otherwise you will get a pile of toggles that nobody can remember how to use." Cada flag es una bifurcación en tu flujo de control que alguien tiene que recordar colapsar. Agrega el ticket de eliminación en el mismo PR que agrega el flag.
Movidas de experto
- Escribe el plan de eliminación en el documento de diseño. Un párrafo de "Cómo lo removemos" junto a "Cómo lo construimos". Si no puedes escribirlo, el diseño no está terminado.
- Dale una fecha de caducidad a cada cosa temporal. Release toggles, shims de migración, shims de compatibilidad — etiquétalos con un dueño y una fecha de muerte para que no se promuevan a permanentes en silencio.
- Mantén la superficie mínima. Cada abstracción es una superficie de mantenimiento y cada dependencia es una relación. Cuando te tiente generalizar algo usado una sola vez, escribe la versión mínima — es la que puedes borrar sin arqueología.
- El desmantelamiento es una restricción de diseño, no algo posterior. Otras disciplinas de ingeniería planean el desmantelamiento de una planta mientras la diseñan. El software que filtra su implementación por todas partes es doloroso de eliminar; el software diseñado para removerse se mantiene barato toda su vida.
Los sistemas que filtran su implementación por todas partes son dolorosos de eliminar. Los diseñados para removerse siguen siendo baratos. Pregunta cómo lo borrarías — y deja que esa respuesta guíe la construcción.
Recursos
- Software Engineering at Google — Deprecation (Cap. 15)
- Martin Fowler — Feature Flag (retirar release flags)
- Feature Toggles (Pete Hodgson) — gestionar el inventario de toggles
- Write code that is easy to delete, not easy to extend
¿Construyendo algo nuevo? Yeda AI diseña, audita y despliega sistemas LLM en producción que se mantienen baratos de cambiar y baratos de eliminar.