Imaginemos una misión espacial (muy del tipo de las que hablamos en este post).
El objetivo es claro: queremos llegar a Marte. Imaginen un mundo estilo The Expanse, donde para evitar los conflictos sociales derivados de las diferencias de clases entre Internos y Cinturoneros, se implementan mecanismos como los créditos grupales tan exitosos en el tercer mundo del siglo XXI. Así que Podemos Progresar se va a Marte a abrir su primer Centro Comunitario en el polvoso planeta rojo (se vale soñar ¿no?)
La pregunta es, ¿cómo llegamos ahí? Hasta ahora, la maquinaria tecnológica de Podemos ha sido básicamente un carro, que nos ha funcionado de maravilla aquí en la Tierra. En su momento el carro, nuevesito, dio mucha batalla. No tenía necesariamente todo el grito de la última moda tecnológica cuando fue creado, pero tenía bases suficientemente sólidas para el trabajo que podía dar en ese entonces.
En el carro trabajaron poquitas personas realmente, no había mucho presupuesto para más. En parte por esto, en parte por el crecimiento cada vez más acelerado que daba el carro, y también por las necesidades que se iban adquiriendo para que el carro funcionara, nunca hubo mucha oportunidad de hacer uno nuevo. Así que los últimos años el carro ya estaba carcacheando un poco, o un mucho.
Entonces llegó la oportunidad de oro: irnos a Marte. ¿Cómo llegar allá en carro? ¡No se puede! Sería como llegar montados en el famoso Roadster de Tesla que Elon Musk lanzó a Marte simbólicamente en 2018. A estas alturas el carro ya debe estar todo oxidado y destrozado, sin batería y nada funcional. ¿Se imaginan que el proyecto de Podemos Progresar de llegar a Marte fuera irnos montados en el mismo carro de siempre? ¡Horrible!
Incluso pensar en algunas 'modificaciones' al carro para habilitarlo para el viaje sería una mala idea. ¿Recuerdan el carro de Homero? Es un ejemplo clásico de muy mal gusto en diseño, y eso hablando solamente del diseño funcional. ¿Qué hay del motor? ¿del combustible? ¿de los neumáticos? ¿de los sistemas eléctricos? Seguro el carro de Homero era peor en esos aspectos y no solamente en su diseño exterior.
Imaginen que al 'carro' que tenemos ahorita por sistema, le queremos añadir un par de alas, un cohete propulsor en el escape, y con eso pensar que volaremos seguros a Marte. ¡Ni pensarlo! Lo que necesitamos es un vehículo diferente, una nave espacial, no sólo más espaciosa, sino también funcional, escalable, que responda rápidamente a nuevas necesidades. Quedarnos con las necesidades actuales, por muy urgentes que sean, sería tener las miras cortas.
Necesitamos, en suma, reeescribir TODO nuestro sistema. El proyecto inició como un deseo de tener algo llamado microservicios en el core del sistema. Pero sólo tener microservicios no sirve de mucho si el resto no cambia también.
El efecto del Segundo Sistema (Second System Effect) es legendariamente temido por los ingenieros que hacen software desde hace mucho tiempo. Fred Brooks lo relató en su ensayo 'The Second System Effect', parte de su fundamental 'Mythical Man Month' de 1975 al hablar del paso que se hizo de sistemas operativos para la IBM 700/7000 a OS/360. Eric S. Raymond habla de un efecto de segundo sistema en su historia de Unix en 'The Art of Unix Programming' de 2004 (pueden leer una traducción de esa historia hecha por mí aquí, y en los enlaces inferiores de esa liga las otras 3 partes). Según Raymond, el efecto de segundo-sistema le sucedió a Multics, el predecesor de Unix, cuando intentaba ser una mejor versión de CTSS, el Compatible Time-Sharing System.
Los efectos de los "segundos sistemas" se suelen ver en los sucesores de pequeños prototipos experimentales. En esa "segunda versión", suele urgir agregar TODO lo que fue dejado a un lado la primera vez, lo que termina provocando un diseño enorme y complicado. Un sistema como el nuestro luego del efecto del segundo sistema, se vería más o menos así:
Pero, aún así, el sistema se debe reescribir, ¿cómo evitar o minimizar los efectos del "segundo sistema"?
TL;DR: con un buen diseño que no sólo implique a los desarrolladores,
y un buen proceso que no sólo implique decisiones de negocio.
En Podemos TI justo estamos en una etapa de (muy necesaria) reescritura. La pregunta persiste: ¿cómo evitar o minimizar los efectos del "segundo sistema"?
- Primero hay que considerar la historia del sistema. En realidad no nació como un pequeño prototipo que luego escaló a un producto terminado.
Para Raymond, la luz al final del túnel se da en el menos observado "efecto del tercer sistema", una vez que el segundo fracasó, se puede llegar a contar con la suerte de tener la oportunidad de regresar a la simplicidad y tenerlo todo bien esta vez, tal cómo le sucedió a Unix.
Quizá lo que denominaríamos "segundo sistema" en Podemos TI es lo que tenemos ahorita: un borlote de funcionalidades metidas a veces con calzador en lo que ya teníamos originalmente, y que los tiempos, la escalabilidad, las urgencias, las necesidades del negocio y demás, nos llevaron a tener nuestra querida pero ya obsoleta carcachita, sin contemplar una estrategia tecnológica adecuada.
Y al final, hoy tenemos un sistema que por lo menos tiene MUCHO aprendizaje de por medio, sobre el negocio que ha evolucionado con el tiempo. Eso no es despreciable y el nuevo sistema lo debe contemplar.
Esto me recuerda a esas pinturas que, por estudios científicos, se ha descubierto que ocultan otras pinturas. Tal como la que ilustra el inicio de este artículo.
- Segundo, como decía más arriba, no podemos ir a Marte en carro, necesitamos una nave espacial completa. No podemos solamente agregarle alas o propulsor al coche. Estamos reescribiendo todo. No sólo el core del sistema, también las interfaces, y las pantallas, y las aplicaciones. Debo decir que contamos con una serie de circunstancias más allá de la suerte, para poder tener esta oportunidad dorada. Pero la pregunta, como fantasma, regresa: ¿cómo evitar que en esa reescritura caigamos en los efectos del segundo sistema?
- Yo diría que la solución está en la estrategia del rediseño. En lugar de que, como la primera vez a lo largo de casi 10 años, las decisiones funcionales y de diseño se tomaran por un lado a partir de un negocio apremiante por conseguir sus resultados, y por otro de un equipo de ingenieros brillantes pero no necesariamente con los skills de diseño adecuados, hoy tomamos otra ruta: el Product Discovery, de la mano de un equipo de Producto Tecnológico que nos está abriendo los ojos, y las posibilidades, a realmente construir nuestra añorada nave espacial.
Hoy en día estamos sentando las bases de una estrategia tecnológica mucho más robusta y acorde con el camino que queremos recorrer como organización. Esto implica muchas cosas:
- El mencionado equipo de producto que nos está guiando a crear y diseñar un producto que realmente de al clavo en las necesidades de nuestros usuarios.
- Una diversificación de nuestro equipo de desarrollo. Necesitamos especialistas en muchas cosas, y hasta ahora con los pocos que éramos habíamos sido generalistas.
- Y no sólo la cantidad de gente, sino la calidad. Y con calidad no sólo su nivel profesional. Su cultura es mucho más importante. Lograr hacernos misioneros de la estrategia tecnológica, no mercenarios.
- Pero la cultura no sólo implica al equipo tecnológico. En realidad necesitamos aculturar a toda la organización. Las decisiones tecnológicas no se toman por urgencias particulares de cada área. Deben ir de la mano de una guía estratégica.
¡La aventura apenas comienza! pero el sueño ya se está construyendo, la nave va en proceso, ¡y pronto nos iremos a Marte!
