Los feature flags, o interruptores de funcionalidad, son una herramienta potente de la ingeniería de software, pero su uso indiscriminado puede salir caro. Este artículo analiza los escenarios en los que aportan valor real y aquellos en los que conviene evitarlos.
Entre los usos justificados se encuentran las pruebas A/B, como las que aplica Amazon para medir el impacto de nuevas funcionalidades sobre cohorts aleatorios de usuarios. También resultan útiles en epic complejas con muchos subcommits repartidos por el sistema, donde desplegar todo a la vez sería arriesgado y un flag maestro permite activar el cambio cuando todas las piezas estén listas. Un tercer caso válido es el de equipos sin control sobre el despliegue, como el antiguo equipo de Android de Facebook, donde hacer rollback es políticamente o técnicamente inviable y el flag permite mitigar efectos sin tocar el binario. Incluso sirven para programar lanzamientos con fecha fija sin necesidad de desplegar en ese instante.
El problema aparece cuando los flags se convierten en muleta. Confiar en ellos como sustituto de un buen suite de tests automatizados, de un proceso de QA robusto o de la capacidad de hacer rollback es una trampa. En Google, la filosofía es «rollbacks are normal»: ante un problema, se revierte primero y se investiga después. Además, cada flag duplica los estados que el código debe contemplar, y la deuda técnica hace que muchos flags olvidados queden activos durante años. El caso extremo citado es el de Knight Capital, que perdió 460 millones de dólares en 30 minutos por código muerto tras un flag en mal estado. La conclusión: los feature flags son útiles para fines concretos —experimentación, coordinación de releases y mitigación—, pero no deben usarse como red de seguridad permanente ni como sustituto de buenas prácticas de despliegue y testing.