Hace unos meses ocurrió algo interesante en Twitter que nos sirve de ejemplo para evidenciar que no existen las soluciones sencillas a los problemas complejos.

La historia tiene como a uno de sus protagonistas a George Hotz, un hacker famoso por haber sido el primero en romper la seguridad del iPhone con apenas 17 años, y también por ser demandado por Sony por hacer lo mismo con la PS3.

En el otro lado y como no puede ser de otra manera si hablamos de Twitter en tiempos recientes, Elon Musk.

La historia comienza con Hotz a quién se le calentó la boca en Twitter diciendo que podía arreglar la búsqueda de la red social en 12 semanas. Musk recogió el guante y le contrató para hacerlo.

Apenas cinco semanas después, Hotz dimitía.

A día de hoy, la búsqueda de Twitter sigue siendo tan pésima como siempre.

Hotz es una leyenda. Nadie puede negar su capacidad o habilidades técnicas. Y, sin embargo, ni siquiera él fue capaz de entender al reto al que se enfrentaba.

No hay soluciones sencillas a problemas complejos

En el artículo La futilidad de estimar problemas complejos introducíamos las peculiaridades de estos.

Construir una casa es un problema del dominio sencillo en el que los humanos tenemos, literalmente, miles de años de experiencia. Los pasos a seguir son claros, definidos, dan lugar a pocas sorpresas, y cuando una de estas se da, generalmente es fácil encontrar una solución porque no vas a ser el primero al que le ocurra.
Desarrollar software, por el contrario, generalmente es un problema del dominio complejo. Salvo que trabajes en una consultora en la que básicamente haces el mismo trabajo para el mismo tipo de cliente una y otra y otra vez, al desarrollar cualquier producto que valga la pena, probablemente te enfrentes a problemas totalmente nuevos sobre el que no hay un cuerpo de conocimiento sólido en el que te puedas apoyar.
Las soluciones a estos problemas no se diseñan como quién diseña los pasos para construir una casa, porque literalmente no sabes lo que te vas a encontrar. Las soluciones a los problemas complejos emergen de las interacciones del sistema a base de prueba y error, no se pueden anticipar de antemano. Literalmente te enfrentas a lo desconocido.

Y, sin embargo, nos empeñamos en aplicarlas

Los humanos y lo complejo no nos llevamos bien. Nuestro cerebro necesita certidumbre, y lo hace simplificando situaciones buscando patrones conocidos que aplicar.

Uno de estos patrones más populares para quién se introduce en el mundo del desarrollo de producto de software es el de la asignación de recursos. En el mundo lineal de los problemas sencillos, mover recursos suele ser una forma estupenda de acelerar un proyecto.

¿Vas tarde construyendo una carretera? Traes a más personal para hacerlo.

Paradójicamente, en el mundo no lineal del desarrollo de software, esta relación es justo la contraria. Añadir más gente a un proyecto de software que ya va tarde, hace que vaya más aún más despacio, como bien describió Fred Brooks en el clásico The Mythical Man Month.

“Adding more people to a late software project will make it even late. — Fred Brooks, 1975

Brooks da tres razones fundamentales por las que esto sucede:

Hay que entrenar a los nuevos miembros para que entiendan cómo funciona el sistema, lo cual resta capacidad al equipo actual.
A más personas, más líneas de comunicación abiertas, lo que complica y retrasa la toma de decisiones.
La indivisibilidad de ciertas tareas hace que más personas terminen creando más componentes independientes que deben coordinarse entre ellos, lo que aumenta el riesgo de errores, bugs y la complejidad inherente del sistema.

Hotz es joven. Quizás nunca había leído The Mythical Man Month. Quizás nunca tuvo que evolucionar sistemas complejos. O quizás simplemente pensó que sus altas capacidades le permitirían saltarse por completo el primer punto.

En cierto modo apostó a que podría aplicar una solución sencilla a un problema complejo y perdió parte de su reputación en el camino.

Pero nos dejo algo bueno. A partir de ahora podemos aplicar la expresión “No nos marquemos un Hotz”. O lo que es lo mismo. No nos putoflipemos.

Estrategia de Producto

¿Es más sencillo colonizar Marte que arreglar…