La martingala del software
Si estás buscando un artículo que siente cátedra no sigas leyendo.
Esta es simplemente mi opinión, parcial y sesgada —y qué opinión no lo es—, de la dualidad negocio/ingeniería en base a mi experiencia durante los últimos 25 años trabajando en equipos de todo tipo. No estoy diciendo que esta sea la visión correcta o la más acertada en todos los casos. Es simplemente mi forma de ver las cosas tras muchos éxitos y fracasos. Se ha escrito (y se escribirá) mucho sobre el tema, por lo que es evidente que es una cuestión de escoger el enfoque y el equilibrio que mejor se adapta a cada equipo.
Una de las expresiones más repetidas en el corpus sobre gestión del proceso de desarrollo es "entrega de valor al negocio".
Aunque la expresión suele dar bastante urticaria, en mi opinión su uso está justificado. El "negocio" —entendido como tu empresa y, dentro de ella, las áreas más preocupadas de traer dinero a casa— no está ahí para que simplemente desarrolles lo que te apetezca de lunes a viernes, ni para que discutas durante el café temas tan trascendentales como cuál es la mejor forma de tener un historial de Git limpio, por qué XML sigue siendo muy superior a JSON por mucho que le pese a los nacidos después del 2000 o si realmente los programadores de PHP tienen alma. Es justo al revés.
Y es que, para el negocio, el software —propio o de terceros— existe para atender sus demandas. Es una entelequia que le va a permitir contar con una funcionalidad, con una automatización, para cubrir unas necesidades específicas. Y ahí es donde está nuestra doble responsabilidad.
Pero vamos por partes.
El trabajo de un artesano
Me gusta observar cómo trabajan los artesanos. No voy visitando talleres, pero siempre que tengo la oportunidad de ver uno la aprovecho. Creo que la esencia de un trabajo gratificante está en esos oficios. Algo se perdió por el camino de la ultraespecialización y la automatización. La humanidad en su conjunto ganó, por supuesto, pero hemos perdido algo como individuos.
Si le preguntas a cualquiera de ellos que a qué se dedica, la respuesta será muy similar en la mayoría de los casos: "fabrico sillas", "fabrico bolsos", "fabrico joyas" ... Ninguno te va a responder "atornillo tacos de madera", "coso trozos de cuero" o "golpeo metales hasta que tienen la forma que me gusta". Con la simpleza de mente adecuada ambas actividades son lo mismo, sí, pero una contiene la esencia del oficio, mientras que otra es simplemente la descripción de un acto mecánico.
En cualquier caso, tanto para ensamblar tacos de madera como para hacer sillas, se necesitan las mismas herramientas.
Las herramientas de un artesano
herramienta [...] 3. f. Instrumento que sirve para hacer algo o conseguir un fin.
— DRAE
Cada oficio emplea un conjunto de herramientas básicas. Estas herramientas permiten elaborar algunos elementos necesarios para terminar el trabajo que no estarán presentes en el resultado final.
Por ejemplo, es habitual que se construyan cuñas, agarres, moldes, guías y otros elementos que se van viendo necesarios sobre la marcha. Estos elementos, aún siendo secundarios, son tan necesarios como el martillo o el punzón que el artesano usa en todos sus trabajos. Sin ellos el trabajo no se podría hacer. Y todos, para alguien ajeno al oficio, resultan irrelevantes para el producto final.
En cierto modo no se diferencia mucho de cómo hacemos nosotros nuestro trabajo.
Las herramientas de un desarrollador
Hace bastantes años, cuando me preguntaban cuáles eran mis herramientas de trabajo, mi lista se detenía tras citar el nombre de mi IDE favorito, del sistema de control de código fuente y de los frameworks que estaba usando en ese momento.
El baño de humildad que te llevas cuando descubres que todo eso no le importa a nadie es revelador. Creo que se sitúa en el top 5 de momentos catárticos de mi adolescencia, muy cercano a "no te emborraches la misma noche que has tomado laxante".
Un día descubres que esas herramientas forman parte del kit básico de la profesión. Son el martillo y el punzón que te ayudan a llegar al producto final. Aunque necesarios, son intercambiables. Pero en tu caja de herramientas hay más.
El código. Lo construyes para cubrir tus propias necesidades. Sirve como sustento a otro código, que sustena a otro más. Te permite dar forma a aquello que se estás construyendo, que no es el código en ninguna de sus capas; es la funcionalidad, la automatización; aquello que el negocio necesita. Su función es la misma que la del calzo de madera que se construye para la ocasión.
Pero existe una gran diferencia entre los artesanos que trabajan con elementos del mundo físico y los que escribimos código.
Mientras que para el ebanista puede ser conveniente descartar un calzo de madera una vez que ha cumplido su función, el código, por el contrario, se convierte en una herramienta habitual con la que continuamos trabajando para dar respuesta a nuevas necesidades. No es algo de un sólo uso. Evoluciona y es iterado. Necesita correcciones, adaptaciones o ser retirado. Y, si es lo suficientemente genérico, a veces puede incluso trascender proyectos en forma de biblioteca.
Como cualquier herramienta, hay que mantenerlo en condiciones óptimas.
Carpinteros
El verano pasado me fijé en cómo trabajaban unos carpinteros en casa. Aparte de lo entretenido que resulta ver a alguien usar una sierra circular —cosas de la edad, supongo—, observé que justo antes de cada descanso dedicaban un tiempo a limpiar la zona de trabajo y las herramientas que habían utilizado. Si por algún motivo se saltaban el ritual, lo hacían antes de empezar a trabajar.
Cuando les pregunté si no era mejor simplemente apartar cosas y limpiar con menos frecuencia para perder menos tiempo, me explicaron que así era más rápido y más seguro.
Más rápido, porque la suciedad acumulada durante ese tiempo era muy fácil de recoger con "menos manos" y las herramientas terminaban menos empedradas. Y más seguro, porque moverse entre montoncitos de serrín y retales de madera tiene sus riesgos para los que curioseábamos por allí. Por no hablar del peligro de utilizar herramientas eléctricas sin el debido mantenimiento.
Es tan obvio que parece estúpido plantearlo, pero aún así hay que recordarlo a veces: el esfuerzo de limpiar el doble de suciedad en el área de trabajo, igual que el esfuerzo de doblar una distancia corriendo, no es lineal; es exponecial y supone un riesgo adicional.
Me recuerda a la trampa de la martingala.
La martingala
En juegos de azar, la martingala es la estrategia más simple —y peligrosa, por absurda— que se puede aplicar. Básicamente consiste en apostar una cantidad igual a todo lo que se lleva perdido hasta el momento para, en caso de tener una jugada ganadora, recuperarlo. ¿Y si se pierde? Se repite la operación ¿Y si se pierde de nuevo? Quizás ya sea tarde.
El por qué es peligrosa y absurda salta a la vista, pero veamos un ejemplo.
Tenemos 90€ y participamos en un juego de azar con una apuesta de 10€ que repetiremos si ganamos (G). Cada vez que perdamos (P), haremos una martingala.
| Capital | Apuesta | Resultado | Ganancia | | ------- | ------- | --------- | -------- | | 90€ | 10€ | G | +10€ | | 100€ | 10€ | P | -10€ | | 90€ | 10€ | P | -10€ | | 80€ | 20€ | P | -20€ | | 60€ | 40€ | P | -40€ | | 20€ | - | - | - |
En teoría, con la sucesión de turnos llegará un momento en el que recuperamos lo perdido. Pero nuestra capacidad económica es finita y una sucesión de pérdidas encadenadas es más que probable. Así que sólo necesitamos 4 pérdidas seguidas para entrar en bancarrota. A partir de ahí, nos quedamos sin la capacidad económica para afrontar una nueva apuesta que nos permita recuperar lo perdido.
Conectando los puntos
No tenía ni idea de cómo llamar a esta sección y la verdad es que eso de "conectar los puntos" suena bien en cualquier contexto. Felicitemos al que escribió el famoso discurso de Steve Jobs en Stanford, porque ha popularizado una expresión universal.
Un sillero no es el que ensambla tacos y tubillones de madera. Es el que entiende que su oficio es hacer sillas.
Y añado "sillas donde la gente se pueda sentar". Si no, hablamos de un gilipollas o de algo muchísimo peor: un artista contemporáneo.
Cuando creamos software, no es porque "alguien de negocio" decide que te tienes que poner a escribir código como un descosido. El código que escribes tiene un propósito y forma parte del valor que entregas, porque sin él no habría nada. Pero no es el valor que el negocio necesita. Lo que importa es resolver el problema de la forma más óptima que las circunstancias actuales permitan.
El producto de nuestro trabajo es un intangible en forma de automatización.
Que el código esté escrito de una forma epecífica, o con una pila tecnológica determinada no es algo que le preocupe al negocio, ni prácticamente a nadie fuera de tu área. Y esto está bien. Preocuparnos por la parte más técnica de nuestro trabajo forma parte de nuestras responsabilidades, pero supeditado siempre a entender qué necesita el negocio y cómo podemos resolverle la papeleta.
De ahí que ante una necesidad específica se pueden plantear opciones tan dispares como comprar soluciones de terceros, desarrollar in-house o resolverlo con esfuerzo humano a base de talonario (ocurre más veces de las que te puedes imaginar). Todas con pleno sentido dependiendo de las circunstancias que concurran durante el proceso de toma de decisiones.
Porque para el negocio, si la automatización necesaria no se produce, o no es correcta, lo que hay por debajo es irrelevante. No existe. De igual modo, si la automatización cumple correctamente con las expectativas, el código que lo sustenta sigue siendo igual de irrelevante. Sólo te va a importar a tí. Esto no es ni bueno, ni malo. Ni justo, ni injusto. Simplemente es una realidad.
En unos sectores, quizás la regulación existente nos permitirá ser más pulcros con los análisis y la toma de decisiones. En otros, quizás las necesidades comerciales nos obliguen a ser más laxos. No es lo mismo desarrollar software en el seno de un banco que en una empresa de control de flotas o en una de porno online. Nos guste o no, tenemos que adaptar nuestro enfoque a las necesidades del sector financiero, a las del control de flotas, o las del porno.
No ensamblas tacos y tubillones de madera. Haces sillas y debes saber venderte así.
Es importante un buen mantenimiento del espacio de trabajo y de las herramientas.
Y el código es ambas cosas al mismo tiempo.
Te ayuda a construir más software y a la vez necesitas moverte por él. Debe estar siempre a punto para poder ser comprendido y utilizado. Eso te va a permitir aportar valor al negocio en tiempo y forma. Y si no lo está, ser conscientes de ello y conocer el impacto que esto puede tener en el tiempo (retrasos), o en la forma (alcance de funcionalidades, incidentes de diversa gravedad en producción...).
Que nadie lea aquí una apología de ningún tipo de pureza teórica absurda. No debemos perder de vista que nuestro objetivo primero es atender las necesidaes del negocio.
Pero atender las necesidades del negocio no debe significar comprometer el mantenimiento de nuestras herramientas. Quizás "ahora" no es el mejor momento, pero "nunca" jamás lo es.
No te impongas ciegamente pero tampoco mendigues por trabajar en un entorno de calidad.
Evitar la martingala como estrategia de ingeniería.
Es una cuestión de enfoque a la hora de gestionar el necesario equilibrio entre los esfuerzos de ingeniería y de producto, que deberían ser sólo uno —ayudar a traer más negocio— e ir siempre de la mano, con las concesiones pertinentes. Un desequilibrio extremo hacia una u otra posición genera problemas de disitnto tipo pero con un resultado bastante similar (pista: nunca es bueno)
Una empresa que se deja secuestrar por los problemas artificiales de ingeniería está condenada a cerrar. Así de sencillo.
Por su parte, en empresas cegadas por la cultura de producto se genera un entorno en el que se empuja únicamente el desarrollo de nuevas funcionalidades a toda costa, con el objetivo de validar todas y cada una de las hipótesis del negocio. Este enfoque termina produciendo pérdidas constantes como las que hemos indicado antes (retrasos, reducción de funcionalidades, incidentes de diversa gravedad en producción...) que se hacen cada vez más costosas de recuperar.
Esto suele ocasionar un escenario constante de inestabilidad en el que la presión sobre todos los integrantes del equipo va a aumentando paulatinamente.
Y el ciclo se repite hasta que algo, o alguien, explota. Entonces ya es tarde: te enfrentas a un desarrollo importante que se retrasa en exceso, o bien ocurre un incidente en producción, la guardia se convierte en una ruleta rusa con periodicidad de 30 minutos, un día empiezas a notar cierta desmotivación, la gente abandona con pretextos chorras por no pegarte un portazo en las narices...o una combinación de todo.
En esta fase, si la empresa es pequeña, es probable que se esgriman eslóganes new age maniqueos como "la velocidad es una funcionalidad" o "la velocidad es un multiplicador del tiempo" —que suenan mejor en inglés—, como si la única alternativa a avanzar sin control fuese la parálisis total. Quizás te enlacen a algún post de un fulano en Internet que te explica cómo corrieron los americanos para mandar un cacharro a la Luna (casi siempre se presentan las mismas historias como ejemplo). Porque tú no lo sabes, pero las mejores cosas de este mundo se han construído en un fin de semana entre un puñado de ingenieros con un buen par de cojones. ¿Eres un ingeniero con cojones o uno que se asusta del éxito?
Queramos reconocerlo o no, cada deuda no atendida en un tiempo razonable genera un problema futuro que crece exponencialmente.
Afortunadamente, el punto de no retorno de la mantenibilidad del software es muy difícil de alcanzar, pero el camino puede volverse muy doloroso, retrasando la entrega, produciendo pérdidas de diverso tipo y minando la motivación de equipos enteros.
Por eso creo que es muy importante escoger una estrategia de desarrollo consciente, donde la calidad y el mantenimiento sean pilares fundamentales, pero sacrificables postergables temporalmente sólo si una ocasión puntual y justificada lo requiere, aunque nunca como norma. Alejarnos de la candidez tóxica de pretender que un equipo motivado siempre lo estará, incluso con una tecnología "difícil de mirar" y que pagará la deuda en su tiempo libre o cuando se produzca un incidente, con el extra de presión añadido. Créeme. Lo he vivido. El resultado no beneficia a nadie y no es sostenible en el tiempo.
¿Y cómo saber qué deuda se debe atender primero y cuándo? Es muy fácil. Ahí es donde entra en juego tu equipo de ingeniería, su experiencia y tu confianza en su criterio.