A veces basta con cambiar un poco el orden de los valores que devuelve una función de biblioteca o la redacción de un mensaje de error para que llegue un aviso de que un servicio lejano ha dejado de funcionar de repente. Aunque la documentación nunca garantizó esos detalles, alguien dependía de ese comportamiento. La observación que resume esta realidad en una sola línea se conoce como la «ley de Hyrum (Hyrum's Law)».
En pocas palabras, la ley de Hyrum es una regla empírica de la ingeniería de software que dice que, si suficientes personas usan una interfaz, da igual lo que se haya prometido en la documentación, pues alguien acabará dependiendo de cada comportamiento observable del sistema. Hyrum Wright hizo esta observación mientras trabajaba con cambios de código a gran escala en Google. Su compañero Titus Winters la bautizó como «ley de Hyrum» y la dio a conocer.
En este artículo veremos, en orden, qué significa exactamente la ley de Hyrum y de dónde viene, cómo surgen las interfaces implícitas, qué ejemplos son habituales en el desarrollo de software y, por último, cómo responder a este fenómeno y cuáles son los límites.
La ley de Hyrum y el contrato que va más allá de la documentación
¿Qué es la ley de Hyrum?
La ley suele formularse así. Si una interfaz de programación de aplicaciones (API) tiene suficientes usuarios, para cada comportamiento observable del sistema habrá alguien que dependa de él, independientemente de lo que diga el contrato. En su artículo, Wright atribuye a Winters el mérito de haber bautizado esta observación como «ley de Hyrum» y de haberla difundido.
Con el mismo sentido se habla también de la «ley de las interfaces implícitas (Law of Implicit Interfaces)». A medida que aumenta el número de usuarios, hasta los detalles de implementación que se consideraban privados pasan a formar parte del contrato de facto. Al final, incluso un pequeño cambio en la implementación puede dar lugar a exigencias de «compatibilidad incluso en los errores (bug-for-bug compatibility)».
- Contrato explícito (Explicit Contract). Abarca las condiciones de entrada, salida y error recogidas en la documentación y las especificaciones.
- Interfaz implícita (Implicit Interface). Es el comportamiento que los usuarios han aprendido a esperar tras observarlo repetidamente, aunque no figure en la documentación.
- Comportamiento observable (Observable Behavior). Abarca todos los resultados que se pueden comprobar desde fuera, como el orden de las respuestas, la latencia, el texto de los mensajes de error y el formato de los registros.
Cómo surgen las interfaces implícitas
La ley de Hyrum describe un fenómeno que surge de forma casi inevitable al aumentar la escala, independientemente de la diligencia de los desarrolladores. Aunque creamos haber ocultado los detalles internos mediante la abstracción, desde fuera todavía se pueden percibir muchas señales.
(1) Los usuarios se fijan más en el comportamiento que en la documentación
Con plazos ajustados, es habitual comprobar primero si todo sigue funcionando como ayer, en vez de cotejar la especificación línea por línea. Así, un detalle que por casualidad parecía estable acaba dándose por garantizado.
(2) Las dependencias son distintas, pero juntas abarcan toda la implementación
Un equipo depende del criterio de ordenación, otro de la cadena de texto del código de error y otro del tiempo medio de respuesta. A medida que aumenta el número de usuarios, el conjunto de esas dependencias abarca casi todos los aspectos de la implementación.
(3) La relación con las abstracciones con fugas de Joel Spolsky
La «ley de las abstracciones con fugas (Law of Leaky Abstractions)» de Joel Spolsky afirma que una abstracción no puede ocultar por completo lo que sucede en su interior. La ley de Hyrum añade que, a medida que aumenta el número de usuarios, incluso los indicios que se filtran terminan adquiriendo el peso de un contrato.
Ejemplos habituales en el desarrollo de software
Aunque pueda sonar a teoría, el mismo patrón se repite en el trabajo cotidiano con bibliotecas y servicios. A menudo, un cambio que se consideraba «fuera de la especificación» termina afectando al sistema más alejado.
(1) El orden de las listas devueltas
Aunque la documentación diga que «el orden no está garantizado», si hasta entonces los elementos siempre se han devuelto en el mismo orden, se acumula código que depende de él. Si un día se introduce el procesamiento en paralelo y cambia el orden, salen a la luz de golpe los supuestos que las pruebas no contemplaban.
(2) Mensajes de error y texto de los registros
A veces, otro programa analiza como cadena de texto una frase escrita para lectores humanos y decide qué rama ejecutar en función de ella. Si basta con reformular la frase para hacerla más amable para que se detenga una automatización, estamos ante un caso de este tipo.
(3) Rendimiento y tiempos de ejecución
Aunque la especificación no garantice la latencia, una velocidad que se ha mantenido parecida durante años se convierte de hecho en la esperada. Si al quitar la caché o añadir pasos de verificación el sistema se vuelve un poco más lento, empiezan a llegar avisos como «la función sigue siendo la misma, pero solo a nosotros se nos agota el tiempo de espera».
Cómo responder a la ley de Hyrum y cuáles son sus límites
La ley de Hyrum deja margen para seguir haciendo cambios. Advierte de que cualquier aspecto observable puede convertirse en parte del contrato y de que conviene reservar deliberadamente margen para modificarlo.
- Clarificación del contrato (Clear Contract). La documentación y las pruebas deben distinguir con claridad qué se garantiza y qué queda fuera de la garantía.
- Variación intencional (Intentional Jitter). Desde el principio, se altera el orden o se hace variar ligeramente la latencia para evitar que se afiancen supuestos basados en coincidencias.
- Verificación de la compatibilidad (Compatibility Testing). Antes de un cambio a gran escala, se ejecuta un amplio abanico de patrones de llamadas reales para detectar de antemano dónde se producen fallos.
Cuando el número de usuarios es muy alto, cualquier modificación, por pequeña que sea, puede hacer que algo deje de funcionar para alguien. El libro «Software Engineering at Google» también trata esta ley como una restricción comparable a la entropía, que no se puede eliminar y debe tenerse siempre presente durante el diseño y el mantenimiento. También conviene evitar que la ley se convierta en un pretexto para aplazar indefinidamente mejoras necesarias.
La ley de Hyrum pone de relieve que la interfaz real de un sistema popular va mucho más allá de su documentación. Esta observación, nacida de la experiencia de Google con cambios a gran escala en sus bibliotecas, se ha convertido en una referencia común para los equipos que buscan mantener sus API y plataformas a largo plazo.
Antes de modificar un comportamiento menor, vale la pena preguntarse una vez más si alguien ya lo estará observando aunque no figure en la documentación. Ese es el primer paso para aplicar la ley de Hyrum al diseño de cambios que eviten fallos.
