Las flores son flores porque caen

Sobre la importancia de descontinuar funcionalidades cuando no contribuyen al crecimiento de nuestro producto.

Shogun es una de las series del año. Ambientada en el Japón feudal, la serie introduce al espectador en la sociedad nipona a través de los ojos de un marinero inglés que llega por primera vez a la isla. El choque cultural, en torno principalmente a cómo se vive el honor y la lealtad, es sin duda uno de los hilos conductores y probablemente su mayor atractivo.

Mariko, uno de los personajes principales, es la hija de una familia noble caída en desgracia. En un episodio, tiene un encuentro con la madre del heredero al trono, Lady Ochiba, con quién compartió infancia, y que ahora está enfrentada al señor al que sirve Mariko. 

Mariko está precisamente en palacio porque su señor le ha pedido que intervenga para liberar a unos rehenes que el consejo de regentes mantiene retenidos. Durante el intercambio entre ambas, Lady Ochiba acusa a Mariko de estar buscando su propia destrucción. Mariko, cierra la conversación con estas poderosas palabras:

Aceptar la muerte no es rendirse. Las flores son flores porque caen.

Pocos días después de ver ese capítulo, observé como Peter Yang, autor de la lista de correo CreatorEconomy.so y Product Manager en Roblox, la utilizaba en un tweet:

Esa relación irónica entre la frase y la necesidad de descontinuar una funcionalidad, me hizo pensar en el paralelismo que podríamos trazar entre el trabajo de un jardinero que cuida esmeradamente de su jardín y el de cualquiera que gestione un producto.

Por qué querríamos descontinuar una funcionalidad

Uno de los pensamientos más peligrosos que existen en el desarrollo de producto es el de pensar que cuando algo ya se ha desarrollado, mantenerlo es gratis. 

Sin embargo, y como bien sabéis los que leéis estas líneas, un producto se parece más a un ser vivo que a un objeto inerte como una caja donde puedes ir metiendo otras cajas sin afectar al conjunto. Como vimos en el artículo de Eduardo Ferro, El Coste Basal del Software, la realidad es que cada funcionalidad, cada nueva línea de código que añadimos, genera un coste de mantenimiento que va reduciendo la capacidad del equipo. 

Haciendo una analogía con un jardín, cada funcionalidad necesita agua y nutrientes para subsistir. No sólo eso, una vez plantada, también compite por el recurso más preciado, nuestra atención. Y es que cada minuto que le dedicamos a hacerla florecer y que no muera, es un minuto de dedicación que le robamos al resto.

Siguiendo con la analogía, podríamos decir que el buen jardinero es aquel que consigue que dar un paseo por sus jardines sea una experiencia satisfactoria, estética y funcionalmente. El mal jardinero, sin embargo, levanta muros y planta nuevas variedades donde no debería, empeorando la experiencia de uso del conjunto.

También, como cualquier cultivo, cada nueva característica puede ser objeto de plagas en forma de bugs. Plagas que el equipo tiene que frenar obligatoriamente si no quiere que se extiendan por todo el jardín, restando recursos que podrían ser empleados en hacer crecer el resto.

Y otras veces, nuestra funcionalidad también puede terminar siendo peligrosa si no aplicamos sus habituales actualizaciones de seguridad, que, como un árbol que se pudre, podrían hacerlo caer y aplastar el resto del jardín, o peor, a algún usuario.

En definitiva, el buen jardinero tiene que ser muy consciente de las implicaciones de añadir cada nueva variedad en su jardín, porque cada una de ellas puede impactar negativamente e impedir que éste crezca sano y fuerte. Y, cuando se equivoca, no puede simplemente dejarlo correr. Tiene que intervenir podando aquellos brotes o malas hierbas que interfieren sobre el resto. 

Eliminar lo que sobra es imprescindible

Haríamos bien en considerar nuestros productos seres vivos en lugar de objetos inanimados capaces de absorber sin coste alguno cualquier idea que se nos ocurra. Y es que, cualquiera que haya pasado el suficiente tiempo en tecnología sabe que conforme la complejidad aumenta, más complicado es mantenerlo y evolucionarlo. Hasta el punto que, de vez en cuando, no queda otra que empezar de nuevo migrando aquello que se pueda salvar a un nuevo terreno. Nuestros colegas ingenieros lo llaman refactorizar. 

Si queremos prevenir llegar a este punto, como buen jardinero, necesitaremos podar y dar forma a nuestro producto eliminando todo aquello que sobra o molesta. De esta forma, conseguiremos:

• Obtener mejores frutos a nuestro esfuerzo enfocando los recursos en aquello que realmente genere valor

• Mejorar la estética y la experiencia de uso, eliminando todo aquello que no contribuye a hacer más fácil la vida a nuestros usuarios

• Reducir nuestro riesgo de bugs y problemas de seguridad que puedan afectar al rendimiento o a la reputación de la empresa

En resumen, debemos reconocer el coste de cada funcionalidad y estar dispuestos a descontinuarla cuando fuese necesario. Solo así podremos asegurar que nuestro producto florezca y prospere en el mercado.