Los peligros de reescribir una aplicación

La historia de cómo todo el equipo ejecutivo de Sonos acabó despedido por la mala gestión de la reescritura de una aplicación.

En mayo de 2024, Sonos, reconocida marca de sistemas de altavoces inalámbricos en el hogar, actualizó su aplicación móvil. Ocho meses después, en enero, el consejo de la compañía “dimitió” al CEO. Esta es la historia que llevó a aquel despido.

La actualización no era menor. En Sonos habían decidido cambiar la aplicación a todos los niveles. Cambiaron la forma de conexión de la aplicación con los altavoces, el backend y la infraestructura que lo soportaba, y también la experiencia de uso, el frontend.

Los usuarios de Sonos comenzaron a quejarse desde el primer momento. Por una parte, altavoces que con la aplicación previa funcionaban perfectamente, en esta eran inalcanzables. Por otra, algunas funcionalidades importantes habían desaparecido, y otras habían dejado de funcionar por completo.

En un primer momento, Sonos, si bien reconoció algunos problemas, defendió su decisión aduciendo a que el rediseño de su app había requerido de mucho coraje y que los problemas se solucionarían. Los más viejos del lugar recordarán una escena parecida cuando Steve Jobs les decía a los usuarios de Apple que cogían mal el iPhone 4 y por eso perdía la señal.

Sin embargo, el tiempo pasó y los problemas no terminaban de solucionarse. A los pocos meses del lanzamiento, el CEO tuvo que excusarse públicamente en una nota incrustada en la nueva app.

Poco después llegaría una primera ronda de despidos, y más excusas, hasta la salida final del CEO, seguida de la del CPO, Chief Commercial Officer y CMO. La cronología de los hechos, narrada por The Verge, vendría a ser así:

• 7 de Mayo de 2024: Sonos lanza la actualización de su aplicación móvil

• 9 de mayo: Sonos dice que la actualización requería coraje

• 25 de julio: El CEO de Sonos se disculpa públicamente

• 7 de agosto: Sonos retrasa dos productos para centrar sus esfuerzos en solucionar los problemas de la aplicación

• 14 de agosto: Despide a 100 empleados

• 20 de agosto: Sonos dice que no puede recuperar la aplicación anterior

• 30 de agosto: Sonos abre un tablero de Trello para que los usuarios puedan hacer el seguimiento público de los arreglos en la aplicación

• 13 de noviembre: La facturación de Sonos cae un 8% y los costes por arreglar la nueva app se acumulan

• 13 de enero de 2025: Despiden al CEO

• 14 de enero: Despiden al CPO

• 15 de enero: Despiden al Chief Commercial Officer

• 5 de febrero: Nueva ronda de 200 despidos

• 10 de febrero: El CMO abandona la compañía

¿No está mal para una simple actualización de la app, eh?

¿Qué llevó a Sonos a actualizar su aplicación?

Las razones para lanzar una actualización de semejante envergadura suelen ser casi siempre técnicas y operacionales. Muy probablemente la empresa, durante años, se dedicó a añadir código y funcionalidades a la aplicación sin preocuparse del impacto de este en la experiencia de desarrollo y en el propio rendimiento de la aplicación.

Con el tiempo, la base de código es tan terrible, que empieza a impactar la velocidad de desarrollo, y la empresa comienza a preguntarse qué puede hacer para ir más rápido. Siempre, y digo, absolutamente siempre, alguien, generalmente con poca experiencia, sugiere que la única solución es rehacer la aplicación desde cero.

Se crea un equipo especial para hacer la nueva app y se convierte en el centro de atención de toda la compañía. La aplicación anterior se congela en el tiempo, lo que curiosamente hace que funcione mejor durante unos meses, y el nuevo desarrollo se convierte en el centro de todas las peticiones históricas que nunca se pudieron llevar a cabo en la antigua app.

¿Cambio de infraestructura? Adelante. ¿Rediseño por completo? Venga, vamos. ¿Aquella funcionalidad que pidió el CMO en algún momento? Por supuesto. Todo tiene cabida cuando te pones a reescribir una aplicación.

El alcance de la nueva aplicación crece. Se empieza a invertir más tiempo de lo que se pensaba. Se empieza a recortar a última hora para lanzar. Se fuerza el lanzamiento pese a las advertencias del equipo técnico y de aquellos más cercanos al cliente final. Y, así, se consuma el desastre.

Sobre la salida del CPO, The Verge, escribe:

Chief product officer Maxime Bouvat-Merlin will also be leaving his position. Some employees have told me that Bouvat-Merlin shares a significant amount of blame for the brand damage that Sonos has endured over the last year after deciding to release an overhauled mobile app well before it was ready for customers. There have been reports that top executives at the company ignored warnings from engineers and app testers that the new software wasn’t up to par ahead of its May rollout. Those alarms didn’t stop it from shipping.

Como reescribir una aplicación sin terminar despedido

El primer consejo que os puedo dar, es que no lo hagáis. Casi siempre es una mala idea. Joel Spolsky tiene el artículo definitivo al respecto: Things You Should Never Do, Part I. Citándole:

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

Si tras leer esta entrada y el artículo de Spolsky, todavía te quedan ganas de reescribir una aplicación porque la situación es totalmente insostenible, hay formas de hacerlo sin morir en el intento. Por ejemplo:

• Cúbre la aplicación con tests: Antes de tocar el código, diseña un conjunto de tests end-to-end que compruebe que no se rompe ninguna funcionalidad clave de la aplicación al reescribirla.

• Reescribe poco a poco: Identifica las partes más problemáticas de la aplicación actual, y reescríbelas una a una. Hacerlo así te permite ir mejorándola a base de cambios aislados que vas liberando poco a poco, de forma que si alguno te da problemas, tienes muy fácil identificarlo y corregirlo.

• Lanza los cambios a segmentos controlados de usuarios: Lanza cada pequeña actualización sólo al 10% de tus usuarios y comprueba que la nueva aplicación no impacta en su uso. Si tienes un grupo de usuarios beta, mejor que mejor.

• Repite hasta haber reescrito la aplicación por completo: Vuelve al primer paso y sigue reescribiendo la aplicación en pequeños pasos incrementales hasta que hayas retomado la velocidad perdida. Entonces, puedes permitirte hacer un ejercicio similar con el frontend de la aplicación.

¿Por qué no todas las empresas lo hacen así? Principalmente por falta de experiencia, y porque no es sexy. Se ve la reescritura como la oportunidad de hacer todo lo que durante años se ha querido hacer pero no se podía. De hecho, se suele vender como uno de los argumentos principales para hacer la reescritura, porque la realidad es que a nadie le gusta invertir tiempo de ingeniería en cosas lo que no se ven.

Y entonces llegan las prisas. Y se rebaja la calidad. Y si se lanza al mercado, ocurre el desastre.

Aún en ese caso, hay una forma de amortiguar el golpe, y es evitar la actualización de todos los usuarios, creando una nueva aplicación en lugar de reemplazar a la antigua. Sonos podría haber lanzado una V2 de su aplicación en modo beta, sin forzar a todos los usuarios a actualizar a una versión inferior de lo que tenían.

Decidió no hacerlo así y terminó con todo el equipo ejecutivo fuera de la empresa, y con suerte, servirá de lección para una generación de líderes de producto.