Bootstrapping o la simplificación de la complejidad

Cuando estás en la universidad te enseñan a diseñar sistemas desde cero. Diseñar un microprocesador por medio de dopaciones. Diseñar una PLA con su juego de instrucciones usando puertas lógicas. Diseñar un lenguaje de programación usando autómatas en forma de reconocedores léxicos y sintácticos. Diseñar una red utilizando conexiones y protocolos de red de todo tipo. Diseñar un sistema operativo desde cero añadiendo la gestión de procesos, la gestión de memoria, la gestión de los recursos. 

Figura 1: Bootstrapping o la simplificación de la complejidad

Recuerdo todas esas enseñanzas con mucho cariño. Recuerdo las estrategias algorítmicas para resolución de diversos problemas. Cuando utilizar Dijsktra. Cuando usar una estrategia de Back-tracking, cuando un Divide and Conquer o una solución basada en una recta de barrido. Me ayudaron a tener herramientas en mi caja de destornilladores y martillos para saber que podía probar cosas distintas en cada problema.

De muchas de ellas os he hablado a lo largo de los muchos artículos que le he dedicado a mi relación con la universidad, pero hoy os quiero hablar de una que me ayuda día a día en mi trabajo y que aprendí en la clase de Sistemas Operativos. Se llama Bootstrap o Bootstrapping. 

Figura 2: Definiciones de Bootstrap

Cuando estudiaba en la universidad cómo se construye un sistema operativo desde cero la pregunta es.. ¿cómo construyo software para un sistema que aún no existe porque está siendo construido? ¿Cómo hago una herramienta de gestión de ficheros gráfico para un sistema operativo que aún no existe? Pues no hay magia. Se trata de hacer Bootstrap, una forma de simplificar la explicación de lo complejo que es sustituir un sistema operativo que funciona por otro.

Si tienes que construir un sistema operativo completo deberás comenzar a hacer un programa que sea capaz de gestionar la memoria, los procesos y la entrada salida. Una vez que tienes los elementos de la gestión mínima, ya puedes comenzar a construir las herramientas mínimas para construir software en él. Construirte tu gestión de ficheros y tu primer compilador. Y una vez que tengas tu compilador ya puedes construir software usando el propio sistema operativo que te estas creando.

No hay magia, solo trabajo y orden. Programar lo mínimo y necesario para que puedas construir software con el sistema operativo que estás desarrollando y completarlo. Es ta sencillo y evidente. Es tan de cómo debe ser todo lo que debe crecer. Construir el círculo virtuoso de éxito de un sistema operativo haciendo varias fases de trabajo en las que priorizas en cada una de ellas lo mínimo que necesitas para que la segunda ola se aproveche de lo construido en la primera versión. En la primera ola de trabajo.

Esta es la estrategia que se debe seguir en cualquier nuevo proyecto que se quiera lanzar en una empresa. Hacer una estrategia de Bootstrapping, poniendo los recursos iniciales necesarios para cumplir con los objetivos de la primera versión, y que estos sirvan para alimentar la segunda versión del proyecto/producto para acelerar su crecimiento.

Yo usé esa estrategia cuando me puse a trabajar con ElevenPaths. No quise muchos más recursos que los que pude manejar. No quise hacer más de lo que pudiera hacer bien y que me pudiera servir para la siguiente evolución. Hice Bootstrapping con ese proyecto.

Trabajar de esa forma te ayuda a priorizar muy mucho. A diferenciar siempre entre qué es lo más importante y necesario y qué es lo que es accesorio en esta fase. Qué es lo que debo tener y qué es lo que es "Nice to have". Algo que una y otra vez comparto con mis compañeros a la hora de hacer el roadmap de los proyectos y decidir en qué invertimos nuestros recursos. Tengo mi regla de las tres "P" repetida una y otra vez con ellos.

Desde luego, construir un sistema operativo completo es complejo. Son muchos los detalles, y herramientas que tiene tu viejo sistema operativo desde el que estás programando el core del nuevo sistema operativo que siempre van a pesar en contra en una posible comparación. Por eso se debe lidiar entre hacer unas cosas con el viejo sistema operativo donde aún puedes programar cosas para el nuevo, y entre hacer cosas desde el nuevo sistema operativo aprovechando las ventajas que tenga el nuevo sistema operativo que has diseñado.  Hay que balancear la transición. Nunca hay que olvidar esto.

Estas enseñanzas las tengo siempre dentro de mí cuando hago algo, y las he usado años después cuando tuve que diseñar la estrategia de la margarita en la 4ª Plataforma para implantar la visión Data-Centric en Telefónica. No se puede cambiar de un día para otro la forma en la que se gestionan los datos y se desarrollan las aplicaciones. Hay que hacer Bootstrapping. Hay que ver cómo se pueden ir diseñando las funciones mínimas del nuevo "sistema operativo" para ir desarrollando las primeras herramientas y poder ir migrando.

Figura 3: La estrategia de la margarita para hacer Bootstrapping con los datos

Cuando diseñas un nuevo proyecto para una empresa que lleva años funcionando no puedes pensar que vas a tener un folio en blanco para ti. Siempre va a haber algo que ya está funcionando y que hay que modificar, cambiar o reemplazar sin que deje de dar servicio. Hay que ver cómo haces el cambio teniendo en cuenta que lo que estás haciendo siempre va a ser más pequeño y sin todas las herramientas que probablemente haya ya en el viejo sistema operativo. No va a ser fácil. Y no lo hagas.

Pensar en hacer un proyecto desde cero siempre es fácil si estás en una página en blanco y no hay nada ya. Pero si estás en una empresa con vida, pasado, clientes y servicios, vas a tener que aprender a hacer Bootstrapping constantemente. A ver qué es lo importante al principio y ver cómo vas decidiendo qué haces en cada sistema operativo (el viejo y el nuevo) hasta que acabe implantado el nuevo sistema operativo por las ventajas que ofrece.

Saludos Malignos!