La Ley de Hyrum: con suficientes usuarios, hasta los bugs generan dependencia
Alguien está dependiendo de tu bug en este momento. Acuñada por el ingeniero de Google Hyrum Wright, la Ley de Hyrum dice: "Con una cantidad suficiente de usuarios de una API, no importa lo que prometas en el contrato: todos los comportamientos observables de tu sistema serán utilizados por alguien." El contrato documentado no es la interfaz. El comportamiento observado sí lo es — incluyendo bugs, detalles de tiempo, la redacción de los mensajes de error y efectos secundarios no documentados.
La interfaz implícita
Todo sistema desarrolla una segunda especificación invisible. Tus docs prometen un tipo de retorno; tus usuarios también dependen del orden exacto, de la latencia en milisegundos, del campo que "por accidente" siempre está presente, y del string de error contra el que aplican regex. El propio resumen de Wright sobre el efecto: con el tiempo "la implementación se convirtió en la interfaz." Por eso los equipos terminan enviando compatibilidad bug por bug — el viejo bug ahora sostiene carga.
La ilustración clásica es xkcd 1172: un usuario escribe diciendo que la barra espaciadora le calienta el café, y resulta que una app se reinicia a propósito cuando se mantiene una tecla presionada. Arregla el "bug" y rompes un flujo de trabajo real. Con suficientes usuarios, no hay cambio tan pequeño del que nadie dependa.
Una deprecación es una migración, no un memo
La trampa es tratar la remoción como un anuncio. Software Engineering at Google es directo: "A menudo es tentador simplemente poner una advertencia de deprecación en un sistema viejo y alejarse sin ningún esfuerzo adicional." Rara vez funciona. El libro divide la deprecación en dos tipos:
| Tipo | Qué es | Qué pasa en realidad |
|---|---|---|
| Consultiva | Una advertencia sin obligatoriedad | "Esperamos que los clientes migren, pero no podemos forzarlos" — reduce el uso nuevo pero "rara vez lleva a que los equipos migren activamente." |
| Obligatoria | Un plazo firme de remoción con consecuencias | Funciona solo cuando hay un equipo asignado a hacer el trabajo de migración de los consumidores. |
Por qué falla el "solo anúncialo": los usuarios literalmente no pueden cambiarse cuando dependen de un comportamiento que el reemplazo no replica. Y una deprecación obligatoria sin financiamiento, advierte el libro, "puede parecerles a los equipos clientes algo malintencionado." El patrón escalable es concentrar la experticia de migración en el equipo dueño de la remoción — primero los migras, luego borras.
Diseña para el borrado desde el inicio
La deprecación más barata es la que planeaste antes de enviar. El consejo del libro: "la deprecación de un sistema de software puede planificarse mientras esos sistemas se construyen por primera vez." Haz la pregunta en tiempo de diseño, no tres años después:
- "¿Cómo borraría esto en tres años?" Si la respuesta es "no puedo," estás diseñando una dependencia permanente.
- Minimiza la superficie observable. Aleatoriza lo que no debería ser confiable (orden de iteración, latencia sobrante) para que nadie pueda depender de ello — la misma lógica detrás del orden aleatorio de los mapas en Go.
- Versiona y controla. El comportamiento nuevo detrás de un flag o un endpoint nuevo, para que la ruta vieja pueda medirse y drenarse en lugar de arrancarse de golpe.
Para usuarios avanzados
- Instrumenta antes de deprecar. No puedes migrar una dependencia que no puedes ver. Agrega logging/métricas a la ruta vieja primero, para que la remoción la impulse un grafo de uso que tiende a cero — no una fecha de calendario.
- Las advertencias de deprecación necesitan una salida. Una advertencia sin ruta de migración documentada solo entrena a los usuarios a ignorarla. Envía el reemplazo y el codemod juntos.
- Esto también aplica a los sistemas de IA. El tono de un modelo, su formato de salida exacto, incluso una particularidad en cómo estructura el JSON se vuelve un contrato de facto en el momento en que los agentes y parsers downstream dependen de ello. Fija las versiones del modelo, congela los esquemas de salida, y trata un cambio de modelo como una migración — no como un cambio de configuración.
Recursos
- Ley de Hyrum — el enunciado canónico y su origen
- Software Engineering at Google, Cap. 15: Deprecation (consultiva vs obligatoria, migración activa)
- xkcd 1172: Workflow ("spacebar heating")
¿Envías sistemas sobre los que otros construyen? Yeda AI diseña, audita y migra software y sistemas LLM en producción — con el borrado planificado desde el día uno.