La trampa de la erosión de metas y el síndrome de la rana hervida
Cuando la percepción de calidad se ajusta constantemente a la baja, un conformismo que nos puede llevar a puntos de no retorno.
Este artículo fue publicado originalmente en Noviembre de 2023 en mi blog, es la última trampa de los sistemas complejos que me quedaba por republicar aquí.
Imagina que inicias una startup y conformas un equipo de producto. Pronto tenéis algo en producción con código greenfield, entendido a la perfección por todos. Ya he escrito sobre cómo el software tiende a la entropía, y sin un diseño evolutivo respaldado por prácticas como las de eXtreme Programming, la calidad puede deteriorarse, afectando la adición de nuevas funcionalidades, la tasa de errores, el burnout del equipo, etc.
Imagina que este equipo no sigue buenas prácticas para mantener un código sostenible y posee habilidades de programación limitadas por lo que produce un software de baja calidad tanto interna como externa: errores, no cumple expectativas, mala UX, etc. En unos pocos sprints, nos damos cuenta de estas consecuencias y tomamos medidas, como contratar a alguien más capacitado.
El actor en este bucle de retroalimentación (fundador, tech lead o manager, por ejemplo) tiene un estado del sistema deseado que compara con el actual. Si nota que hay discrepancia, actúa.
Este bucle de compensación debería mantener el rendimiento deseado, pero la realidad es que tras 2 o 3 rotaciones de equipo, la startup podría fracasar. Lo que quiero destacar es que, si el problema se hace evidente pronto y con magnitud notable, normalmente hay tiempo para reaccionar y tomar medidas.
Esto también se puede modelar con existencias y flujos:
El diagrama muestra la calidad del software (Software Quality), que mejora con la refactorización continua (refactoring) o empeora por falta de diseño y acumulación de deuda técnica (entropy). La meta de calidad del equipo (Actual Quality Goal) impulsa la mejora continua ante desviaciones (gap).
La trampa
El problema surge cuando la calidad se deteriora lentamente sin provocar una reacción inmediata.
Imagina que el equipo sabe programar, pero no aplica prácticas para mantener la sostenibilidad del código. El estado percibido por el equipo puede parecer peor que la realidad. Así, sus estándares de calidad caen continuamente por debajo de la realidad objetiva (si tal medida existiera). Las metáforas negativas como deuda técnica, código heredado, entropía, etc., tampoco ayudan a mejorar esta percepción.
Cuando las metas siempre están por debajo de la realidad, la erosión de estos objetivos conduce a un código cada vez más deficiente.
En este caso, tenemos dos bucles de compensación compitiendo: uno que provoca acciones para mantener el objetivo (Balancing loop 2) y otro que ajusta el objetivo a la baja (Balancing loop 1), siendo este último más fuerte en este ejemplo.
En dinámica de sistemas quedaría así:
El objetivo de calidad (Actual Quality Goal) se ve afectado y sustituido por una nueva meta erosionada (revised goal).
En la simulación del modelo, podemos ver cómo la meta (línea azul) se erosiona y hace de techo a la calidad (línea verde), que también se deteriora.
Deriva hacia el bajo rendimiento
Este arquetipo de sistema se conoce como “Deriva hacia el bajo rendimiento”. Ocurre cuando los estándares de rendimiento se ven influenciados por el rendimiento pasado. Aspectos como la calidad del software, los resultados o la efectividad de los equipos, que a menudo son difíciles de medir objetivamente, pueden verse afectados. Si a esto le sumamos que la degradación es tan gradual que pasa desapercibida, terminamos quemados como en el «el síndrome de la rana hervida».
La premisa es que si una rana se pone repentinamente en agua hirviendo, saltará, pero si se coloca en agua tibia que luego se calienta lentamente, no percibirá el peligro y se cocerá hasta morir. Esta analogía, aunque macabra, es un mito.
Tendemos a dar más crédito a las malas noticias que a las buenas. Cuando el rendimiento real varía, los mejores resultados se descartan como excepcionales y los peores se recuerdan. Pensamos que las cosas están peor de lo que realmente están.
La salida
La única forma de salir de esta trampa es mantener estándares de rendimiento absolutos. Pero no podemos establecer estándares si no los medimos y, como he mencionado antes, muchas de las cosas que queremos mantener son difíciles de medir objetivamente. En esos casos, nos queda confiar en métricas proxy, siendo cuidadosos de no caer en otras trampas.
Es importante tener en cuenta este patrón en las retrospectivas, donde a menudo nos limitamos a analizar el desempeño del sprint sin ampliar el horizonte temporal de comparación a trimestres, semestres o años.
Otra forma de salida es aprovechar la entrada de nuevos miembros al equipo empoderándoles para que nos saque de nuestra visión de túnel. Que en lugar de sumarse al cargo cult software engineering cuestione nuestros procesos, prácticas y estándares de calidad.
La buena noticia es que podemos usar este arquetipo de manera positiva, marcando como objetivo nuestras mejores marcas por encima del objetivo original, empujando siempre en la dirección correcta.
Aclaración: Las simulaciones presentadas en este artículo no pretenden tener rigor científico. Su propósito es ilustrar visualmente patrones que he observado en proyectos. Es más relevante considerar las tendencias y patrones de las gráficas que sus valores exactos.
Bonus para padres
Llevas 12 años obteniendo sobresalientes en todo, pero de pronto llegas a la secundaria y te enfrentas a mayores exigencias. El primer trimestre te sorprende desprevenido, ya que pensabas que prestar atención en clase sería suficiente, pero no logras obtener ni un notable. “Bueno, será que acabo de volver de vacaciones y aún estoy adaptándome”, te dices. Luego, en el segundo trimestre, aparecen los primeros suspensos. Tanto tú como tus padres se preocupan. Decides ajustar un poco tu esfuerzo y logras sacar algunas calificaciones de bien y notables, lo que alivia a todos, ya que has dejado de suspender. La meta, que antes era obtener sobresalientes, ahora se ha transformado en simplemente aprobar.
Serie: las trampas de los sistemas complejos
Esta entrega forma parte de una serie sobre las trampas de los sistemas complejos aplicadas al desarrollo de productos:
Elusión de las reglas y persecución del objetivo equivocado: La trampa del testing coverage.
Desplazamiento de la carga hacia la intervención: La trampa de la adicción al parche.
Deriva hacia el bajo rendimiento: La Trampa de la Erosión de Metas y el Síndrome de la Rana Hervida. (esta entrega)
Exclusión competitiva: La trampa del «rockstar developer».
Resistencia a las políticas: La trampa de los atajos y el falso dilema entre calidad y velocidad.
Tragedia de los recursos comunes: La tragedia del código compartido.
Si te interesa el tema del pensamiento sistémico aplicado al desarrollo de producto, de vez en cuando organizo talleres sobre cómo usar y sacarle partido a estas herramientas. Si estás interesado en que lo imparta para tu equipo o en algún evento, escríbeme.