Con el tiempo me di cuenta que me salía más rápido y seguro comprar fuera de Chile. Las demoras y la incerteza en la entrega de los productos, junto con malos ratos, me impulsaron a ir por ese camino. Incluso en costos incluyendo el mayor pago por fletes rápidos, sale más conveniente. Pareciera que el retail chileno para lo único que es bueno es para cobrar.

Así que empecé a comprar en Amazon, varios artículos electrónicos sobretodo. Y la entrega muchas veces es más rápida que hacerla con un proveedor local. En varias ocasiones evalué el tiempo de entrega y Amazon los superaba con holgura.

Pero no todo es perfecto. He observado que la entrega en Amazon depende del carrier que seleccione para el envío. Esto se nota más si te toca que el envío es por DHL, UPS o por ChileExpress. Cuando el envío viene por los primeros las fechas se cumplen, incluso hasta llegan antes. Pero si me toca el último, es probable que tenga una total incerteza sobre el cumplimiento de la fecha, y lo que es peor, ¡hasta Amazon les pierde la traza!

Esa ha sido mi experiencia al menos, después de varias compras.

Cuando era chico recuerdo que se usaba la expresión: “¡si es chileno es bueno!", era una frase que se decía con cierto orgullo, quizás originada en alguna campaña de promoción de la industria nacional¹.

Escribo este rant para cuestionar esa afirmación, porque no es cierta. A lo que apunto es que a quizás esa frase era una guía, una aspiración legitima que guiaba el actuar de las empresas, profesionales y trabajadores chilenos, pero parece que ya no es el caso en muchos lugares.

Al menos en el retail se nota mucho. Demasiado, lo mismo que en la industria logística. Si uno revisa los reclamos de los usuarios de internet en Chile la queja apunta casi siempre a estos dos tipos de operadores.

Por otro lado, hay empresas jóvenes que adoptan otra actitud, como Cornershop, que tiene un trato respetuoso y amable con el cliente, además una gran eficiencia y un alto grado de cumplimiento con la promesa ofrecida, que es lo que esperas como cliente. Empresas jóvenes que tienen clara la importancia de la experiencia del cliente.

Pareciera que la mediocridad es la norma en Chile hoy en día, la mala calidad de los productos, el mal trato los clientes, el pésimo desempeño laboral parece ir en aumento. A tal grado que decir que “si es chileno es bueno”, es más bien una excepción en estos tiempos.

Debemos desterrar la mediocridad de nuestros trabajos, de nuestras culturas. Hay que exigir y auto exigirnos. El mundo ha cambiado mucho y más en estos meses. Tenemos menos paciencia, y no perdonamos los errores, los retrasos, el trabajo mal hecho. Ya no más y quienes no entiendan eso van a perder.

Es una cuestión de sobrevivencia, y más para un país tan pequeño y frágil económicamente como Chile. Tenemos que volver ser buenos, para poder recuperarnos, para poder salir de las crisis que estamos pasando. Y ese cambio parte en cada uno de nosotros, debemos exigir y también autoexigirnos. De ese modo volveremos a decir con orgullo: “¡si es chileno, es bueno!".

En rigor hay dos celebraciones de Linux, la del 25 de agosto que celebra el anuncio original de Linus Torvalds en el grupo de “news” comp.os.minix:

Hello everybody out there using minix –
I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I’d like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things).
I’ve currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I’ll get something practical within a few months, and I’d like to know what features most people would want. Any suggestions are welcome, but I won’t promise I’ll implement them 🙂
Linus
PS. Yes – it’s free of any minix code, and it has a multi-threaded fs. It is NOT portable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that’s all I have :-(.

La segunda celebración es el 5 de octubre, cuando realizó la primera liberación pública del código.

De todas maneras, ¡cómo pasa el tiempo!

Recuerdo que eran mis primero años laborales, pero seguía asistiendo a los últimos años de universidad, y seguía relacionado con varios amigos en el DCC de la Universidad de Chile, fue alguien allí (probablemente Willy), quien me pasó una caja (¿o varias?) de disquettes, para que instalara una distribución de Linux. Era Slackware y probablemente a fines de 1993 o inicio de 1994.

Lo instalé en una PC en mi casa, y no recuerdo muy bien si pude correr X-Windows en ese momento, pero estaba feliz, por que tenía Unix en mi computadora¹.

Hoy Linux está en casi todos lados. Si usas Android, o incluso si lees este post, el servidor en que está instalado el gesto de contenidos de este blog, está basado en Linux. Tu televisor seguramente tiene alguna versión de Linux.

Desde que empezaste a leer este post, seguro que más de cien dispositivos con Linux se activaron.

Linux no es un sistema operativo completo, es el Kernel de un sistema operativo, el núcelo que lo sostiene. Por eso que tienes sistemas operativos como Android en que el resto de las componentes fue construido por Google. En el mundo del escritorio hay diversas distribuciones, o distros, que incluyen Linux como Kernel, pero incluyen otra serie de herramientas y software desarrollado por GNU, son las distros GNU/Linux.

Pero donde alcanza mayor uso Linux, después de los dispositivos móviles, es en los servidores, y en particular hoy en día en los contenedores.

Alpine Linux es una de las distros más populares hoy en día en el mundo de los contenedores. La idea original era desarrollar una distribución que ocupara muy poco espacio y recursos. Todo partió de un proyecto llamado LEAF: Linux Embedded Appliance Framework Project), con la idea de colocar una distribución de Linux que cupiera sólo un floppy (algo que habría sido muy útil en 1994). Pero esta característica la hace muy práctica para poder usada en contenedores, donde queremos ocupar la menor cantidad de espacio posible.

Linux siempre será impresionante. Es el fruto de la colaboración. A partir de la idea de un joven fines, se ha convertido en una de las piezas esenciales que sostiene el mundo tecnológico actual.

¡Feliz cumpleaños Linux!

Les dejaré un video, que muestra cómo se construye Linux. Es de 2012, así que pueden extrapolar como algunos de los números que se mencionan deben haber cambiado:

Desde hace años las comunidades open source, en diversos proyectos, han adoptado una serie de prácticas muy sencillas, pero poderosas, que ayudan a gestionar mejor su código.

Entre estas hay tres que me parece deberían ser adoptadas por los equipos de desarrollo en ambientes corporativos.

Por cierto, estas prácticas funcionan mejor si usas GIT¹.

Mantener una bitácora de cambios

La bitácora de cambios, o changelog, es un archivo que describe todos los cambios relevantes en un proyecto. Hay un proyecto que describe una forma estándar de mantener una bitácora de cambios, se trata de Keep a Changelog²

La idea es muy sencilla, debes mantener un archivo llamado CHANGELOG.md, que se trata de un simple archivo en markdown (el mismo formato que usamos para nuestro archivo README.md³), que contiene todos los cambios relevantes, pero descritos en forma correlativa.

Este es un fragmento de un típico archivo CHANGELOG.md

# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

## [1.0.0] - 2017-06-20
### Added
- New visual identity by [@tylerfortune8](https://github.com/tylerfortune8).
- Version navigation.
- Links to latest released version in previous versions.
- "Why keep a changelog?" section.
- "Who needs a changelog?" section.
- "How do I make a changelog?" section.
- "Frequently Asked Questions" section.

Todos los detalles de cómo gestionar este archivo están descritos en el sitio Keep a Changelog, así que su lectura es recomendada para tener clariddad de cómo escribir este archivo.

Pero notarán que el archivo marca las versiones según una notación, esta corresponde a Semantic Version, que es la segunda práctica que les voy a recomendar.

Versionado Semántico

El versionado semántico es una convención para enumerar las versiones de nuestro software. Su definición se mantiene en el sitio SemVer.org. Y en principio es muy sencilla.

En SemVer usamos tres números para designar una nueva versión, estos números se separan con un punto, así que el formato es algo así:

1.0.1

Al primer número le llamamos MAJOR, al segundo MINOR, y al tercero PATCH. Así que el formato es:

MAJOR.MINOR.PATCH

• MAJOR: se incrementa cuando se agrega un cambio que es incompatible con versiones anteriores.
• MINOR: se incrementa cuando se agrega funcionalidad, pero sigue siendo compatible con versiones anteriores.
• PATCH: se incrementa cuando se corrigen errores en la versión vigente.

En el ejemplo anterior 1.0.1 podemos entender que corresponde a la versión 1.0 del producto, pero lleva una o varias correcciones a errores (bugs).

Por cierto hay varios detalles sobre cómo gestionar las versiones, pero la guia en el sitio es bien completa, y se encuentra disponible en español también: https://semver.org/lang/es/

Commits Convencionales

Conventional Commits es una forma de escribir los mensajes cada vez que hacemos un commit en GIT de una forma estructurada.

La forma de un commit convencional es la siguiente:

<tipo>[ámbito opcional]: <descripción>

[cuerpo opcional]

[nota de pie opcional]

El puede ser al menos uno de estos:

• fix: en que documentamos una corrección
• feat: en que introducimos nuevas características al software
• BREAKING CHANGE: es un cambio que rompe la compatibilidad hacia atrás (y por lo tanto debería afectar el valor MAJOR).

Hay otros posibles tipos: chore, docs, style, refactor, perf, test y otros, que se describen en el sitio oficial de Conventional Commits⁴.

Un ejemplo de un commit convencional⁵:

fix(core): corrige algunos errores de tipeo en el nombre de las clases

Ver el issue para más detalles

Closes #45

Automatizar todo lo anterior

Hay herramientas que permiten integrar los commits semánticos, con CHANGELOG.md y SemVer.

Una lista está descrita en el sitio de Semmantic Commits: https://www.conventionalcommits.org/en/v1.0.0/#tooling-for-conventional-commits

La idea es que al usar conventional commits ayudas a estas herramientas a determinar cuál es el siguiente número de versión que deberías generar para tu siguiente liberación (versión o release).

Además, estas herramientas mantienen actualizado el archivo CHANGELOG.md.

Mi favorita es una escrita en python, que se llama commitizen.

Cuando la instalas y la configuras adecuadamente la herramienta te ayuda a escribir tus commits, y después mantener actualizado tu número de versión y CHANGELOG.md

Un último tip

Yo siempre recomiendo publicar el número de versión en el front de las aplicaciones. A veces puedes crear una página about que contenga un listado de todos los módulos, APIs, usadas, y obtener el release number de cada una (usando SemVer) y mostrarlo en pantalla. Esta práctica ayuda mucho a verificar qué versión está instalada en producción y aclarar y resolver situaciones rápidamente. Automatizar el versionado es sencillo usando algo como commitizen, pero además puedes hacer que tu herramienta de integración continua recoja esa información y la deje disponible en el siguiente build de tu aplicación.

Espero que te sirva esta reseña y difundas estas prácticas en tu equipo, cuéntame si estás usándolas o planeabas hacer algo del estilo en tus proyectos.

Es mucho tiempo, salvo el blog de Alejandro Barros, que partió antes, no conozco otro blog chileno tan antiguo (si alguien sabe de uno me avisa).

A pesar de la irregular frecuencia, este blog sigue vivo, sigue siendo visitado, referenciado y tiene una saludable y fiel audiencia.

He escrito tantas cosas en este blog que es dificil hacer una antología, sin contar este son 1024 posts (un número redondo 😉), pero intentaré recomendar un par de articulos por año:

2005

• “Desarrollar software es como hacer una película”: el primer post de este blog, muy breve, simple, empezando con mucha timidez.

• “Tropicalmente tolerante”: la historia de Hermann Chinery-Hesse un hacker africano en Ghana. Hoy en día se le conoce como el Bill Gates africano (https://en.wikipedia.org/wiki/Herman_Chinery-Hesse).

2006

• “Blogmemes y Meneame dos sistemas distintos”: en 2006 desarollé un sitio que se llamaba blogmemes, una suerte de agregador de noticias compartidos, el sitio llegó a tener más de 50.000 usuarios, pero lo di de baja un tiempo después. Huboo varios sitios similares que imitaban a Digg.com, en plena época del auge de los blogs. En España estaba Meneame, un sitio creado por Ricardo Galli, hubo competencia al inicio y ciertas comparaciones, pero yo no seguí con esta idea y BlogMemes fue cerrado. Meneame sigue vigente aún: https://www.meneame.net/. Hoy leí este par de tweets de Ricardo Galli, creador de Meneame:

- Tenemos que desarrollar más en España y Europa, no podemos dejar el control a Facebook, Twitter, Amazon, Google o Apple

Haces algo con lo que puedes pero con bastante éxito

Amenazas, demandas, bulos para desprestigiar...

Vivido personalmente, pesadilla personal, nunca más.

— Ricardo Galli 🗣️ 😷 (@gallir) August 1, 2020

Y lo de bulos no es tontería, crearon foros y hasta un canal en Youtube avisándome de pederastas, enviaron emails a todos los medios con esos enlaces, bloggers y tuiteros famosillos acusándome de permitir y proteger a pederastas... Panda de cretinos.

— Ricardo Galli 🗣️ 😷 (@gallir) August 1, 2020

Y reflejan el problema de administrar un sitio tipo red social, consume mucho tiempo, esfuerzo y seguro que es blanco de críticas injustas, en esa época no estaba para agregar esas preocupaciones a mi vida.

• “Wikipedia Man o el surgimiento del nuevo pedante seudo intelectual”: Un pedante artículo criticando la pedantería 🤷

2007

• “Lecciones de Ratatouille”: mi admiración por Brad Bird y por qué esa es una gran película.

• "¿Por qué falla el software?": este breve post tiene una frase demoledora: “La verdad, es que el software bien hecho no debería tener fallas”.

2008

• “Atolondrados tecnológicos”: “Un  atolondrado es aquel que procede sin reflexión, en eso estamos convirtiéndonos cuando no nos esforzamos por entender lo que estamos haciendo. Copiar y pegar no es la forma más eficiente de resolver un problema”

• “Los hackers del 5 de octubre”: Un recuerdo y homenaje a dos grandes amigos.

2009

• “Cómo diseñar una API”: hay algunas cosas que digo en este texto que me gustaría cambiar, pero sigue siendo una guía válida en 2020.

• “El manejo informático de la identidad”: para manejar la identidad hay leyes y debemos respetarlas. Es una lástima que este modelo no haya prosperado.

2010

• "¿Puedo Confiar en ti? (La ética como un nuevo nivel de ventaja competitiva)": aunque hemos visto que Google ha adquirido prácticas cuestionables, lo esencial de lo que se habla en este artículo se mantiene y debemos velar porque se cumpla.

• “Deten el reloj, aplasta al bicho”: en rigor este artículo es una traducción de un post de un blog inglés llamado “Word Aligned” de Thomas Guest. Hay muchas verdades en este artículo y además es muy entretenido (si eres programador 😉).

2011

• “Medir y Reaccionar”: sin saber escribí un post sobre uno de los principios más importantes de porqué implantar agilidad en las empresas.

• “Decisiones Irracionales”: este es el primer artículo de una serie que escribí ese año sobre la racionalidad de nuestras decisiones y la falacia del sentido común. Nunca lo puse en un libro, creo que es algo que debería remediar.

2012

• "¿Cuál es la verdad?": este es un post sobre post verdad, antes que ese término se popularizara y se empezara a usar.

• “Un almuerzo en Lafayette Square”: si pudiera viaja en el tiempo visitaría este lugar en este instante para espiar esta conversación de Von Neummann con dos de sus alumnos más brillantes.

2013

• “No somos cocineros”: un post largo, pero bien largo, para contestar una tesis de un académico, que me pareció incorrecta en ese momento, y que en gran parte sigo sosteniendo. Valor a quien se atreva a leerlo y comentarlo.

• "¡No se puede!": siete años han pasado y sigo peleando con Grumpy Cat.

2014

• “Sexo pianos y WiFi”: hablar del aporte de Hedy Lamarr a la tecnología ya se ha vuelto un tópico común, pero en 2014 pocas persona sabían su historia, y de hecho hoy en dia la historia se cuenta de forma incompleta omitiendo el aporte de George Antheil y la extraña relación de estos dos artistas que unidos en la frivolidad llegaron a desarrollar una tecnología tan trascendental. Este debe ser de los pocos textos sobre el tema que cuenta la historia completa.

• “Un conjunto de conversaciones recurrentes”: mi definición favorita de equipo. Y cuando esas conversaciones dejan de darse, o se hacen disonantes, el equipo deja de existir.

2015

• "¿Cuánto más durará este maldito proyecto?": ¿podríamos aplicar los principios expuestos en este post a la duración de la pandemia? La respuesta es no, pero ¿podrías explicar por qué?

• “Revelaciones”: una noche el “Angel de las Categorías” vino a mi en un sueño y me dio una gran revelación.

2016

• “Esos raros lenguajes nuevos”: el inicio de una serie, que ilusamente pensé que tomaría unos cuantos meses 😄.

• “Profesión sólo para hombres”: este post nació de la indignación que me provocó la historia de una joven que entrevisté, quien me contó como su papá le prohibió estudiar ingeniería informática.

2017

• “El botón de los 300 millones de dólares”: la importancia de la usabilidad, se mide en millones de dólares de ganancia o pérdida.

• “Las leyes fundamentales de la estupidez humana”: o por qué la gente estúpida es más peligrosa que la malvada, como hemos podido apreciar por desgracia estos últimos años.

2018

• “The Chain”: el inicio de una serie sobre blockchain, pero desde una perspectiva bien particular que quizás los sorprenda.

• "¿Quién es responsable por la calidad?": la vieja e inútil discusión si es QA o Desarrollo se zanja cuando vamos al origen de las cosas.

2019

• “El Fin de la Agilidad: Parte 1: Grunge”: el inicio de la serie más personal que he escrito, la mayor parte de mi vida profesional resumida en unos posts, cuyos últimos capítulos se están escribiendo aún. Con harta dosis de rock.

• “El Fin de la Agilidad - Parte 8: Heavy Metal”: sobre el dificil problema de estimar software.

2020

• “Entusiasmo Selectivo”: sobre las lecciones que nos dieron los directivos de Bell Labs durante el origen de Unix

• “Manos a la Obra”: sobre lo que nos enseñan los reality de renovación de hogaresa los ingenieros de software.

Cierre

Espero que les guste la selección, a mi me entretuvo recordar cuando revisaba estos posts.

Quiero aprovechar de agradecer a todos mis auspiciadores en Patreon, los que han pasado y los que se mantienen por su soporte y confianza.

Y si te gusta lo que escribo y puedes visitar mi cuenta en Ko-fi e invitarme a un café: https://ko-fi.com/lnds tu aporte ayuda a mantener este y otros sitios, y a preparar futuros proyectos.

Meanwhile, inside the box, Schrödinger's cat plans its revenge. pic.twitter.com/DTmjuaCTCH

— Richard Feynman (@ProfFeynman) July 17, 2020

(Mientras tanto, dentro de la caja, el gato de Schrödinger planea su venganza)

Si has estado bajo una roca, y no entiendes por qué el Gato de Schrödinger se ha vuelto un meme de la cultura pop, te explico a continuación de qué se trata.

En un momento de malvada creatividad, tras un largo intercambio epistolar con Albert Einstein, el físico austriaco Erwin Schrödinger propone el famoso experimento mental que lleva su nombre.

El concepto es el siguiente: se construye un sistema que consiste de una caja cerrada y opaca, en cuyo interior se encuentra un gato, una botella de gas venenoso y un dispositivo que contiene una partícula que podría desintegrarse en cualquier momento, un sensor es capaz de detectar esta desintegración y abrir la válvula que contiene el gas dentro de la botella¹, matando al gato.

La paradoja que plantea Scrödinger es que a menos que abramos la caja y observemos su interior, el pobre gato se encuentra en un estado indeterminado, no está vivo ni está muerto. Diríamos que está en un estado oscilante, que los físico llaman superposición, es decir, podemos decir que hasta que no abramos la caja el gato está vivo y muerto a la vez.

¿Por qué ideó este vil experimento Schrödinger? ¿Para qué ganarse el odio de los gatos, verdaderos amos de este mundo?

Este experimento mental –no querido lector, nadie hasta donde sé, ha montado este disparate en un laboratorio– fue pensado para abrir la discusión sobre las paradojas que plantea la mecánica cuántica en el entendimiento de nuestro mundo.

La naturaleza de la realidad objetiva

Los físicos cuánticos han propuesto diversas interpretaciones para superar esta paradoja, y salvar la vida del micifuz.

La interpretación de Copenhague, nos dice que efectivamente el estado de salud del pobre felino es desconocido hasta que abramos la caja, en ese momento se produce lo que los físicos llaman “el colapso de la función de onda”, y recién en ese instante podemos saber si el minino sobrevive a tan cruel experiencia. Esta interpretación dice que es el observador el que modifica el estado del sistema, por el simple hecho de realizar la medición del estado de la misma. Y este hecho es irreversible e inevitable cada vez que observamos un fenómeno físico. La realidad entonces está siempre fluctuando, el mundo más allá de nuestros sentidos es borroso, difuso, no hay forma de conocer la realidad, y lo peor, es que cuando realizamos una observación la alteramos. Lo malo es que no podemos controlar el efecto de la observación.

La otra interpretación es la de los “muchos mundos”, propuesta por Hugh Everett en 1957. En un mundo el gato está muerto, en el otro está vivo, y cuando realizamos una observación es como si nuestra realidad se bifurcara, entramos a un mundo u otro. No nos damos cuenta, y cada universo vive al lado del otro, la “decoherencia cuántica” nos impide observar todos estos mundos.

Hay algunos que plantean que el colapso de la función de onda es real, objetivo, que realmente sucede, que no sólo es una hipótesis adhoc como lo plantea la interpretación de Copenhague. Es decir, hay una relidad objetiva allá fuera, aunque no la observemos. En esta postura no hay ramas que se abren, ni universos paralelos. El gato está objetivamente muerto o vivo, no depende de lo que observemos. La limitación está en nuestra capacidad para observar esa realidad.

Existe una interpretación relacional, que dice que los cambios dependen de las relaciones entre el observador y el sistema. Para el gato la función de onda ya colapsó, pero para un observador externo el sistema se encuentra en un estado de superposición, sólo cuando abre la caja el observador y el gato comparten la misma información.

Y así hay diversas maneras de elucubrar sobre este fenómeno. Esa es otra de las crueldades de Schrödinger, plantearnos un problema que no sabíamos que teníamos.

Todo esto ha dado paso a diversas especulaciones, científicas, filosófica y seudo científicas por supuesto. Como la idea de que podemos alterar la realidad con la fuerza de nuestro pensamiento.

¿Y si los humanos sómos computadores cuánticos?

El físico matemático inglés Roger Penrose ha planteado ideas polémicas, combinando conceptos de la teoría cuántica y el famoso teorema de Gödel².

En esencia, Gödel demostró que hay afirmaciones que la mente humana es capaz de entender como verdaderas, aunque no es posible construir pruebas formales para validarlas. Las consecuencias de esta incompletitud de los sistemas formales (como la lógica o la matemática), son interesantes, y he escrito sobre esto antes, por ejemplo, sobre su impacto en el emprendimiento: https://lnds.net/blog/lnds/2016/08/30/toda-empresa-es-de-software-o-lo-sera/

Penrose es defensor de la hipótesis de la “Reducción Objetiva Orquestada”, y se basa en un modelo que establece que la conciencia se origina en un nivel profundo de actividades cuánticas dentro de nuestra neuronas.

En esencia, las ideas de Penrose plantean que nuestras neuronas funcionan como qubits y nosotros los seres humanos seríamos ordenadores cuánticos, cuyo comportamiento, lo que llamamos conciencia, es orquestado por lo que Penrose y Stuart Hameroff denominan micro túbulos.

La orquestación es un proceso mediante el cual proteinas asociados a los micro túbulos influyen u orquestan estados de reducción de los qubits, con esto se separan los estados superpuestos y nuestra mente obtiene una visión de la realidad objetiva.

Por otro lado, el argumento Penrose-Lucas³ establece que, dado que los humanos somos capaces de conocer la verdades de las declaraciones no demostrables de Gödel, el pensamiento humanos no es computable, al menos no en el sentido de los computadores que conocemos y apreciamos desde las ideas de Turing y Von Neumann.

De ser cierto el argumento Penrose-Lucas, habría que encontrar el mecanismo que explique esta ventaja de nuestra mente por sobre cualquier computadora construida en base a sistemas formales.

Sin embargo, hoy en día es aceptado que la mayor parte de las leyes de la física son computables (es decir, algorítmicas), cómo les he contado en otra ocasión⁴.

Y acá viene la astucia de Penrose, para el físico el “colapso de la función de onda” es un proceso no computable.

En mecánica cuántica el comportamiento de las partículas se describe mediante “funciones de onda”, que evolucionan de acuerdo a la… redoble de tambores… “ecuación de Schrödinger”. Las funciones de ondas no estacionarias son combinaciones lineales de los estados de un sistema, a esto se le conoce como “superposición cuántica”, cuando un sistema cuántico interactúa con un sistema clásico, se realiza lo que se llama “medir un observable”, y el sistema parece “colapsar” a un estado aleatorio de ese observable desde un punto de vista clásico⁵.

Todas estas teorías de Penrose y Hameroff han sido objeto de diversas críticas, y hasta ahora se han defendido de cada una. Pero sigue siendo polémicas, y difíciles de demostrar.

La teooría se basa en encontrar el sustrato adecuado para sustentar las ideas de Penrose, y este serían los micro túbulos. El cito esqueleto de las neuronas contiene ciertas estructuras que podrían ser los candidatos adecuados para que se ejecute este procesamiento cuántico requerido por las teorías de Penrose.

Roger Penrose escribió en la década de 1990 un muy interesante libro titulado “The Emperor’s New Mind”, aparte de ser un brillante libro de divulgación, es también una crítica a la posibilidad de crear una verdadera Inteligencia Artificial.

El argumento central de ese libro es que no es posible crear una real inteligencia artificial, porque los seres humanos tenemos una capacidad de más potente que la posible con sistemas computables. Es el argumento usando el Teorema de Gödel que expuse antes.

La solución que propone Penrose es que la mente humana tiene estas capacidades por capacidades que le da la mecánica cuántica, que es capaz de resolver problemas no computables. Pero el físico no tenía como explicar donde se podría producir estos cómputos cuánticos en nuestro organismo.

Tras leer el libro, y debido a su trabajo de investigación de las neuronas, Hameroff se acercó a Penrose e iniciaron una colaboración que ya lleva varios años, en búsqueda de ese sustrato que explique la teoría de Penrose.

Hay muchas críticas al planteamiento de Penrose, partiendo por su uso del teorema de Gödel que parece arbitrario, hasta algunas críticas más fundadas desde el mundo de la biología.

Cómo sea las ideas de Penrose no dejan de ser interesantes, y hay que consignar que hay algunos experimentos que muestran efectos de entrelazamiento cuántico en las neuronas, o de capacidades de computo a ese nivel en nuestro cerebro.

Quién sabe.

Quizás la respuesta a la computación cuántica esté en nuestros cerebros, o en los cerebros de los gatos, o quizás no.

StackOverflow es un sitio muy popular en el mundo del desarrollo de software, para quienes no lo conozcan se trata de un foro abierto de preguntas y respuestas, desarrollado en 2008, por Jeff Attwood y Joel Spolsky, dos famosos e influyentes bloggers especialistas en TI,

La idea original era crear un sitio de preguntas y respuestas para desarrolladores de software, que usara un mecanismo de reputación y reconocimiento para determinar la mejor respuesta. Con el tiempo el sitio se convirtió en una referencia muy usada por desarrolladores de todo el mundo, quienes acuden a este sitio para encontrar respuestas a sus problemas más habituales.

El sitio ha sido objeto de críticas, y cuestionamientos. Tal como ocurre en muchos otros sitios similares, la participación no es tan alta. Como indica Ricardo Baeza¹, con el tiempo hemos visto que el concepto de “Wisdom of the Crowd”, que era tan popular en la época que nació StackOverflow, no resultó ser tan cierto.

En StackOverflow sólo el 0.46% de los usuarios ha alcanzado un nivel de reputación sobre 5000, la mayor parte de los que responden sólo responden una pregunta. Sólo el 8% contesta más de 5 preguntas. Así que la participación no es lo que esperaban sus creadores. Además hay estudios que han mostrado que los desarrolladores que usan el código obtenido en el sitio crean software más inseguro que el resto².

La gente de StackOverflow es consciente de las críticas y es por esto que desde hace diez años conducen una encuesta para tratar de entender mejor a su comunidad y lograr una participación más diversa.

Esto la ha convertido en la encuesta más grande para desarrolladores del mundo. La edición de 2020 fue respondida por más de 65.000 personas.

Y aunque hay que considerar que hay un sesgo importante, de todas maneras entrega información valiosa e interesante.

Este año hicieron un esfuerzo por alcanzar una representación más diversa de desarrolaldores, y para eso promocionaron mucho menos la encuesta en sus propios canales, y la publicaron en diversos lugares. A pesar del esfuerzo, no lograron un aumnento significativo de representación como esperaban, aunque lograron algunos aumentos en la representación de latinos y afro descendientes, otras razas y etnias se mantuvieron e incluso bajaron en su representación. Lo mismo en cuanto a representación de género, tuvieron un leve aumento en la representación femennina, anque los que se identifican como no binarios, y de otros géneros se mantuvieron. Lo positivo es que en StackOverflow reconocen que tienen mucho que hacer para aumentar la inclusión en su comunidad.

Pero veamos algunos datos encontrados por este sitio³.

Ignoraré por esta vez las preguntas más técnicas, y sólo me concentraré en aspectos demográficos y socio económicos, en un próximo post hablaré sobre los otros hallazgos.

Raza y Etnia

El 68.3 de todos los que respondieron se identifican como blancos o descendientes de europeos. El segundo grupo serían las personas de Asia del Sur, con un 10.4% y el tercero que se identifica como hispano o latino, con el 7.6%. Estas cifras aumentan un poco al agrupar por los desarrolladores profesionales, en ese caso aumenta para blancos (70.7%), e hispanos y latinos (7.8%), y baja a un 9.6% para sud asiáticos:

Género y orientación sexual

La pregunta sobre género fue respondida por 50,557. Y el 91.5% se identifica como hombre, con una representación de 8.0% que se identifica como mujeres:

Por otro lado, el 1.0% se identifico como persona trans género (sobre una base de 49.345 personas que respondieron esa pregunta específica).

Con respecto a la orientación sexual el 92.1% se identificón como hetero sexual, y el 5.7% como bisexual, sobre un base de 43,992 respuesta:

Género y Roles más experiencia

El siguiente gráfico muestra la participació por género en distintas especialidades:

En el eje vertical vemos la proporción hombres / mujeres según especialidad, y en el eje horizontal la cantidad de desarrolladores, que contestaron la encuesta.

Pueden apreciar que la proporción en Especialistas DevOps es de casi 30 a 1.

La proporción promedio es de 15 a 1. Que corresponde a un 6.6% de representación femenina.

Por otro lado, podemos inferir que el sector en que la proporción de hombres a mujeres es más baja (y por ende hay más participación femenina), se da en el sector de Data Science y Machine Learning, con valores menores a 10 a 1 (es decir, más de un 10% de representación femenina). Pero la cantidad es menor (menos de 500 mujeres que respondieron la encuesta).

La mayor representación femenina se daría entre los desarrolladores front end, backend y full stack, si bien la proporción es peor que en el área de Data Science, al estar cerca de 15 a 1, la cantidad de personas es mayor.

Y si esta proporción es preocupante, porque muestra una baja particpiación que no hemos logrado revertir, hay otro hallazgo que es más preocupante aún.

Estos hallazgos son consistentes con otros estudios que muestran que las mujeres abandonan el área de tecnología a los 14 años en promedio.

Es claro que tenemos mucho que hacer aún.

El desarrollo de software sigue siendo un entorno hostil para otros géneros distinto al masculino. Es un entorno blanco, hetero normado, y muy poco tolerante a la diversidad. Y eso es algo grave.

La tecnología afecta la vida de todos y todas, por lo tanto requiere más representatividad étnica y de género y es un deber mejorar esto⁴.

Los invito a discutir estos hallazgos y compartir ideas sobre qué hacer.

El análisis de la encuesta la pueden encontrar en este enlace: https://insights.stackoverflow.com/survey/2020#overview

Entre esas actividades compartidas está el ver programas de televisión. Era muy raro que en mi casa prendieramos la TV para ver algún canal de cable, pero en estos días además de mantenernos informados, buscamos algo de distracción.

Entre las alternativas más entretenidas están los programas de remodelación y construcción de Discovery Home & Health, que seguro muchos de ustedes conocen. Lo interesante es que de estos reality shows se pueden sacar algunas lecciones para el desarrollo de software, y hoy les quiero compartir algunas reflexiones al respecto.

Me voy a centrar en tres programas: “Vívala o Véndala: Vancouver”, “Las Renovadoras”, y el más popular: “Hermanos a la Obra”.

Las aventuras y desventuras de Jill y Todd

“Vívala o Véndala: Vancouver” es parte de una franquicia de televisión, con diversas variantes que se desarrollan en distintas ciudades del mundo.

El concepto del programa es el siguiente: Una pareja tiene un dilema con respecto a su casa, no sabe si renovarla o venderla. Uno de los miembros de la pareja está más dispuesto a la venta, mientras que el otro prefiere remodelarla pues está apegado al hogar por todos los recuerdos y afectos.

Para ayudarlos a tomar una decisión se presentan dos personajes, que son los protagonistas del show. Un agente inmobiliario (Todd Talbot, en esta versión de la franquicia) que se encargará de mostrarles prospectos de casas que pueden adquirir. El otro personaje es un diseñador o diseñadora de interiores (Jillian Harris en este caso), que les hará una propuesta de remodelaciones y mejoras que deben abordar para darle más valor a su casa. Ambos protagonistas compiten por ver quien logra que la pareja se mantenga en su casa, u opte por venderla.

Análisis de requisitos

El requerimiento de la pareja es resolver su dilema, vender la casa o remodelarla. En la pareja no saben qué hacer, pero para resolverlo el programa les hace una “trampa”, los obliga a realizar una remodelación, con el incentivo de que eso aumentará el valor de la casa, con ese dinero extra pueden tomar la decisión de venderla. Así que en realidad la decisión es una: vender o no vender.

El simil a un proyecto de software sería tomar la decisión entre modificar un sistema ya existente o adquirir uno nuevo. A diferencia de que hacen en el programa, no podemos realizar la mejora y luego vender nuestro software para poder comprar el nuevo, eso no lo he visto pasar nunca, y me parece un escenario irreal (pero uno nunca sabe).

Pero sí podemos hacer algo similar: realizar una prueba de concepto, o un prototipo¹, para ayudarnos a decidir. La ventaja de los prototipos y las pruebas de conceptos es que son de rápida ejecución y de bajo costo.

Lo que vemos en el programa es que después de presentarnos a la pareja y su casa, los protagonistas, el agente inmobiliario y la diseñadora, visitan la casa solos y se hacen una idea de los problemas que llevan a la pareja a esta situación.

Luego los cuatro se reunen y realizan el “levantamiento de requisitos”[^2]. Estos son distintos, aunque complementario para cada uno de los protagonistas. Para la diseñadora es una lista de cosas a cambiar o reparar. Para el agente inmobiliario es una conjunto de características, que deben ser idénticas o mejores a las que ya tiene la casa, más algunas nuevas deseables.

Estos es importante y quiero que lo noten, así que insistiré. Las listas de requisitos son distintas, porque cada uno ofrece una solución distinta al “desafío focal”² de la pareja, el que podríamos definir como “mejorar su nivel de vida y agrado con la casa que habitan”.

La solución de Todd, “comprar una casa nueva”, plantea el desafío de encontrar una casa que les guste al nivel de abandonar su actual hogar a pesar de todas las ataduras emocionales que puedan tener con esta. El desafío focal Jillian es que la pareja se quede en la casa después de las mejoras que va a realizar.

Ejecución del proyecto

Teniendo la lista de requisitos clara empieza a desarrollarse el programa, y surgen los problemas, lo que genera el nudo dramático del show.

Todd es una persona alegre y muy optimista, busca casas y se las muestra de una manera simpática y agradable a la pareja. Es el que da el aspecto más divertido y de comedia del programa. Hay veces en que le cuesta convencer a los futuros compradores, que plantean una y otra vez objeciones, pero se hace cargo y va mediante “aproximaciones sucesivas” acercándose a la casa que la pareja busca. Su principal restricción es el presupuesto para compra. Pero se apoya en cierta manera del trabajo de Jillian, confía en que ella con su trabajo aumentará el valor de la casa, lo que lleva agua a su molino.

Jillian aporta el drama. Ella se encuentra con los imprevistos. Maneja una reserva de emergencia para imprevistos, pero es típico del programa encontrarse con verdaderos desastres.

Inundaciones, termitas, la presencia de asbesto, instalaciones eléctricas o plomería defectuosas. Incidentes siempre hay, porque parten de una casa que ya tiene uso, y las casas requieren mantención. Hay veces en que los ocupantes de la casa no tienen idea de los problemas que su casa tiene. También hay casos en que los problemas los han provocado ellos mismos en el pasado, con renovaciones incompletas o mal ejecutadas.

Jillian tiene que darles las malas noticias, y siempre es criticada. Todo esto se exagera, por supuesto, después de todo estamos ante un “reality show”. Pero sí se refleja mucho de lo que ocurre cuando decidimos hacer una mantención a nuestras casas.

Acá la solución clásica a los problemas que se presentan son las mismas. Ante un imprevisto, se recurre al fondo de emergencia, si con esto no se alcanza, se les pide más a los propietarios, si están de acuerdo, se avanza con el dinero extra. Si no, entonces se debe sacrificar alguna de las mejoras que pidieron.

Esto es lo que en gestión de proyectos llamamos “reducción de alcance”. Si el presupuesto no alcanza, algo de la lista de requisitos debe descartarse. El cliente reclamará, y estará molesto, es obvio, pero acá viene la habilidad negociadora de Jill, quien como buena “project manager”, logra que el cliente acepte esta nueva realidad, producto de los imprevistos. Es habitual que compense el mal rato con alguna mejora extra, un toque de diseño en la entrega final.

Entrega

El proyecto tiene un plazo. Si no han habido retrasos, los cuatro se juntan en la casa renovada. Que siempre luce espectacular.

El programa nos recuerda lo que no pudo completar Jill, junto cona las casas que se le mostraron a la pareja por parte de Todd, con los pro y contra de cada una.

Todd se acerca a la pareja y les muestra el nuevo valor que ha alcanzado su casa tras las mejoras de Jill. Con esto ellos toman la decisión y se decide quien ganó.

He observado que las parejas tienden a vender mientras mayor es el valor agregado de la reparación. Pero la verdad es que no es fácil predecir la decisión que van a tomar, pero es un juego que hago, tratar de encontrar algún patrón que me indique cómo toman la decisión.

Es un programa entretenido y nos ha entregado algunos conceptos interesantes:

• La importancia de entender bien cual es el desafío focal y las necesidades de nuestro cliente.
• Que podemos replicar lo que hace Jill mediante prototipos o pruebas de concepto.
• Que si vamos a adquirir software, debemos revisar varias opciones y contrastar contra nuestra lista de requisitos. Ver en que medida nos acercamos a la satisfacción de esa lista con la más amplia cobertura.
• A gestionar los imprevistos que afectan nuestro prespuesto mediante el recorte de alcance.

Vamos al siguiente programa.

La alegría de Las Renovadoras

Si algo caracteriza este segundo programa es la alegría y optimismo de Mina y su madre Karen.

Todo parte de un proyecto que desarrolló la abogada Karen Laine, quien creó la empresa “Two Chicks and a Hammer”, en conjunto con la hija de su primer matrimonio, “Mina Starksiak”, en 2007.

La empresa se especializa en renovar casas abandonadas en los sectores de Fontain Square y Bates Hendricks en Indianápolis.

Fueron descubiertas por la cadena HGTV en 2014, y publicaron su primer piloto en mayo de 2015. Así nació “Good Bones”, el reality que conocemos en Latino América como “Las Renovadoras”.

Good Bones (buenos huesos), hace referencia a que ellas buscan y adquieren, casas cuya estructura es firme y resistirá una buena remodelación. A veces compran una casa abandonada por unos 4.500 dólares y pueden venderla en vario cientos de miles después de la renovación.

En software también tenemos arquitectura, y los “buenos huesos” son el diseño y la disposición de los componentes de nuestra arquitectura.

Nuestro software no debería decaer al grado tal que requiera ser retirado. Su retiro debería obedecer a razones de negocio u obsolescencia tecnológica.

El equivalente a lo que hacen Mina y Karen es más dificil de encontrar en desarrollo de software, pero lo más cercano es a la manera en que operan las StartUps.

Mina y Karen arriesgan su propio dinero, toman un proyecto en función de una visión más amplia, la renovación urbana de Indianápolis. Cada casa es un aporte a esa visión, y el dinero ganado se re invierte en el siguiente proyecto.

Otro simil sería la reducción de “deuda técnica”³.

Reduciendo la deuda técnica

Podemos ver a cada casa que Mina y Karen recuperan, como una componente de nuestra arquitectura que requiere ser modificada.

¿Pero cuales serían los “good bones”?

Depende de la calidad de tu diseño. Si hay una buena modularización, la tendrás más fácil. Si no, tienes mucho trabajo (como tratar de enderezar el muro de la figura).

Cada módulo se relaciona con otro mediante una interfaz, algo que llamamos API.

Hoy en día hay mucha gente que cuando hablamos de API piensa en endpoint usando el protocolo REST. Pero el concepto de API es muy antiguo, existe desde al menos la década de 1970. Se consolidó en la década de 1980 con el surgimiento de la Programación Orientada al Objeto y el desarrollo de componentes.

Yo recuerdo cuando para poder programar aplicaciones para Windows 3.11 era necesario dominar la famosa API de Windows. Con el tiempo se introdujeron conceptos como OLE y DDE que permitían modelar nuestros sistemas como conjuntos de componentes. Lo mismo pasaba con RPC y luego CORBA en otros ambientes. Esto alcanzó su peak en los noventa.

El diseño por componentes era visto como la forma adecuada de construir software.

La gracia de este diseño es que cada componente expone una API, que es utilizada por cualquier otra componente que quiera acceder a los servicios provistos. Ahí están los “good bones”. Si al menos tienes esta separación puedes apoyarte en esto para reemplazar las componentes.

Si no tienes esa suerte, tendrás más trabajo. Ahí lo que debes hacer es llamar a Todd Talbot y pensar en comprar un nuevo sistema 😄.

¿Qué podemos aprender de Las Renovadoras?

• Si trabajas en una StartUp, la visión compartida, centrarte en cumplir esa visión paso a paso. Tal como ellas están haciendo con Indianápolis.
• Si tienes código legado, busca los “good bones”, esos elementos que sostienen tu arquitectura y que son rescatables, apóyate en ellos para mejorar tu arquitectura, o reducir la deuda técnica.

Los Reyes de los programas de construcción

El programa más popular y exitoso en este género es “Property Brothers”, de los gemelos Scott.

En realidad, son varios programas los que manejan a través de su productora. A estas alturas son dueños, junto a su tercer hermano, de un imperio multimedia, que incluye libros, videos, series web, varios programas de TV, eventos, lineas de productos, etc.

Los gemelos son muy famosos en Canada, su país de origen, y Estados Unidos y en estos momentos producen una serie sobre remodelaciones acompañados por celebridades que en el capítulo estreno tuvo la participación de Bradd Pitt.

Como son varios los programas que producen, cada uno tiene una estructura diferente, pero vamos a centrarnos en el más clásico de sus formatos.

Muchas veces sus clientes tienen un presupuesto que está muy por debajo de sus expectativas. Entonces los hermanos los llevan a visitar una casa, que por supuesto tiene todo lo que sueñan los clientes. Pero está muy por encima del dinero del que disponen.

Este ejercicio no es cruel, sirve para dos cosas, la no declarada es confirmar la lista de requisitos. La segunda es mostrarles que deben ajustarse al presupuesto, y para eso les ofrecen una alternativa: comprar una casa antigua más barata, y reservar una parte del presupuesto para remodelarla.

Después de visitar varias casas se quedan con un par de alternativas. Acá es donde Jonathan les muestra videos animados, que usan realidad virtual para mostrar cómo quedarán la casas tras la remodelación. Esto es crucial. La visualización es de alta calidad, con gran impacto visual y ayuda a los clientes a hacerse la idea de cómo quedarán la remodelaciones y tomar la decisión.

El proyecto inicia, y los clientes participan de la demolicion inicial. Pero eso es casi todo en lo que tendrán participación. Acá el control de proyecto es ferreo por parte de Jonathan. Es él quien propone el diseño, dirige al equipo y gestiona el presupuesto. Mantiene informados a los clientes, y es un excelente negociador, pero cede muy poco a los caprichos de sus clientes.

Otro aspecto muy importante es que el plazo de remodelación es corto, y se cumple, rara vez he visto que se retrasen en algún proyecto. Es por eso que Jonathan no permite mucha participación de los clientes en el proceso, porque tienden retrasar el proceso o aumentar los costos con sus ideas.

En general la remodelación se centra en ciertas partes de la casa, no en toda. Siempre las que mas lucen, como la cocina, el comedor y la sala de estar. Mientras más presupuesto disponible, pueden abordar más habitaciones, pero en general es raro que remodelen toda la casa.

El simil que más se parece es lo que llamamos un “Producto Minimo Viable”⁴ (o MVP por sus siglas en inglés).

Un MVP es un producto final, pero con las características suficientes para satisfacer a algunos clientes. Nos permite tener una retroalimentación que podemos usar para el desarrollo futuro del producto.

Hay que tener cuidado con definir bien el MVP. Y para lograrlo hay diversas técnicas, como Lean Inception, o Design Sprint, o mediante la ejecución de un buen prototipo. Estas técnicas son similares a cuando Jonathan muestra sus videos de realidad virtual.

Lo más importante cuando uno define un MVP: el cliente debe entender que no es todo, sino lo que es viable en el tiempo, presupuesto, y de acuerdo a los objetivos de negocio que queremos abordar.

Constructores de alto desempeño

Una de las características más importantes de Hermanos a la Obra es la calidad del trabajo, el cumplimiento de plazos bastante exigentes, y la eficiencia en el uso de tecnología y heramientas.

La prolijidad de su trabajo es indiscutible. Alguien dirá que son actores, y todo es realizzado por otros, pero no, tanto Drew como Jonathan tenían quince años de experiencia remodelando casas antes de empezar el programa, además de estudios técnicos sobre construcción del Instituto Tecnológico de Alberta, y de administración en la Universidad de Calgary. Por supuesto que cuentan con equipos de alto nivel, tanto en diseño como en construcción, los que se destacan más en otros formatos del programa (por ejemplo, en las series en que los hermanos compiten en la remodelación de casas).

La conformación de equipos es relevante para obtener excelentes resultados.

Un buen equipo es capaz de estimar de manera adecuada. En uno de los episodios un cliente les pregunta si no hay que reservar algo para contingencia, la respuesta de Scott es que el presupuesto siempre considera un margen de 10% para contingencias. Lo otro, es que un buen equipo cumple el plazo comprometido. No sólo eso, sino que además sorprende con la entrega. Todas las remodelaciones son aún mejores que las simulaciones mostradas.

Esa es la característica de equipos de alto desempeño.

Eso se da con la experiencia, el compromiso, la buena relación, el humor o actitud positiva y sobretodo la mejora continua, que requiere de una práctica constante de la reflexión y la auto crítica.

Estas son las cosas que debemos valorar de los hermanos Scott:

• Hay un proceso de incepción previo, que en el caso de los hermanos Scott consiste en visitar una casa que cumple todo pero a un costo superior. Después se muestran varios prototipos en 3D donde los clientes pueden decidir cuál opción tomar.
• Fíjense que al inicio del programa, mientras visitan las casas, en pantalla aparecen las características deseadas. Cuando finaliza el programa esas mismas características aparecen de nuevo en pantalla, indicando que se cumplió con lo esperado. Es la lista de requisitos, que ha sido refinada en la fase de incepción.
• El experto es el que define lo que se hará a nivel técnico. Después de la fase de incepción las visitas de los clientes son cada vez menos. De hecho sólo participan de modo activo en la fase de demolición inicial, después son invitados para validar ciertas decisiones. Hay algunos clientes más “intrusos” y en ese caso Scott sabe como distraerlos, con otras actividades.
• Hay veces que el presupuesto es tan estrecho que los hermanos Scott recurren al apoyo directo de los clientes para que realicen algunas labores, con esto se ahorran dinero. Eso lo puedes hacer también en tus proyectos. Hay veces en que puedes pedir apoyo a tus usuario para que realicen testing, ayuden con documentación, etc.

Manos a la obra

Ahora que tienes algunos similes, puedes usarlos para dirigir algunas conversaciones sobre cómo mejorar tu forma de gestionar proyectos de software. Seguro que si miras algunos de estos programas se te ocurrirán varios símiles adicionales. Puedes usar esto para cambiar, mejorar tu proceso. Yo te mostré además algunos conceptos que son esenciales en el desarrollo moderno de software. Me sorprende que varias de las técnicas que menciono en este artículo no son conocidas por mucha gente de la industria. Es mi esperanza que al presentarlas de esta forma, se despierte la curiosidad por aplicarlas.

Notas

• Ilustración principal tomada de unDraw https://undraw.co/thankful
• Imágenes y video de los programas tomadas de Discovery Home & Health Channel, usadas con fines pedagógicos mediante fair use.
• Caricatura sobre diseño inteligente tomada de Geek & Poke http://geek-and-poke.com/ bajo CC-BY-3.0.
• Imagen del muro tomada de este tweet: https://twitter.com/moonpolysoft/status/1263459227697246208?s=20.

[^2] Un requerimiento es una petición para ejecutar algo, normalmente viene de una autoridad. Por otro lado un requisito es una cualidad, circunstancia o cosa que se requiere de algo. Así que lo que recibimos de nuestro cliente es un requerimiento que contiene una lista de requisitos. Hay mucha confusión con estos términos en el lenguaje informático, sobretodo en Chile, donde confunden requerimientos con requisitos.

“La máquina militar, el ejército y cuanto a el pertenezcan es en el fondo bien sencillo, y parece, por lo tanto, fácil de manejar. Mas reflexionando se ve que ninguna de sus partes está compuesta de una sola pieza; que todas están compuestas de individuos, cada uno de los cuales conserva en todas partes su propia fricción.” – Karl Von Clausewitz

El historiador y teórico militar Carl von Clausewitz siempre sintió revulsión de que una milicia popular, el ejercito revolucionario francés, hubiese derrotado a las fuerzas armadas de la monarquía alemana. A tal grado llegó este sentimiento que cuando vino la invasión a Rusia, por parte de Napoleón, se opuso a la postura oficial prusiana de apoyar a Francia, y solicitó la baja al ejército. Tras esto se trasladó clandestinamente a San Petesburgo, para ofrecer sus servicios al Zar Alejandro I, con la esperanza de liberar a Prusia de la dominación francesa.

Sus reflexiones tras las guerras napoleónicas las plasmó en una serie de manuscritos, que fueron publicados de manera póstuma por su esposa, tras la muerte del militar, debido al cólera, a los 51 años de edad.

De su teoría sobre abordar la estrategia y la táctica de la guerra, los elementos que más se destacan son los conceptos de Niebla de Guerra y Fricción, debido a su universalidad y vigencia.

Niebla de guerra

El término acuñado por Clausewitz hace referencia a la confusión reinantes durante un conflicto bélico. Este fenómeno es una metáfora inspirada por la humareda provocada por los disparos de cañones y mosquetones, y por la polvareda generada por las cargas de caballería durante las batallas de aquellos tiempos, que no dejaba ver con claridad la evolución de la batalla¹.

A lo que apunta Clausewitz es que durante la evolución del conflicto se produce mucha confusión debida a diversos factores como los retrasos, confusión, incertidumbre, etc, que dificulta la coordinación y planificación de las operaciones.

Gran parte de la labor de los estrategas modernos es minimizar los efectos de la niebla de guerra. En la actualidad se apoyan muchos procesos militares con tecnología, pero aún así es algo aún difícil de dominar.

Demasiada información

Los teóricos militares han abordado el problema de la niebla de guerra mediante la incorporación de más información, de forma oportuna y de la manera más eficiente posible. Con ayuda de la tecnologías de información han desarrollado sistemas de comando, control, comunicaciones, computación, inteligencia, vigilancia y reconocimiento (C4ISR), sistemas COP (Common Operating Picture), que les dan la habilidad a los comandantes de visualizar en tiempo real todo aspecto del campo de batalla, incluyendo al enemigo.

Aún así, no garantiza el éxito de las operaciones de guerra. En 2004, durante la batalla de Fallujah las unidades de marina y del ejército norte americanos no podían comunicarse de forma efectiva², como resultado, paradojalmente, del exceso de comunicaciones y del uso de los sistemas COP ocupados por ambos servicios militares para apoyar el desarrollo de la batalla ³.

La necesidad de reportar hacia el mando operativo genera otro problema, el lider de pelotón lleva un computador que sirve para monitorear centralmente a su unidad. Esto le crea una dificultad adicional, puesto que debe controlar a su unidad y servir las demandas de la tecnología. Como ambas requieren su atención, ninguna la recibe totalmente.

Sumemos que los comandantes tienen una capacidad limitada de absorber tanta información. Ante esto la estrategia es engañar al comandante, la que es adoptada de forma astuta por combatientes irregulares, o populares, como diría Clausewitz.

Fricción

El otro elemento que identificó Clasewitz es la fricción de guerra.

Al problema de que cuesta tomar decisiones estratégicas o tácticas debido a la niebla de guerra, se le suma que cuesta que las órdenes emitidas se cumplan adecuadamente, por culpa del fenómeno de la fricción.

Clausewitz dice: “todo en la guerra es muy simple, pero la cosa más simple es dificil. Las dificultades se acumulan y terminan produciendo una especie de fricción”. Y continua ilustrándonos que esta fricción afecta la oportunidad, resultando en efectos cuya determinación no es posible dado que son generados por la casualidad. Simplemente, “la fricción es la fuerza que hace que lo aparentemente simple sea dificultoso”. ⁴

Clausewitz identifica ocho fuentes mayores de “gran fricción”⁵:

• Conocimiento insuficiente del enemigo
• rumores (información adquirida por observación remota o espías)
• incerteza sobre la fuerza propia y posición
• la incerteza que causa que las tropas aliadas exageren sus propias dificutltades
• la diferencia entre las expectativas y la realidad
• el hecho de que el ejército propio nunca es tan fuerte como aparece en el papel
• las dificultades de mantener los suministros del ejército
• la tendencia a cambiar o abandonar planes bien pensados cuando se confrontan con las imágenes físicas vívidas y la percepción del campo de batalla

Hay una cierta sobre posición y redundancia en esta lista, pero consideremos que es una obra completa y póstuma.

Ni los mejores planes salen cómo se espera

Lo importante es considerar que hay muchas causas y fuentes de este fenómeno, y que por otro lado es imposible llegar a conocerlo todo, porque tratar de controlar todo también genera más fricción.

En suma, si bien reconocemos el fenómeno de la niebla de guerra y de la fricción, lo importante es saber que estos fenómenos existen e impiden que el comandante pueda tomar decisiones totalmente informadas, y que sus órdenes no saldrán como él espera.

Esto, claro está, aplica también en otros escenarios de liderazgo, no sólo sirve para la guerra.

En este mismo momento, producto de la pandemia de COVID-19, estamos en un escenario de alta incertidumbre, donde tenemos muchas niebla de guerra.

¿Cómo lo hacían los mejores comandantes?

¿Cómo lo hacen los cuerpos irregulares?

Si revisan la historia, el fenómeno que irritaba a Clausewitz, y que lo llevó a analizar las estrateguas de guerra, es que los cuerpos irregulares, o populares, pueden llegar a ser más exitosos que los cuerpos profesionales con alto entrenamiento o incluso tecnología.

Es cosa de ver la historia de las guerras acometidas por Estados Unidos desde Vietnam hassta la fecha.

Los oponentes usan tácticas sencillas, sin una coordinación sofisticadas, muchas veces son células pequeñas que recurren a tácticas de guerrillas o guerra urbana. Sin mucha tecnología de comunicaciones, y mucho fanatismo o patriotismo, con la motivación de luchar por una causa que consideran justa, contra un adversario superior, lleno de tecnología.

Esto me recuerda la vieja discusión entre el modelo de gestión de Comando y Control, versus la gestión ágil o lean.

La gestión vía Comando y Control topa con los fenómenos identificados por Clausewitz hace ya 200 años. Y lo que es peor, provoca mayor fricción, generando un círculo vicioso.

De seguro ustedes son capaces de identificar muchas fuentes de fricción en su trabajo, esas son parte de las causas de lo que en Lean llaman “Waste”⁶, esta identificación puede quizás ser el primer paso para mejorar.

Relax
You’re quite safe here
– Paranoimia, The Art of Noise

Hace unos ocho o nueve años atrás ibamos a realizar la migración de SVN a GIT en mi trabajo.

Hicimos algunas estimaciones y calculamos que en un par de semanas podíamos migrar todos nuestros repositorios a este nuevo gestor de versiones distribuido.

Dado lo anterior solicité que se instalara GIT en los computadores de los miembros del equipo de desarrollo. La sorprea fue que el equipo de informática interna se negó, indicando que no podían instalar software “con serias vulnerabilidades de seguridad” en nuestros equipos.

La respuesta fue para mi increible, tuve que intervenir, pero el daño ya estaba hecho, y tuve que dar explicaciones y dar explicaciones a varios niveles, asumiendo la responsabilidad si algo pasaba por usar GIT.

La verdad es que tenían un punto, si revisan CVE¹ verán que GIT ha tenido serias vulnerabilidades de seguridad en el pasado: https://www.cvedetails.com/vulnerability-list/vendor_id-4008/GIT.html.

Entonces, ¿debíamos de dejar de aprovechar esta poderosa herramienta por esos motivos?

He escuchado anécdotas de empresas que han bloqueado el acceso a todos los sitios terminados en HUB, para evitar el acceso a sitios porno, esto por supuesto generó que no se pudiera acceder a GitHub, la fuente definitiva de los principales proyectos open source en el mundo.

Cuando quieres innovar o incorporar un nuevo software a tu set de herramientas te encuentras con que la respuesta estándar de casi todos los sysadmin, departamentos de informática es un enorme NO. Y la excusa es que “auditoría, o seguridad de la información, no lo permiten”.

La realidad no es así. Si hablas con tus auditores o gestores de riesgo, ellos te dirán que en realidad lo que corresponde es gestionar el riesgo. Si declaras los riesgos y defines medidas mitigatorias, puedes usar cualquier herramienta que se te de la gana. Es la clásica ecuación: a mayor libertad, mayor responsabilidad.

En mi experiencia, las personas que menos saben de gestión de riegos son las más paranoicas con la seguridad de información. Y esa paranoia hace daño, porque afectan la continuidad del negocio finalmente.

Hay una relación inversa entre usabilidad y seguridad. Y la usabilidad es vital para el éxito de tu negocio.

Si tuvieramos que expresarlo en una ecuación sería algo así:

$$Usabilidad = \frac{k}{Seguridad}$$

A mayor seguridad menos usabilidad.

Y adivinen qué, hay otra ecuación importante:

$$Producto = F(Usabilidad)$$

O, como lo expresa Steve Yegge²:

[…] argumentaré que la Usabilidad es realmente más importante que la Seguridad porque llevando Usabilidad a cero significa que no tienes producto, mientras que dejando Seguridad en cero puedes tener un producto razonablemente seguro tal como la Playstation Network.

Yegge se refiere al fiasco de seguridad de 2011 de la Playstation Network³ que revelaba datos personales de unos 77 millones de usuarios.

Hay personas que dicen que esto es inaceptable, son los que llevan la seguridad a infinito, y por ende la usabilidad a cero.

Estos son los que yo llamo paranoicos de la seguridad de información, y este es su efecto:

$$\lim_{paranoia\to\infty} Usabilidad = 0$$

Debemos combatir esa paranoia, porque si seguimos ese camino nos quedaremos sin internet.

Relájense un poco.

Zoom y la gestión de riesgos

How do I get
How do I get to sleep
Please let me sleep
Po-po-poetry, that’ll work
– Paranoimia, The Art of Noise

Zoom, la plataforma de teleconferencia, se ha vuelto inmensamente popular en estos días pues aparece como una excelente herramienta para realizar video conferencias. En estos momentos está siendo usada por empresas, escuelas, universidades, y grupos de amigos para comunicarse en estos días de cuarentena preventiva y aislamienteo social, productos de la pandemia de Corona Virus.

El servicio aumentó en un 67% su cantidad de usuarios activos a mediados de marzo. En la bolsa el precio de su acción subió en un 263%⁴. Todo este éxito viene aparejado de la paranoia por la seguridad y la privacidad. Algunos incidentes del pasado reflotaron, todo lo que atrae a abogados expertos en acciones civiles, bloggers aficionados al clickbait y por supuesto crackers, hackers y juaquers⁵.

Esto también empieza a preocupar también a organizaciones no gubernamentales preocupadas de la privacidad y a ciber activistas. Estas últimas preocupaciones son legítimas y muy adecuadas, siempre es bueno tener una visión crítica de los servicios que vamos a usar, pero no podemos ser como esas personas que ante una innovación parten con un gran NO a priori. Lo que debemos hacer es un análisis de riegos, evaluar, y en base a antecedentes actualizados tomar decisiones.

Hagamos un poco de análisis de riesgo para Zoom, y partamos con un aspecto comparativo en cuanto a vulnerabilidades, para empezar a magnificar el problema.

¿Saben ustedes cuantas vulnerabilidades de seguridad salen reportadas en CVE ¹ para Google Chrome?

La respuesta es 1858 desde 2008: https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224

En 2019 se publicaron 177 vulnerabilidades para este navegador web: https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-15031/year-2019/Google-Chrome.html

Veamos que pasa con Zoom, desde 2004 se han publicado 5: https://www.cvedetails.com/vendor/2159/Zoom.html

En 2019 se publicaron 2: https://www.cvedetails.com/vulnerability-list/vendor_id-2159/year-2019/Zoom.html

Bien, parece que Zoom no está tan mal en esta dimensión, pero hay que seguir monitoreando esto, la clave acá es: si vas a usar Zoom actualiza en forma permanente el cliente en tu PC, o la app en tu móvil, para que te mantengas al margen de las fallas que pueden ser explotadas por ciber delincuentes.

Han habido una serie de reportes de fallos de seguridad, los que no analizaré en este post, les dejo este artículo en inglés⁶ que explica como se resolvieron varios de ellos, como otros son exageraciones o simplemente mala leche, la que por supuesto alimenta la paranoia: https://blog.rapid7.com/2020/04/02/dispelling-zoom-bugbears-what-you-need-to-know-about-the-latest-zoom-vulnerabilities/amp/.

Nuevamente, acá el consejo es mantener actualizada las aplicaciones nativas de Zoom, o usar el cliente en el navegador (si eres paranoico, no uses Chrome 😉).

Por otro lado, hay un punto relevante que tiene que ver con la encriptación punto a punto o End to End (E2E). Acá es efectivo que Zoom no garantiza aún un nivel de encriptación que permita comunicaciones confidenciales. El consejo por ahora es: no hables de temas confidenciales, o sensibles, por Zoom. Úsalo para actividades que normalmente harías en forma pública o semi pública. De todas maneras Zoom provee versiones on premise de sus servidores, para clientes enterprise, donde esto puede ser reforzado (en las redes LAN o WAN, o con VPNs)⁶, de hecho Zoom tenía como foco principal para dar servicios de tele conferencias a empresas, donde los niveles de seguridad que se pueden implementar son más estrictos.

El último aspecto es la privacidad. Acá han habido reclamos paranoicos como que Zoom envía datos al gobierno chino, o comparte con la NSA o el FBI, los que son exageraciones o interpretaciones distorsionadas de ciertos hechos. Efectivamente el fundador es de origen chino, y Zoom tiene empleados de esa nacionalidad, y tiene servidores en China, pero también en USA y seguramente otras partes del mundo, y está obligado a cumplir con las regulaciones y leyes de esas naciones. En esto no es diferente de otras empresas, como Microsoft, Google o Amazon. Sobre esto no puede ni podemos hacer mucho, salvo buscar por medios democráticos que las legislaciones cambien y protegan nuestra vida privada.

El artículo en ⁶ aborda varios de estos puntos, no me extenderé mucho en este aspecto. Pero la privacidad es algo importante, y debes revisar siempre los términos de servicio antes de usarlo. Si no te satisfacen, o sientes que la empresa que presta el servicio no te entrega confianza, bueno, la decisión es tuya. Haz una análisis de riesgo y pon en la balanza tus necesidades versus lo que te ofrece y te restringe la herramienta que vas a usar. Pero si vas a partir con un NO a priori, sin analizar, puede que estés perdiendo oportunidades por culpa de una visión paraonica.

Reflexiones finales

How do I, how am I
Gonna get to sleep
Trust me, trust me….
– Paranoimia, The Art of Noise

Para terminar quiero hacer algunos comentarios a propósito de la sobre reacción sobre la seguridad de Zoom.

Me llama la atención lo rápido que escaló la paranoia con Zoom, por ejemplo, la página en español de Wikipedia sobre Zoom parte enumerando la información que Zoom recopila, perdiendo la objetividad que debería caracterizarla. Claramente hay una edición sesgada ahí.

Hay una serie de influencers que han propuesto soluciones muy malas. He visto Tweets que promueven usar alternativas al voleo, sin análisis comparativo de riesgos y usabilidad.

¿Sabemos si Zoom es más seguro que Microsoft Teams, o Slack, o Google Meet? ¿Hay comparativas? ¿Hacemos comparativas antes de elegir una herramienta?

Se ha planteado el uso de una herramienta opensource: Jitsi Meet, pero es una solución que aún tiene problemas de usabilidad y seguridad, por ejemplo, cualquiera con la URL de una conferencia en Jitsi puede ingresar a esta, lo que permite el fenómeno del bombing, o simplemente espiar la conversación. Otro ejemplo un issue sobre un XSS que no está claro si ha sido resuelto por esta plataforma: https://community.jitsi.org/t/xss-injection-on-jitsi-meet/15336/11. Si bien puedes crear tus propios servidores Jitsi, lo probé y requiere bastante configuración y las opciones que vienen fuera de la caja no son suficientemente seguras aún.

Creo que lo que falta en el caso de Zoom es más análisis de escenarios de riesgo y gestión, hay mucha crítica, mucha paranoia, pero poco análisis.

Zoom ha sido exitoso en muy corto tiempo, y es un objetivo de muchos millones de dólares, así que será blanco de ataques de juaquers, ciber delincuentes, abogados en busca de dinero de acciones civiles, y de bloggers aficionados al clickbait. Las ONG y los gobiernos le exigirán cambios a sus políticas de seguridad y los expertos de ciber seguridad estarán atentos a que se corrijan los fallos y se mejoren los protocolos. Creo que si Zoom sigue con la actitud que ha mostrado hasta ahora, logrará robustecerse.

Recuerdo el caso de Microsoft, establecieron una política estricta de ciberseguridad y mejoraron en robustecer sus productos. Zoom ha respondido rápido, ha establecido mitigaciones rápidas y estableció un freeze de desarrollo de 90 días para corregir fallos de seguridad⁷, esto es lo que deben considerar también en su análisis de riesgo.

Personalmente creo que se puede usar Zoom con tranquilidad, pero, si están compartiendo cosas muy confidenciales problamente no sea la plataforma adecuada.

Pero les cuento algo, no sé, ni tengo modo de saber, si hay una alternativa que sea más segura que Zoom. Y los expertos en seguridad serios tampoco pueden garantizar nada al respecto.

Así que hay que gestionar riesgos, asumirlos, tomar medidas mitigatorias e ir midiendo, observando y estando al día de lo que ocurre.

Por ahora, relájense con Zoom, ellos se están haciendo cargo, hay cosas más importantes que nos deberían quitar el sueño.

Do what you think is interesting, do something that you think is fun and worthwhile, because otherwise you won’t do it well anyway. – Brian Kernighan

Unix es el sistema operativo más exitoso de la historia. Una variante de Unix se encuentra disponible en casi todos los dispositivos que se conectan a internet hoy.

En efecto, si usas un teléfono Android usas como base el Kernel de Linux, por otro lado si tu teléfono es un iPhone estás usando iOS, que tiene como base un kernel XNU. Ambos pertenecen a la familia de Unix.

Por otro lado, es muy probable que los servicios en internet a los que accedes sean soportados por servidores operando alguna variante de Unix o de Linux.

¿Cómo podemos explicar este éxito?

Una forma es indagar en lo que nos cuenta una de las personas que estuvo involucrada en la creación de Unix.

Brian Kernighan

La historia de Unix ha sido contada muchas veces, pero en octubre del año pasado se publicó una fuente definitiva del origen de este exitoso sistema operativo, relatada por alguien que estuvo involucrado directamente en su creación: Brian Kernighan.

Este investigador y pionero informático es reconocido, entre otras cosas, por su gran habilidad como divulgador y escritor.

Kernighan tiene una gran pluma y entre sus libros más vendidos se encuentra “The C Programming Language”, que fue el que introdujo este importnate lenguaje de programación al mundo. Este trabajo fue co-escrito con el creador del lenguaje, Dennis Ritchie, y es uno de los mejores libros técnicos que he leido personalmente, además de serconsiderado un verdadero clásico.

Es en este libro que se introduce al mundo el famoso programa “Hello World”

main( ) {
        printf("hello, world\n");
}

Hay que notar que este programa aparece por primera vez en un memorandum interno de Bell Labs de 1974, escrito por el mismo Kernighan, titulado: “Programming in C: A Tutorial”. Hoy es una tradición el presentar un nuevo lenguaje de programación con este programa, y es también una buena práctica ejecutarlo la primera vez que probamos un nuevo lenguaje o entorno de programación.

Otro de los libros escritos por Kernighan, que siempre recomiendo a los nuevos programadores, es The Practice of Programming.

Pero hablemos de “UNIX: A History and a Memoir”, un texto publicado en octubre de 2019. Se trata de una memoria personal del autor sobre sus años en Bell Labs y el origen y la evolución de de Unix.

Unix: A History and a Memoir

Hay varias anécdotas interesantes en este volumen. Se trata de un texto entretenido de lectura rápida, de no más de 190 páginas.

En los primeros capítulos el autor nos introduce a Bell Labs y su cultura. Tal como el escritor dice, para entender Unix hay que entender a Bell Labs, cómo operaba y el ambiente creativo que este entorno proveía.

Bell Labs

Fundado en 1925, los Laboratorios Bell fueron creados para fomentar la innovación en telefonía a través de la investigación científica. Durante la Segunda Guerra Mundial, Bell Labs prestó importantes aportes al gobierno norteamericano, no sólo en sistemas de comunicaciones, sino que en computadores de control de fuego, desarrollo del radar y criptografía.

En Bell Labs, por ejemplo, se desarrolló el transistor, un invento de John Bardeen, quien recibiría el premio Nobel por este descubrimiento.

Otros ganadores del Nobel, que trabajaron en Bell Labs fueron Penzias y Wilson, quienes descubrieron accidentalmente la radiación de fondo generada por el Big Bang, trabajando en la mejora de antenas de telecomunicaciones.

Durante mucho tiempo AT&T, la empresa propietaria de Bell Labs, llegó a invertir el 2.8% de sus ingresos en investigación y desarrollo. De eso, el 0.3% se invertía en investigación básica. Esta inversión estable le daba libertad a los científicos contratados, que podían hacer investigación en áreas que no necesariamente reportaran beneficios de corto plazo, incluso en investigaciones que nunca tuvieran una aplicación práctica.

Computación en Bell Labs

Entre los investigadores que destacaron en Bell Labs estaba Claude Shannon, el padre de la Teoría de la Información (del que he hablado antes).

A principio de la década de 1960 se creó un grupo de investigación en computación. Y en 1967 Brian Kernighan se incorporó al Computing Science Research Center, bajo la guía de Doug McIlroy.

Kernighan cuenta que tenía la suerte de estar muy cerca de varios próceres de área que tenían sus oficinas muy cerca a la suya. Entre los famosos investigadores que trabajaban en esa época estaba Richard Hamming, autor, entre otras cosas, del famoso código de corrección de errores que lleva su nombre, que permite que tengamos comunicaciones confiables de alta velocidad.

Fue Hamming quien impulsó a Kernighan a escribir. Para Hamming el entrenamiento de los programadores era deficiente, según el autor, expresaba su opinión sobre la capacidad de los programadores con la siguiente frase:

We give them a dictionary and grammar rules, and we say, ‘Kid, you’re now a great programmer.'

Para Hamming la programación debería ser enseñada del mismo modo que se enseña la escritura. Debería existir una noción de estilo que separe el código bueno del código malo, y a los programadores se les debería enseñar a escribir bien y a apreciar el buen estilo.

Esta idea sirvió de incepción para el libro que Kernighan y Plauger publicaron en 1974: “The Elements of Programming Style”.

Sistemas Operativos

Una computadora no es mucho más que una calculadora. Lo que ocurre es que son capaces de ejecutar millones de operaciones aritméticas por segundo.

Programar consiste en crear una secuencia de operaciones que ejecutará la computadora, usando lo que llamamos un lenguaje de programación. Por ejemplo, si queremos calcular el promedio de notas de un curso, un posible algoritmo sería:

1. Reserva una sección de la memoria que llamaremos ACUMULADOR
2. Cargar la nota de un alumno en una variable que llamaremos NOTA
3. Suma el valor de NOTA en ACUMULADOR
4. Incrementa un contador N en 1
5. Repite los pasos 2 al 3 hasta que no queden más notas que leer
6. Divide ACUMULADOR en N y almacenalo en PROMEDIO
7. Imprime el valor PROMEDIO.

Esto debía ser expresado en un lenguaje entendible por la máquina algo como esto:

      dword acum
      dword nota
      dword n
      set acum 0
      set nota 0
      set n 0
  loop:
      load nota
      jz end
      add acum nota
      store acum
      inc n
      jmp loop
  end:
      div acum n
      print

En los primeros computadores esto se transcribía a tarjetas perforadas como la de la figura:

Típicamente cada tarjeta contenía una linea de código. También en estas tarjetas se almacenaban los datos. En nuestro ejemplo, si habían 100 alumnos, habría una tarjeta por cada dato. Estas tarjetas se entregaban a un operador quien cargaba tanto el programa como los datos en un lector de tarjetas, esta máquina se encargaba de leer las tarjetas y almacenarlas en la memoria del computador. Después el operador ejecutaba el programa, y el resultado normalmente quedaba impreso en papel. Después de un tiempo el programador pasaba a retirar el resultado solicitándoselo al operador.

Como pueden ver, esta forma de trabajar obligaba a que sólo un usuario podía ocupar el computador a la vez. A esta modalidad se le llama “batch processing”.

Por otro lado, cuando automatizamos esta labor aparece el concepto de Sistema Operativo. En cierta manera, el sistema operativo es el reemplazo del operador humano.

En 1964 uno de los sistemas operativos más innovadores era CTSS: “Compatible Time Sharing System”, desarrollado en el MIT.

En este sistema no era necesario usar tarjetas perforadas. Los programadores podían tipear sus programas en terminales que estaban conectados directamente, o por líneas telefónicas a un gran computador, el IBM 7094.

El sistema operativo dividía su atención entre los usuarios conectados, cambiando rápidamente de un usuario activo al otro, dando a cada usuario la ilusión de que tenía el computador a su entera disposición. Esto se denominó “time sharing” (tiempo compartido), y era percibido en esa época como mucho más agradable y productivo que el batch processing.

CTSS fue tan exitoso y productivo que en 1965 el MIT decidió crear una versión mejorada que llamaron Multics, por Multiplexed Information and Computing Service.

MULTICS

Multics sería un trabajo de gran envergadura, que requería la construcción de software bastante ambiciosos y del hardware que lo soportara. Así que el MIT llegó a un acuerdo con General Electric y Bell Labs, para apoyarlos en el proyecto.

El proyecto era demasiado ambicioso y cayó en el “efecto del segundo sistema”, una trampa en que se pretenden arreglar todos los problemas del primer sistema, pero además incorporar las características favoritas de cada uno. El resultado es a menudo un sistema demasiado complicado con sobre ingeniería. En palabras de Sam Morgan fue un intento de “trepar demasiados árboles a la vez”¹.

Media docena de investigadores de Bell Labs trabajaron en Multics, incluyendo a Doug McIlroy, Dennis Ritchie, Ken Thompson y Peter Neumann.

McIlroy estaba involucrado en el desarrollo del lenguaje PL/I que se usó para programar el sistema operativo. Ritchie, que era un estudiante recién egresado de Harvard, trabajó en los laboratorios en los subsistemas de entrada y salida, al igual que Thompson.

Thompson describió su trabajo en Multic como “una muesca en una enorme rueda y estaba produciendo algo que yo no quería usar”².

En 1969 Bell Labs decide retirar su apoyo al proyecto.

Multics fue finalizado eventualmente. De acuerdo a Kernighan fue usado y soportado hasta el año 2000.

De todas maneras fue la fuente de varias ideas y una influencia, aunque sea por reacción, en la creación de Unix.

Proto Unix

Después de la salida de Bell Labs del proyecto Multics, varios de los investigadores aún querían desarrollar un sistema operativo. Pero la administración no quería saber más de un proyecto de este tipo y no tenía interés en comprar hardware especial para una aventura como esta.

Uno de los más entusiasmados en continuar era Ken Thompson, quien compartía con otros colegas ideas en papel de posibles implementaciones.

Eventualmente Ken encontró un computador con poco uso, se trataba de un DEC PDP-7.

Este era un computador construido en 1964 y en esa época ya se consideraba obsoleto, razón por la cual Thompson pudo disponer varias horas del mismo. Era una máquina con poca potencia, poseía una memoria de 16K bytes actuales (estaba organizada como 8K words de 18 bits).

El computador tenía una buena pantalla gráfica, y Thompson escribió un juego de viaje espacial para esta máquina.

El PDP-7 tenía un periférico que representaba un desafío interesante. Se trataba de un disco cuya velocidad de rotación era demasiado rápida para el computador. Así que Ken Thompson desarrolló un algoritmo que maximizara el througput de cualquier disco, incluyendo este en particular.

Pero para probar el algoritmo tenía que desarrollar un programa que llenara el disco con una gran cantidad de datos. Fue entonces que Thompson se dio cuenta que estaba a tres semanas de completar un sistema operativo.

El necesitaba crear tres programas, uno por semana: un editor, de modo que pudiera crear código, un ensamblador que pudiera convertir el código en lenguaje de máquina que corriera en el PDP-7, y un kernel, es decir un sistema operativo.

Justo en esa época la esposa de Thompson se tomó unas vacaciones de tres semanas, llevando al hijo de un año de ambos a visitar a sus abuelos paternos en California. Así que Ken tuvo tres semanas para dedicarlas para trabajar ininiterrumpidamente en este proyecto.

Esta historia se puede ver en una entrevista que Kernighan le hizo a Thomposon en mayo de 2019:

En 2003 Kernighan le preguntó via email sobre el origen de Unix a Thompson, y este respondió lo siguiente:

Lo que demuestra la consistencia de la historia.

Unix

Y a partir del trabajo de Thompson se forma un pequeño grupo de usuarios dentro de Bell Labs de este proto sistema operativo. Se dice que el nombre UNICS surgió de estas conversaciones, y se suele atribuir el nombre a Kernighan, y sería una suerte de juego de palabras y parodia a MULTICS.

Mientras MULTICS sería “Mucho de Algo”, UNICS significa a lo más “uno de algo”, es decir, usar uni, en vez de multi. Otro rumor es que a los abogados de AT&T no les gustó la palabra UNICS por ser fonéticamente similar a Eunucs (eunucos) en inglés. Así que eventualmente se volvió UNIX. Como sea el nombre era una parodia a Multics, como apuntó Dennis Ritchie.

Después del éxito del sistema en el PDP-7, Ritchie y Thompson empezaron a hacer lobby para que se aprobara la compra de un PDP-10, un computador más poderoso. El PDP-10 tenía un costo de 500.000 dólares y su compra fue rechazada por la administración.

Pero DEC anunció la disponibilidad de un mini computador, el PDP-11 con un costo de 65.000 dólares. Así que el equipo solicitó la adquisición del modelo más barato, la que también fue rechazada.

En ¹ Sam Morgan expresa:

El principio de administración acá es que contratas gente brillante y los introduces al ambiente, y les das direcciones generales del tipo de cosas que se requieren, y les das un montón de libertad. Esto no significa que necesariamente le das todo el dinero que ellos quieran. Entonces ejercitas entusiasmo selectivo sobre lo que hacen. Y si equivocadamente desalientas o fallas en responder a algo que posteriormente resulta ser bueno, si es realmente una idea fuerte volverá.

El estar forzado a trabajar con restricciones puede ser bueno. En su charla al recibir el premio Turing en 1983 Ken Thompson escribió:

Unix barrió en popularidad con el cambio a lo largo de la industria desde mainframes centralizados a minis autónomos. Sospecho que Daniel Bobrow³ estaría acá en vez de yo si él no hubiera tenido recursos para un PDP-10 y haberse conformado con un PDP-11.

La forma en que lograron la aprobación fue totalmente lateral.

Bell Labs elaboraba una enorme cantidad de patentes al año. Las que debían ser presentadas en un formato estandarizado con páginas con líneas numeradas. No existían sistemas en esa época que permitiera manejar este tipo de formatos. Así que el departamente de patentes estaba dispuesto a comprar hardware especial para eficientar su operación.

Joe Ossana propuso que el departamento de patentes compara la PDP-11 y el grupo Unix escribiría el software necesario para que ellos pudieran imprimir las aplicaciones de patentes en el formato requerido. Por supuesto nadie escribiría un sistema operativo, no señor 😉.

Esta propuesta tuvo apoyo del centro de investigación acústica, que estaban interesados en aplicaciones de procesamiento de textos.

Así que la PDP-11 fue comprada, una máquina con 24 Kbytes de memoria principal y un disco con medio megabyte de capacidad.

Ken Thompson y Dennis Ritchie tradujeron y adaptaron el kernel de la PDP-7 a la PDP-11. Este kernel consumía 16 Kbytes de memoria, quedando 8 Kbytes para los programas de los usuarios.

Ossana escribió un programa llamado nroff (“New roff”), análogo al existente program Roff que se usaba para generar los archivos en el formato requerido para las patentes.

Hacia la mitad de 1971 se estaba usando Unix para generar las patentes de Bell Labs diariamente.

La experiencia fue tan exitosa que el departamento de patentes compró otro PDP-11 para que el equipo de Unix mejorara el sistema operativo.

El entorno Unix

Unix fue creciendo poco a poco mediante la colaboración de varios investigadores de Bell Labs.

Una de las innovaciones más importantes fue el concepto de pipes.

En 1964 Doug McIlroy propuso la idea de que se deberían conectar programas tal como se enganchan las mangueras de jardin.

Unix tenía la característica que la entrada y salida de cada programa ya estaba estandarizada. Por otro lado McIlroy le insistía a Thompson con la idea de estos conectores de mangueras, hasta que un día a Ken se le ocurre incorporar una llamada adicional al sistema, la que resultó bastante simple, dado que el mecanismo estándar ya existía. Esto es lo que se conoce como pipes (tuberías).

Un ejemplo es la siguiente sentencia, que sirve para saber cuantos archivos hay en un directorio:

ls | wc 

ls es un comando que lista los archivos, uno por linea. wc (word count) es un programa que cuenta lineas.

El pipe se expresa con la barra vertical |, y lo que esta expresión dice es que el resultado de ls debe ser pasado al programa wc como entrada.

El potencial de esto permitió la cultura de Unix de crear muchos pequeños programas especializados en sólo una cosa a la vez, los que podían usarse para componer operaciones más complejas.

Para facilitar la mantención del sistema Dennis Ritchie construyó el lenguaje C. Pero junto con esto se incorporó una biblioteca estándar, la que permitía acceder a los servicios del sistema operativo.

Contando con C otros pudieron aportar con mini lenguajes, o lenguajes de scripting, como sh, o bash. El mismo Kernighan junto a Al Aho y Peter Weinberger crearon el lenguaje AWK que permite operar sobre patrones.

En 1973, Steve Johnson y Al Aho crearon Yacc, un programa que facilita la creación de compiladores. Esto permitió que florecieran aún más lenguajes específicos dentro del entorno Unix lo que lo fue enriqueciendo.

Dado que Unix fue “vendido” como un proyecto para apoyar la generación de documentos, desde el principio contó con muchos programa de procesamiento de texto, como roff y nroff, posteriormente con la adquisición de una máquina de foto composición tipográfica, se creó troff.

En 1974 Lorinda Cherry creó el lenguaje Eqn, usando Yacc que permite escribir ecuaciones matemáticas. Este programa fue inspiración para el trabajo posterior de Donald Knuth en TeX de 1978.

De este modo, cuando alguien preparaba un texto con ecuaciones matemáticas podía hacer lo siguiente en Unix:

eqn archivo | troff > typesett.output

Todos estos lenguajes son como antepasados de los actuales lenguajes de markup, como Markdown que uso para escribir este blog.

La distribución de Unix

Toda esta explosión de lenguajes, comandos y utilitarios hizo de Unix un sistema útil y popular.

Además Unix fue distribuido en forma gratuita a las universidades, bajo un simple convenio. Este convenio incluía el acceso al código fuente del mismo. Esto permitió la elaboración de otras versiones derivadadas, como BSD Unix.

Esto permitió que el sistema se difundiera en entornos comerciales, pues los graduados de informática querían seguir usando el mismo entorno que usaron mientras estudiaban.

Pero lo principal era la facilidad e innovación que giraba alrededor de Unix. Una cultura libre que se fue perdiendo con los avatares que sufrió AT&T en la década de 1980.

Finalmente Unix fue vendido a Novell en 1992, la que posteriormente la vendió a SCO.

Pero Unix sobrevió en forma de múltiples derivados, como BSD, Minix y el más popular Linux.

La figura que encabeza este post muestra esta especie de árbol genealógico de Unix.

Peor es mejor

En 1989 Richard P. Gabriel en su artículo The Rise of Worse is Better explica el éxito de la filosofía de Unix

En el ensayo Richard Gabriel plantea que existe un estilo de diseño de software que el denomina el estilo MIT/Stanford (es decir, un estilo académico) que básicamente tiene las siguientes características:

• Simplicidad: el diseño debe ser simple, tanto en implementación como interfaz. Es más importante que la interfaz sea simple que la implementación.
• Correctitud: el diseño debe ser correcto en todos los aspectos observables. La incorrectitud simplemente no está permitida.
• Consistencia: el diseño no puede ser inconsistente. Se permite que un diseño sea ligeramente menos simple y menos completo para evitar incosistencia. La consistencia es tan importante como la correctitud.
• Completitud: el diseño debe cubrir tantas situaciones importantes como sea práctico. Todos los casos razonablemente esperados deben estar cubiertos. A la simplicidad no se permite reducir excesivamente la completitud.

Como ven estas son características que se consideran buenas y positivas.

Por otro lado, la filosofía Worse Is Better, Peor es mejor, o estilo New Jersey, en referencia a los Bell Labs, la cuna de C y Unix es ligeramente diferente en los siguientes aspectos:

• Simplicidad: el diseño debe ser simple,tanto en implementación como interfaz. Es más importante que la implementación sea simplea que la interfaz. La simpliciddad es la consideración más importante en el diseño.
• Correctitud: el diseño debe ser correcto en todos los aspectos observables. Es ligeramente mejor ser simple que correcto.
• Consistencia: el diseño no debe ser demasiado incosistente. La consistencia puede ser sacrificada por la simplicidad en algunos casos, pero es mejor eliminar partes del diseño que tienen que ver con circunstancias menos comunes que introducir complejidad en la implementación o inconsistencias.
• Completitud: el diseño debe cubrir tantas situaciones importantes como sea práctico. Todos los casos razonablemente esperados deben estar cubierntos. La completitud puede ser sacrificada en favor de cualquier otra cualidad.

De hecho, la completitud puede ser sacrificada siempre que la simplicidad de implementación esté amenazada. La consistencia puede ser sacrificada para alcanzar completitud si se mantiene la simplicidad, especialmente la inconsistencia de la interfaz no tiene valor.

Para mi esto se traduce en construir servicios, lenguajes, o programas simples que hagan bien una cosa, y disponer esto dentro de un entorno en que puedan acoplarse de una manera sencilla para brindar nuevos servicios más complejos.

Súmenle esto al precepto de administración de “entusiasmo selectivo”, en que cuentas con equipos brillantes que son libres de innovar dentro de ciertas restricciones, y tendrás un entorno de innovación tan exitoso como lo fue Bell Labs en las décadas de 1960 y 1970.

“Esta es una noche para recordar… ella es el comienzo de siempre” – Dante

Veintinueve de febrero. Cada cuatro años agregamos este día especial especial para poder ajustar nuestros calendarios y asegurar que las estaciones empiecen cuando se supone que deben.

Es casi seguro que más de algún sistema informático ha fallado por manejar mal esta fecha.

El tiempo es, de muchas formas, una mera convención. La órbita de la tierra alrededor del sol no toma 365 días, ni tampoco el día 24 horas. Podrían ser cualquier valor arbitrario. Nos reconforta tener estas convenciones. Los meses, los días, nos ordenan.

Aprovechemos entonces este día extra, para ordenarnos y marcar un nuevo inicio para este blog.

Rutina

Steven Wilson escribe en Routine:

Routine keeps me in line Helps me pass the time Concentrate my mind Helps me to sleep

La rutina dice que el verano se acaba, llega el otoño. El año empieza en Chile en marzo. Todo se reactiva. Las clases comienzan, la gente vuelve de vacaciones.

Pero hay épocas en que esta rutina se rompe. Y este 2020 no será para nada rutinario en Chile.

Motivación

“Quien sabe de dolor todo lo sabe” – Dante

Y si la rutina, que nos ordena, que concentra nuestra mente, se pierde, ¿qué podemos hacer?

Me ha costado volver a escribir con periodicidad en este blog.

Por mientras, estos últimos tres meses he dedicado parte de mi tiempo a migrar de plataforma todo el contenido escrito en estos últimos quince años. En este proceso he vuelto a leer muchos de esos escritos, y he descubierto cosas sobre mi mismo en el proceso. Algunas fueron sorpresas agradables, otras no me gustaron para nada.

En 2006 escribí:

Hace mucho que no escribo en este blog, ya casi dos meses. Es que no siempre estamos motivados, o tenemos problemas, o simplemente nos falta tiempo.

Según la RAE la motivación es “un ensayo mental preparatorio de una acción para animar o animarse a ejecutarla con interés y diligencia”.

Sin motivación, es muy dificil que podamos hacer algo bien, o con interés. Entonces la motivación es muy importante para que podamos “funcionar” como personas.

Así cada uno busca un objetivo, y con este en mente se motiva para realizar alguna acción, con interés y diligencia. Muchos de los que escribimos bitácoras, lo hacemos más por vanidad, que por otra cosa. Sentimos que tenemos algo valioso que aportar y lo escribimos.

Como sea, hay momentos en que no encontramos motivación en lo que hacemos, ni en nada de lo que nos rodea. Es en esos momentos donde necesitamos ayuda, apoyo, paciencia, y también un remezón.

Necesitamos de esas personas que nos digan que estamos mal, o que manifiesten preocupación por nosotros. Que sepan remecernos, decirnos lo que está mal, que sean capaces de perdonarnos, a pesar de los errores que cometemos, pero que estén ahí para indicarte cuando te estas equivocando.

No es que quiera compartir con ustedes mis problemas, sólo quiero expresar que para los que no tenemos el don de la fe, existe en el amor una fuente para encontrar las energías necesarias para lograr la motivación. Y el amor surge del compartir con otros, aunque puedes amarte mucho a ti mismo, necesitamos recibir el amor de otros para poder vivir. En mi caso el amor de mi esposa, de mis hijos, amigos y familiares.

Un religioso me dirá que Dios es Amor, puede ser.

Lo importante es entrar en ese estado que te da la motivación. Esas ganas de emprender, trabajar, o hacer cualquier cosa. Ese estado que mejora tu concentración, te da más energías, que te permite decir que sí o que no dependiendo de lo que te pidan.

Si quiero escalar una montaña, debo motivarme para asumir el estado mental que me permitirá llegar a la cima. Pero queda claro que debe haber una montaña para escalar.

La motivación es importante, pero la motivación surge de las ganas, o la necesidad de hacer algo. Una meta, un objetivo.

Por otro lado, en febrero de 2019 escribí en mi Patreon sobre la “trampa de la motivación”.

“La motivación está sobrevalorada, lo importante es el compromiso: El compromiso te permite dar lo mejor cuando no estás motivado.” - Del muro de Facebook de Leonardo Jofré

El problema con motivar es qué es una forma de empujar a las personas a que hagan algo, que quizás no quieren hacer, porque no le encuentran sentido, o porque están interesados en otras cosas.

Crisis

“A la mitad del viaje de nuestra vida,
me encontré en una selva oscura
por haberme apartado del camino recto." – Dante, “La Divina Comedia”

En septiembre de 2019 tomé unas largas vacaciones por Europa, muchas ideas de artículos surgieron en esas semanas que compartí con mi mujer recorriendo el viejo mundo. Pero no vieron la luz. Llegamos a Chile justo dos semanas antes del estallido social. Pero aparte de ese aspecto externo, me enfrenté a los errores que cometí como lider de mi equipo. Vino una crisis, sobre la que hablaré de seguro más adelante.

La vida está llena de crisis, sociales o personales. La forma en que las enfrentamos y superamos es la que nos muestra quienes somos. Es la prueba suprema.

En 2006 atravesaba una crisis, a fines de 2019 también. Pero los contextos son distintos. Las formas de solucionarlas también.

Este es un año en que estaremos expectantes. Sólo nos queda tratar de hacer lo mejor en nuestro micro cosmos personal y aportar en el cosmos social.

Florencia

La raza humana se encuentra en la mejor situación cuando posee el más alto grado de libertad – Dante

En esas vacaciones que mencioné recién tuve la fortuna de visitar la casa del poeta florentino Dante Alighieri, uno de mis autores favoritos. Fue grande mi emoción, caminar por los escalones que el poeta pisó hace más de siete siglos. Conocer la capilla donde que su amada Beatrice Portinari visitaba (y donde ella se casó). Recorrer esas estrechas callecitas de Florencia.

Las palabras de Dante son inmortales. Porque Dante vivió tiempos complejos, de agitación política. Todos, si vivimos lo suficiente, enfrentaremos una época de grandes disturbios y conmoción social. Se neutral en esas épocas es cobardía moral, tal como nos recuerda Dante. Yo no soy neutral con lo que pasa en mi país, y en la medida que sea pertinente expresaré alguna opinión en este blog. No significa esto que cambiará el sentido de que acá se escribe.

Organizando la escritura

Aquel que escucha bien, toma apuntes – Dante

Desde 2010 mantengo tres blogs: “Akarrú”, “La Sombra de Dijkstra” y este “La Naturaleza del Software”.

En estas últimas semanas, para retomar el hábito, la rutina de la escritura, publiqué algunos desafíos en “La Sombra de Dijkstra”.

En Akarrú publiqué un pequeño homenaje a Neil Peart, tras su fallecimiento. Hace dos semanas agregué un pequeño relato de ciencia ficción.

Poco a poco retomaré la rutina de escribir posts en este blog, a veces un aforismo, de vez en cuando un largo y documentado artículo técnico. Mis reflexiones más personale irán a “Akarrú”, todo lo que tenga que ver con tecnología, reflexiones sobre el arte de desarrollar software, y alguna que otra reflexión de tipo epistemológico, irán acá. Por último todo lo que tenga que ver con programación y arquitectura de software será publicado en “La Sombra de Dijkstra”.

Empieza una nueva jornada

“Incipit Vita Nova”

Cuando Dante desciende a los infiernos consigue la compañía de Virgilio, que lo orienta dentro de los círculos que componen el infra mundo, y que le explica lo que ve. Al ascender al cielo, la anfitriona es su amada Beatrice.

El Vate Florentino transmite en su obra su larga reflexión sobre su propio crecimiento moral y ético, critica y nos transmite en modo alegórico las crisis que le tocó observar. Es un testigo de su tiempo y nos deja un relato de las bajezas y grandezas humanas que le toca observar.

Estoy al inicio de una nueva jornada. Un reinicio donde me acompañan nuevos aliados. Hay ciclos que se cumplen, y necesitas formar nuevos equipos para asumir nuevos desafíos. Contextos diferentes.

Contra la rutina

“Un poderoso fuego es solo la continuación de una pequeña chispa” – Dante

La rutina no nos ordena. No calma nuestra mente. La canción homónima de Steven Wilson habla desde la perspectiva de una persona atormentada, que se refugia en la rutina porque le cuesta aceptar la terrible realidad a la que se vio expuesta.

No es que me guste la rutina, aunque sí soy amigo de tener cierta disciplina, ritmo y rito para trabajar y abordar mi vida.

Descubrí que en los primeros años de este blog habia un ritmo asombroso de publicación, aunque el contenido muchas veces era bastante pobre. En esa época los blogs eran la tendencia en “social media”. Hoy usamos las redes sociales. Así que ahí volcamos mucho del contenido contingente. Pero en el 2005, o el 2006, era normal que se usaran los blogs para discutir sobre la coyuntura nacional.

Objetivos

“El secreto para que las cosas sean hechas está en hacerlas” – Dante

Hoy hay muchas personas que usan Medium para publicar posts más extensos, para superar la barrera del espacio que imponen las redes sociales. Pero también ocurre que hay mucho contenido que es pura vanidad, o venta de humo.

No es el objetivo de este blog, al menos no en esta época o contexto. Lo que yo espero aportar es contenido de calidad, desde mi experiencia, mi nivel de conocimiento. También uso este medio como un mecanismo para aprender, y mejorar. Cuando descubro algo me gusta expplicarlo para asegurarme que lo entiendo. Ese es objetivo principal de “La Naturaleza del Software”, ese es el compromiso final. Es la idea que se mantendrá vigente en estos textos que vendrán. Vamos a avanzar.

Recordemos a Dante, “el secreto para que las cosas sean hechas, es hacerlas”. Así que acá estamos de nuevo. Vamos a volver a escribir.

Ritmo y Rito.

Una palabra tras otra, una idea y después la siguiente.

(*) Todas las fotos tomadas por el autor

Two Steps Back
One Leap Forward
– Earthrise, Haken

El décimo cuarto año no terminó muy bien. No voy a entrar en detalles ahora. ¿Para qué?

Supongo que para muchos de ustedes fue igual. Hay lecciones que tomar con calma. Aún hay procesos que están sucediendo.

Es fuerte cuando el tejido social que estaba deshilachado se termina desarmando completamente. Porque te das cuenta que esa red que nos sostenía a todos no solo ya no está, sino que estaba sostenida por débiles hebras. ¿Qué puedes hacer?

Lo que te mantiene vital, lo que se convierte en los pilares fuertes que sostienen tu vida son tu familia, tus amigos, y las personas que te quieren.

Resolve to carry on!
Another life awaits beyond the horizon.
Evolve and we’ll ensure our survival.
We are the revolution!
– Earthrise, Haken

Hay veces que es mejor retroceder para poder tomar otro camino, porque el que tomaste era el incorrecto, o el inadecuado para el momento.

Marcha atrás, con cuidado mirando el retrovisor, y viras hacia el otro lado.

O como dice una canción de Haken, dar dos pasos atrás para brincar hacia adelante.

Por meses no he escrito en este blog, ya irán sabiendo algunas causas, pero ya es momento de retomar la voz. Decir lo que tengo que decir. Seguir aportando.

La Naturaleza del Software cumple quince años en agosto de este año, y vale la pena seguir escribiendo.

Notarán que la casa está cambiando. Estoy remodelando. Migrando el contenido a una nueva plataforma, así que algunas cosas estarán desaparecidas por algunos días.

Keep reaching through horizons,
to leave our past behind us.
We turn toward the earthrise!
– Earthrise, Haken

He retomado también mis otros blogs, en estos meses he escrito algunas cosas en La Sombra de Dijkstra, y en Akarrú. Los invito a visitar esos sitios que complementan a este en otros aspectos de mis gustos y aficiones.

Además los invito a sumarse como auspiciadores a través de Patreon. Si quieres apoyar mi trabajo en este blog y los otros blogs que publico, es una de las formas. Hace tiempo decidí dejar de poner publicidad en este blog, pero mantenerlo tiene costos que espero poder solventar con el apoyo de ustedes.

Hay un proyecto que estoy preparando que verá la luz pronto en este espacio. Espero que les guste.

El decimo quinto año presenta grandes desafíos, pero no soy de los que esquiva los desafíos. Veamos que nos depara el 2020.

Pero como la música siempre ha sido parte de este blog, partiremos con una canción que nos de una dosis de merecido optimismo.

“A good drummer listens as much as he plays."
— Proverbio Indio

Como les conté antes, en la segunda mitad de los noventa, con mis amigos volvimos a ensayar como grupo musical. En esa época yo invertí en una batería y compraba cada cierto tiempo algún ejemplar de la revista Modern Drummer. A diferencia de hoy, en que encuentras en YouTube miles de tutoriales, en esa época recurrías a material escrito para aprender nuevas técnicas o mejorar como músico aficionado.

Fue en uno de esas ediciones que leí una entrevista a Neil Peart, el baterista de Rush, quien contaba como había vuelto a estudiar con el maestro Freddie Gruber. 

La historia de Gubber es azarosa, pudo haber sido uno de los grandes bateristas del jazz, pero su adicción a la heroína lo alejó del camino del éxito. Con la ayuda de sus amigos, entre ellos el gran Buddy Rich, Freddie pudo recuperarse y encontrar su verdadera vocación en la enseñanza.

Grubber enseñaba todos los aspectos de tocar la batería, pero su verdadero regalo, en palabras de Neil Peart, su discípulo más famoso, era *“un entendimiento sin paralelos de la ‘danza’ física involucrada al tocar el instrumento, la relación ergonómica entre el baterista y la batería” *(tomen nota de esto porque es importante).

A fines de 2015, como relaté en la parte 11, estábamos en crisis. Ese mismo año, en la StartechConf, presenté una charla que titulé “El viaje del agente de cambio”, donde reflexioné sobre mi intento por cambiar como persona y hacer cambios en mi organización. Pero había pecado de soberbia al tratar de llevar el cambio con pura voluntad y sin involucrar demasiado a mis colegas y a mis principales colaboradores. En cierta medida lo que contaba en esa charla era cierto sólo en teoría, no había sido efectivo. Así que debía hacerme cargo de la crisis y debía cambiar.

Empezar a hacerme cargo de las cosas que tanto Miguel, Carolina y  Elizabeth me habían dicho una y otra vez. Asumir, con humildad, que me faltaba mucho por aprender.

Así que, tal como lo hizo Neil Peart, quien siendo el mejor baterista del mundo fue a aprender para mejorar su técnica, yo también partí a estudiar.

Desaprender para aprender

“If the future's looking dark,
We're the ones who have to shine.
If there's no one in control,
We're the ones who draw the line.
Though we live in trying times,
We're the ones who have to try.
And we know that time has wings,
So we're the ones who have to fly."
― Neil Peart

Coincidió, porque no nos pusimos de acuerdo, que mis dos lugartenientes decidieron hacer lo mismo, y lo interesante es que estudiamos temas complementarios. Carolina decidió formarse como Coach Organizacional, y Elizabeth estudiar un diploma en Gestión de Calidad de Software.

Por mi parte decidí cerrar un ciclo personal. Cuando yo estaba en la universidad mi plan era salir con el título de ingeniero y magister. Pero no había completado ni uno ni el otro. Mil cosas pasaron en mi vida que hicieron que pospusiera mis estudios y así, sin darme cuenta, habían pasado más de veinte años. Esto no significó nunca cuestionamientos de mi capacidad laboral al buscar empleo. A fines de los ochenta y al inicio de los noventa muchos ingenieros en computación entramos a la industria en esta situación, nuestras habilidades eran requeridas y las ofertas laborales eran buenas.

Decidí que estudiaría el Magister en Tecnologías de Información de mi alma mater, la Universidad de Chile. Un programa que se ofrece para los profesionales de la industria. Mis hijos mayores ya dejaban la universidad, así que podía invertir en mi formación personal. También recibí algo de apoyo de mi empleador en esto, así que tenía sólo que poner de mi parte para sacar adelante estos estudios. 

Recuerdo que, cuando se cumplieron los 40 años de la fundación del departamento de computación de la Universidad de Chile, me invitaron a un cóctel en la facultad. Esa noche hablé con varios amigos y conocidos que eran académicos, o enseñaban en este u otros programas de extensión y educación continua. Fue en un momento que uno de ellos, quien me hizo clases después, me preguntó que ¿para qué hacía esto? Después de todo ya contaba con todos los conocimientos que se impartían en el programa. Pero yo quería cerrar el ciclo, y tener al menos un título y además enseñarles a mis hijos que todo debe cerrarse y terminarse como corresponde, aunque tome tiempo.

Al hacer los trámites de inscripción al programa de magister descubrí que mi universidad era generosa con sus ex alumnos y les permitía completar sus estudios, los que en mi caso, para ingeniería civil, era un ramo de ultimo semestre y la memoria, así que aproveché la oportunidad. dos año estudié para sacar mi carrera de ingeniero y el grado de magister.

El programa de la Universidad de Chile requiere tomar un par de diplomas e invertir una cantidad de horas para preparar la tesis. Pero yo aproveché el vuelo e  inscribí tres diplomas: “Gestión de Proyectos Informáticos”, “Ingeniería de Software” y “Ciencia e Ingeniería de Datos”, este último el más difícil, pero en dónde aprendí muchas cosas nuevas para mí.

Recomponiendo al equipo

En 2016 tomé algunos cursos de liderazgo y negociación. Fue ahí que fui reflexionando en la forma en que me relacionaba con mi equipo. También en ese tiempo hicimos diagnósticos de lo que nos había pasado y decidimos trabajar en mejorar la moral del equipo.

Sufrimos otro par de bajas, Natalia y José, que habían trabajado en un duro proyecto a fines de 2015 y principios de 2016. Ellos realmente habían caido en el burnout, uno de los males de nuestro tiempo. 

Empezamos a traer nueva y más gente para incorporar al equipo, fue ahí que llegaron Gerardo y Fabián. También llegaron miembros extranjeros a nuestro equipo, como Pedro y Johan. El fenómeno de la inmigración empezaba a aparecer en nuestro país en esa época, así que aparte de la diversidad de género que tratábamos de mantener, había que hacerse cargo de la diversidad cultural que implica incorporar gente de diversas nacionalidades.

Los cambios más importante ocurrieron en el área de Elizabeth. Con la partida de Gustavo y Contardo (ver parte 11), ese equipo corría el riesgo de colapsar. Hicimos muchos cambios y logramos mejorar la productividad de ese grupo a pesar de tanto cambio.

Una de las primeras cosas que hicimos fue hablar con Gabriel Ovalle, quien en ese entonces era jefe de sistemas, hicimos un análisis de todas las incidencias que generaban solicitudes desde el área de procesos que se traducían en labores de explotación de datos, lo que consumía mucho tiempo del equipo. Descubrimos que habían muchas solicitudes tenían un origen histórico, los usuarios las hacían porque hubo un tiempo en que no existían funcionalidades en los sistemas para resolver esos problemas, pero la verdad es que ya se habían resuelto, el problema era que no sabían que existían o al haber rotación de personal se perdía el conocimiento. Corregimos eso, capacitamos, desarrollamos algunas funcionalidades nuevas, o corregimos errores. Redujimos varios incidentes también automatizando algunas tareas. Y dejamos un montón de labores de explotación de datos en el equipo de DBAs que dependían de Gabriel.

Pusimos énfasis en la integración continua, fue ahí que Jonathan Peña y Lillo, quien era analista de calidad hasta ese momento, tomó la posta del trabajo que había empezado Gustavo e implantó definitivamente un proceso de integración continua para que nuestros desarrolladores dejaran de entregar piezas binarias para instalar. Ahora por fin teníamos un ciclo en que las piezas a entregar a producción se generaban de manera automática a partir del repositorio de código fuente.

Recuerdo el día en que me mostraron el primer pipeline de integración continua implantado en Bamboo. Realmente me emocioné, lo que había visto en Borland en 1998, y en Boston en 2011, por fin estaba tomando forma en mi área. Me sentí orgulloso de ellos.

A fines de 2015 se había incorporado Claudio Araya, como ingeniero de sistemas, a cargo de mantener la infraestructura de nuestros ambientes de desarrollo y calidad. Pero además de sus capacidades técnicas, lo que buscábamos en ese tiempo, era gente con ganas de aprender, con una actitud positiva, gente alegre que cambiara la moral del equipo, que lo empujara hacía arriba. En ese sentido Claudio es y sigue siendo, un pilar importante de mantener la actitud del equipo. Uno de los líderes positivos de mi unidad.

En 2016 también apareció el programa “Mujeres Programadoras”, de la fundación Kodea. Le dimos la oportunidad de realizar práctica con nuestro equipo a dos de las alumnas del proceso, Natalia y Camila. Finalmente decidimos incorporar a Camila Donoso al equipo de QA. Ella fue una de las pionera en un cambio importante que hicimos al proceso de control de calidad: incorporar la programación y así fue que empezamos a crear pruebas automatizadas, usando Selenium y Python en nuestro proceso. Pero se incorporaron otras técnicas que permitieron cambiar el estilo de hacer las pruebas. Gradualmente el equipo de Elizabeth empezaba a incorporar DevOps a nuestra organización.

Ritmo y Rito

“Rhythm is the soul of life. The whole universe revolves in rhythm. Every thing and every human action revolves in rhythm.”
–― Baba Tunji

Fue en la clase de ingeniería de software que conocí a Daniel Perovich, quien después se convertiría en mi profesor guía de tesis. Recuerdo que su clase de introducción al curso escribió dos palabras en la pizarra:

Ritmo y Rito

Con esas dos palabras se podía resumir todas la metodologías de desarrollo de software, y en particular las llamadas metodologías ágiles.

¿Y quién es el encargado de esas dos cosas en una banda de rock?

El jefe de proyecto, por ejemplo, es como toda la sección rítmica de una banda de rock, encargado de llevar el ritmo, pero de que se ejecuten los ritos que solicita el proceso de desarrollo de software. Y así.

La metáfora creo que se explica por sí misma. Pero yo no era consciente de esto, no había eso esa distinción hasta esa tarde en que asistía a esta clase. Yo creía que sabía de ingeniería de software, pero se me escapaba algo tan esencial. 

Al estudiar, al analizar las cosas, al darnos el tiempo de disectarlas y extraerles los detalles, es que podemos entender de verdad lo que está ocurriendo y podemos integrarlas a nuestro ser.

Ritmo y Rito, y qué mejor ejemplo que SCRUM para reflejar esto.

Procesos ágiles

“When Mr. Ludwig invented the bass-drum pedal, that's what made the drum set possible.”
-― Neil Peart

No soy gran fan de Scrum, pero es una excelente manera de introducir agilidad en un ambiente estructurado, con mucha norma, con obligaciones normativas, donde tus procesos son auditados. Además funciona como esas rueditas que se le ponen a las bicicletas para que los niños aprendan a andar en estas.

Scrum permite formar el hábito de la entrega continua, del time box, que fija el tiempo, y aprendes a controlar el alcance de lo entregado. Permite introducir algunos términos de agilidad. Incluso Spotify, que es vista como uno de los principales referentes del uso de las metodologías ágiles, partió con Scrum.

En la segunda mitad de  2017 fue cuando empezamos a adoptar Scrum oficialmente en algunos equipos. Hasta antes de ese cambio teníamos un proceso que más o menos podíamos describir como iterativo incremental.

Pero más que el proceso, lo que ocurría es que teníamos un grave problema con la calidad y la entrega.

Calidad

“I don't think there's such a thing as a 'best' drummer”
― Mike Portnoy

Esta viñeta cómica de Geek & Poke refleja mucho lo que ocurre con la calidad en el proceso de desarrollo de software:

Una vez literalmente nos pidieron hacer esto con un proyecto. El proveedor se quejaba de que nuestro equipo detectaba muchos bugs.

Y efectivamente ocurre. También ocurre que pareciera que el proceso de control de calidad no parara nunca. Fue entonces en que cambiamos el switch.

Tradicionalmente ocurre que el proceso de desarrollo involucra una etapa que llamaremos construcción, seguida de una etapa de control de calidad. Y ahí empieza la iteración, la que puede llegar a ser infinita.

nuestro caso intentamos con una métrica que medía la cantidad de iteraciones entre desarrollo y QA en cada entrega.

Esencialmente nuestro proceso era así:

Eran muchas iteraciones entre desarrollo y QA, y los proyectos se alargaban hasta que cortábamos y tomábamos la decisión de pasar a producción. Eso,  por supuesto, debía cambiar.

La clave es dejar de pensar en dos unidades independientes. El equipo de desarrollo y control de calidad deben trabajar juntos. Además había que aclarar que la calidad no es responsabilidad del área de QA, la calidad es una preocupación de todo el equipo.

Definimos que todos eran desarrolladores, ya no habría distinción si programaban o ejecutaban pruebas. Además les pedimos a nuestros tester que escribieran pruebas automatizadas, así que también estaban desarrollando literalmente. Para mi ya no hay distinción entre esos roles, todos son devs.

Otro elemento importante fue definir las métricas adecuadas. La más obvia, la cantidad de defectos que pasamos a producción. Empezamos a medir cuanto porcentaje de defectos incorporábamos en cada paso a producción. Es doloroso medir esto, pero importante. Una medida estándar en DevOps es la tasa de falla en cada cambio, cuentas cuantos fallos tuviste al realizar un cambio en el sistema. Otra medida también es medir cuantos defectos introduces contra la cantidad de funcionalidad que agregas en cada paso a producción. En la primera teníamos una medida de 16%, en la segunda estábamos sobre el 30%. La primera medida no es mala, la segunda sí lo es. Pero vas obteniendo una mejor visión cuando la complementas con otras métricas interesantes. 

Ahora, gracias a Scrum los ciclos de entrega eran fijos, 2, 3 o 4 semanas. Sabíamos la cantidad de nuevas funcionalidades, mejoras y correciones que se implementarían en cada ciclo. Eso falicitó la implantación de dos métricas esenciales para mejorar.

La primera de estas métricas es la Eliminación Efectiva de Defectos. La definición clásica, descrita en el libro de Pressman de ingeniería de software (quinta edición), la define de la siguiente forma:

EED = E / (E+D) 

En esta ecuación el valor  E corresponde a la cantidad de defectos encontrados en una entrega anterior, y D son los defectos encontrados en la entrega actual. Lo ideal es que este valor sea 1, pues significa que estás eliminando todos los defectos. Nosotros manejamos una formula modificada de la presentada por Pressman (una métrica más exigente de hecho). Pero se puede partir con este simple cálculo para ir midiendo la mejora en la calidad del trabajo. 

El problema era que nuestros valores de EED eran cercanos a 0.5. Nuestra manera de medir el EED nos entrega más información la que nos permitió deducir que lo que ocurría es que estábamos ingresando tantos defectos como los que eliminábamos en cada iteración. Otra forma de verlo es que pasas el 50% del tiempo corrigiendo errores previos.

Otra métrica complementa es la que llamamos Valor Entregado (VE). Un ratio similar al EED que nos permite ver cuánto de lo que pasamos a producción son funcionalidades nuevas y mejoras, por sobre la corrección de defectos.

Aunque puedan parecer muy crudas, estas simples métricas nos permitieron mejorar. Crecimos, mejoramos, y cambiamos la forma de hacer las cosas. Estábamos incorporando la agilidad a nuestra manera. Y nos fue bien. Revertimos los resultados de las encuestas de clima laboral, incluso estuvimos entre los mejor evaluados, y sostuvimos esos resultados en el tiempo. El espíritu del equipo cambió. 

Nuestro viaje de transformación

“It´s nice when somebody says that you're their 'favorite' drummer”  –― Mike Portnoy

Todo es lo contamos a la comunidad ágil de nuestro país,  en un Meetup que organizamos. Una presentación que elaboramos a partir del esqueleto de mi presentación de 2015, “el viaje del agente de cambio”.

La gran diferencia es que ahora era mucho más real, y comprometía la visión de mi equipo, ya no era mi visión egoísta, era una mirada mas integradora y sincera. Pero lo mejor que esta historia fue presentada por mis principales colaboradoras, Carolina y Elizabeth, sin las cuales no podría haber logrado ningún cambio. 

Ese Meetup fue especial. Todo fue organizado y atendido por todo el equipo, y marcó un hito importante para nosotros, salíamos al exterior a contar nuestra experiencia y éramos escuchados con interés y respeto.

Todo esto quedó registrado en un video que grabó Miguel González, y que les dejaré acá para que lo vean, ahí se describen mejor los cambios que realizamos, nuestras experiencias, dolores, y aprendizajes. 

Con esto ya nos estamos acercando al final de esta serie. El fin de una época se acercaba pero no lo sospechábamos, venían cambios y desafíos mayores, pero estábamos mejor preparados para afrontarlos, aún teníamos problemas, no menores, que resolver. Pero habíamos cambiado y eso es bueno.

Notas:

El video está en este enlace: https://www.youtube.com/watch?v=i0GpxfyZjr4&feature=youtu.be

La primera parte de esta serie se encuentra en este enlace. 

“Mission First
People Alway”
— Us Air Force Mantra

CBGB OMFUG era un Club ubicado en el 315 de Bowery entre la 1ª & 2ª Calle en el Lower East Side de Manhattan, en Nueva York, que se convirtió en el epicentro del Punk y el New Wave en los primeros años de la década del ochenta. En CBGB hicieron su estreno Talking Heads, The Ramones y Blondie.

En su libro “How Music Works” David Byrne,  músico y fundador de The Talking Heads, cuenta que él consideraba a CBGB como un sistema auto organizativo. “Una entidad emergente gobernada por pocas reglas que Hilly Kristal estableció al principio, reglas que permitieron que toda una escena emergiera en Nueva York a fines de la década de los 70”.

Mi unidad se desarrollaba de la misma forma que la escena Punk en CBGB, de una manera orgánica, emergiendo a partir de muy pocas reglas. No porque estuviera especialmente planeado así. En parte porque yo soy muy perezoso para andar estableciendo demasiadas reglas. Por otro lado, no teníamos mucho tiempo para organizarnos pues éramos muy pocos y teníamos un montón de cosas por hacer.

The job that ate my brain

Five o'clock rolls around I feel so glad I kiss the ground
There isn't enough hours in the day, there's go to be a better way 
— The Ramones

Un día estaba saliendo del trabajo muy tarde y vi que Rosita, quien trabaja en operaciones, todavía seguía ocupada en su puesto. Me acerqué y le pregunté en qué estaba. Me explicó que era un proceso que debía correr una vez a la semana, y que entre tantas cosas que debía hacer en el día no alcanzaba a abordarlo a tiempo. Así que prefería trabajar en esto cuando ya nadie la molestaba. Indagué un poco más y descubrí que gran parte de los problemas de Rosita se debían a la falta de sistemas, o a fallas en los que usaba. 

Hablé con Miguel y el resto de los chicos de desarrollo, su misión era lograr que Rosita se fuera a su casa temprano como correspondía. No les dije específicamente qué hacer, ellos deberían ver la manera de lograrlo, para esto tendrían que hablar con ella y con otros compañeros del área de operaciones y ejecutar mejoras.

Un ejemplo muy simple de lo que pasaba: Rosita usaba una aplicación que se usaba para cargar archivos para ser procesados. El problema es que se debían subir los archivos uno por uno. Miguel detectó esto en la primera conversación y no se demoró nada en modificar la aplicación para cargar varios archivos a la vez. Esto parece super obvio, pero el programador original de la aplicación nunca se molestó en determinar la verdadera necesidad de los usuarios.

Así fue que los chicos empezaron a realizar pequeñas mejoras. Recuerdo que teníamos más de 400 tickets en Jira que se resolvieron en 4 meses de trabajo. Un día me encontré con Rosita en el ascensor a las 5 de la tarde, “¿tan temprano te vas hoy?", le pregunté.  “Sí”, me dijo, no sólo había terminado su labor, además su jefa le había dado además el siguiente día libre. Me dijo algo como: “ya no me quedo hasta tarde gracias a las mejoras que hicieron tus chiquillos”. Fue así que me sentí orgulloso de mi equipo, y se los agradecí. 

Por ese tiempo construyeron otra herramienta que denominaron “Ejecutor de Procesos”, que seguimos usando hasta hoy. Un sistema que ha resuelto muchos problemas y ha facilitado la vida de nuestros usuarios. Una aplicación cuyo diseño no me convencía mucho al principio, debo confesar. Contábamos con un equipo con mucho potencial, pero todo eso estuvo a punto de perderse, por un mal manejo de mi parte, pero sigamos avanzando en esta historia. 

Muchas veces seleccionamos mal a las personas que incorporamos a nuestros equipos. 

A veces seleccionamos personas que no calzan con este espíritu de equipo, es ahí cuando debes tomar una dura decisión, la desvinculación.

The Road To Nowhere

Well, we know where we're goin'
But we don't know where we've been
And we know what we're knowin' 
But we can't say what we've seen
— Talking Heads

Desvincular laboralmente a una persona es de las cosas más difíciles que te tocan realizar como líder o jefe. Nadie te prepara realmente para eso. Después de todo inviertes tiempo reclutando gente y no quieres llegar a esa situación. 

Recuerdo una ocasión en que tuvimos en el equipo a una persona, un ingeniero de desarrollo, que no se ajustaba a nuestra forma de trabajar, y tampoco colaboraba mucho con el equipo. Era una persona inteligente y hábil técnicamente, pero hacía las cosas del modo que a él le parecían bien, no consideraba para nada las pocas directivas y prácticas que habíamos definido en esa época. 

Cuando detectamos que era un problema, empecé un proceso de orientación con él. No puedes desvincular a alguien de un día para otro, debes darle la oportunidad de mejorar. Debes orientarle, decirle qué es lo que está mal. Explicarle por qué no estás conforme con su labor, y qué es lo que esperas de él. 

Yo realicé esta gestión con este desarrollador, pero no tuve éxito. Fue entonces que mi jefe, Claudio, tomó la batuta y conversó con él, hicimos seguimiento y no logramos nada. En esa época ya habíamos decidido que Carolina se haría cargo del equipo de desarrollo. Independiente de esa decisión, ella nos comunicó que se haría cargo del caso, hablaría con este chico, le haría seguimiento y tendría éxito donde nosotros habíamos fracasado. Se sentía segura al respecto. Nos pidió un par de meses y se los dimos.

Pero no tuvo éxito, a pesar de la confianza en ella misma y en sus gestiones, le fue tan mal como a nosotros. No había manera de alinear a esa persona. Así que un día nos comunicó que teníamos razón, que en realidad no había otro camino que prescindir de ese ingeniero. 

Bueno, le dijimos, entonces ahora le toca despedirlo. Pero no te preocupes, le acotamos, te apoyaremos en el proceso. Un día fuimos a almorzar y le dimos algunos tips y consejos para afrontar ese momento.

En mi experiencia, la mayor parte de las veces despides a alguien no hay grandes problemas. Muchas veces no es sorpresa para ellos, si has estado dándole las señales que corresponden. El problema es cuando ellos no se lo esperan, o peor aún, cuando no son capaces de entender lo que está mal con ellos, cuando no tienen ningún sentido de auto crítica. Este último tipo de personas son normalmente los más complicados de tratar. 

Así que allí estábamos, el día de la desvinculación, los tres sentados en una oficina, con Carolina indicándole que no seguiríamos trabajando con él y entregándole su finiquito. Yo estaba allí de observador, y testigo del proceso. La respuesta de este desarrollador fue inesperada, se molestó mucho, y empezó una discusión, la que tuve que interrumpir. La decisión ya estaba tomada, no era necesario continuar con la conversación. Nunca hay que involucrarse en más discusiones durante este momento. Extender el momento del despido no es bueno para ninguna de las partes.

Pero definitivamente no fue una experiencia agradable. Es por esto que debes evitar caer en esos casos. Entonces tuvimos que aprender y realizar un par de cambios:

• Mejorar nuestro proceso de selección
• Dar feedback temprano y permanente a los miembros del equipo.

De esto último voy a hablar en este artículo, de lo primero me extenderé en otro momento.

Heart of Glass

Lost inside adorable illusion
And I cannot hide
I'm the one you're using
Please don't push me aside 
— Blondie

En su libro “Radical Candor: How to Get What You Want By Saying What You Mean”, Kim Scott nos ilustra con el ssiguiente gráfico:

Hay dos dimensiones en las que nos movemos cuando nos relacionamos con los demás. En el eje vertical está el cuidado personal, la preocupación genuina por los demás. En el eje horizontal está el desafío directo. En el trabajo el desafío tiene que ver cuando exiges resultados a tu equipo.

Si recuerdan lo que vimos en el capítulo 9 de esta serie, ahí les mostré un diagrama con cuatro cuadrantes similar a este. En ese caso las dimensiones son  la seguridad sicológica versus la motivación. 

Esto es análogo, pero desde la perspectiva en que te relacionas con los miembros de tu equipo que están a tu cargo.

Es importante preocuparse por las personas, pero si nunca la desafías, si nunca le mencionas lo que no te parece, lo que te molesta, si en el fondo esquivas el conflicto, caes en una zona de falsa armonía. Esto es lo que Kim Scott denomina la Empatía Ruinosa. No quieres hacer daño, no quieres decirle a esa persona qué es lo que está mal, porque quieres ser amable con ella. Esto por supuesto requiere que en realidad estés interesado en no hacer daño a esa persona, porque cuando en realidad no te importan sus sentimientos, lo que estás haciendo realmente es Manipulación sin Sinceridad.

Lo peor es cuando no te importan los sentimientos de las personas, y sólo estás interesados en desafiarlos. Es ahí donde caes en el cuadrante de la Agresión Desagradable. 

Fue entre 2014 y 2015, cuando caí en ese cuadrante precisamente y lastimé mucho a mi equipo con esa actitud.

Life During Wartime

This ain't no party, this ain't no disco,
This ain't no fooling around
This ain't no Mudd Club, or C. B. G. B.,
I ain't got time for that now
— The Talking Heads

A fines de 2014 empezamos a desarrollar un proyecto importante, con un plazo acotado. Además yo quería que implementáramos micro servicios y desplegármos directamente en la nube. Había pedido autorización para experimentar con estas tecnologías en este proyecto, la promesa era la de tener menores costos.

Cometí varios errores. El primero fue traer a un desarrollador al que le di demasiada libertad y autoridad, por sobre Miguel, mi desarrollador más experimentado. Mi idea era que se desafiaran mutuamente. Quería tensionar a Miguel, pues yo percibía que siempre solucionaba todo con las mismas herramientas, y yo quería más innovación. Pero la persona que traje no era la adecuada, tampoco la estrategia. Estaba manipulando a Miguel, y no lo escuchaba. Finalmente tuve que despedir a ese desarrollador, no sólo generaba conflictos, sus soluciones resultaron ser inadecuadas técnicamente.

Otro error fue no conseguir apoyo interno, me tropecé con la resistencia del equipo de sistemas, quienes sentían, con razón, que me metía en su área de competencia. Se cuestionó la seguridad del proyecto. Tuve muchas discusiones en esa época. Con mi equipo, con mis pares, y mis jefes. Cada año hacemos evaluación de clima laboral, y en 2015 mi unidad fue la que obtuvo el peor resultado de toda la empresa. No podía haber estado peor.

[Además por ese tiempo se fueron dos personas valiosas que nos apoyaban en el equipo de Elizabeth, eran Contardo y Gustavo, que habían llegado cuando reorganizamos al equipo de explotación y lo transformamos en el equipo de Control de Calidad y Soporte. Con ellos intentamos implantar integración continua, sin mucho éxito, debido a un fenómeno que yo llamo “materia oscura”, del que les hablaré más adelante en esta serie. No pudimos retenerlos, les hicieron una oferta laboral que no podíamos igualar. 

Todo lo que te recomienda hacer Kim Scott en su libro, yo lo hacía al revés. Era un pésimo líder. No estaba tensionando, estaba presionando. No me preocupaban realmente las personas, sólo el objetivo. Por supuesto que yo también colapsé.

Entonces fue que tuve que retroceder un poco. Parar y tragarme mi orgullo. Tuve que ceder en algunos puntos, negociar con mis pares además de pedir ayuda y lo principal, conversar con mi equipo y pedirles disculpas.

En 2015 finalizó toda una época en mi equipo de Previred, no lo sabíamos en ese momento, pero ese fue el año que marcó una inflexión positiva en nuestra gestión y forma de hacer las cosas, un momento de crisis que nos haría reflexionar.

Sin ponernos de acuerdo Carolina, Elizabeth y yo decidimos salir a estudiar. Sabíamos que teníamos que hacer grandes cambios, porque estabamos a punto de estropear algo que tenía mucho potencial. Teníamos que cambiar y lo hicimos, y eso es lo que les contaré en los capítulos finales de esta serie.

Notas:

El capítulo 10 de esta serie se encuentra acá.

El primer capítulo de esta serie está acá.

Spirit with a vision
Is a dream with a mission 
– Rush

En febrero de 2011 habíamos pasado a producción uno de los proyectos más ambiciosos abordados por mi equipo hasta ese momento. 

Cumplimos en los plazos, aunque el sistema técnicamente no estaba terminado. Tal como expliqué antes, si nos comprometemos a una fecha nuestro foco es cumplir con el plazo. La gestión se enfoca a lograr este hito primero, si eso requiere recortar alcance, pues se recorta. Otra medida importante es la gestión de los riesgos, mantener a todos informados de los impedimentos que no permiten cumplir con la fecha y tomar medidas para mitigarlas. Así que una vez cumplido el hito de paso a producción, empezaba una etapa posterior de mejora continua para estabilizar el sistema para cubrir la mayor cantidad de requisitos establecidos en el alcance original.

Boston

“I'm shipping up to Boston
— Dropkick Murphys

Después de ese hito, En mayo de 2011 viajé a Boston, Massachusets, para asistir al RedHat Summit de ese año. También había recibido un reconocimiento de la empresa por mi trabajo en esos primeros años, así que me sentía contento.

El evento fue interesante, porque ahí pude asistir al lanzamiento de la primera versión de Openshift.

Así fue cómo resucitaron los recuerdos de lo que vi en aquella visita a Borland en los 90. Quería que trabajáramos en integración continua. Tuvieron que pasar un par de años aún para empezar a implementar esta tecnología en nuestra empresa.

También se produjo uno de los primeros cambios importantes en esa época. Rubén Valenzuela nos comunicó que decidiría aceptar una oferta en Oracle y que abandonaría la empresa. Eso planteaba una re estructuración mayor. De este modo, decidimos dividir nuestra área de sistemas, el equipo de DBAs e ingenieros de sistemas se incorporarían al equipo principal de sistemas de Previred. El grupo de soporte y QA estaría a mi cargo. Así empezamos la búsqueda de una persona que se hiciera cargo de esta área, que llamamos temporalmente “area de explotación”. Fue así como se incorporó Elizabeth Sepúlveda a nuestro equipo.

Ese año también Carolina Rojas se hizo cargo de todo el equipo de desarrollo, así fue como nació la organización nuclear de mi equipo de trabajo. 

El power trio que apoyaría mi gestión durante estos años, nació en esa época, aunque no se consolidaría hasta un buen tiempo después. Carolina Rojas a cargo de la gestión de proyectos y el equipo de desarrolladores, Elizabeth Sepúlveda en control de calidad y soporte, y Miguel González en arquitectura. Estas tres personas estaban conmigo en 2011, pero sus cargos y posiciones definitivas las fuimos configurando a lo largo de varios años.

Power Trio

Today is the day for you to rise,
Take my hand, you're gonna be my man,
You're gonna rise
 — Jimmy Hendrix Experience

En el rock, un  power trío [es una formación musical compuesta originalmente por una guitarra eléctrica, un bajo eléctrico y una batería. Esta formación nació en la década de los sesenta, uno de los primeros ejemplos son Cream y The Jimmy Hendrix Experience.]{style="letter-spacing: 0.01rem;"}

ZZ Top, es un ejemplo de un power trio famoso de blues texano, formado en 1970. En el progresivo tenemos a Rush, y Emerson Lake and Palmer, en este último caso la guitarra se reemplaza por sintetizadores.

Y uno de los mejores power trios de los ochenta es por supuesto The Police. Cuando vinieron a Chile en 2008, mi hermana me regalo para mi cumpleaños entradas para ir a verlos. Fue una jornada increíble ver a los tres británicos y en particular a Stewart Copeland, uno de mis bateristas favoritos en vivo.

Intermezzo

And the colors of the sea
Blind your eyes with trembling mermaids
And you touch the distant beaches
With tales of brave Ulysses 
— Cream

En  julio de 2010 reflexioné sobre el número tres:

“Triple es la manifestación de la Diosa, como Doncella (Coré), como Madre o Mujer adulta (Demeter) y como Anciana o Bruja (Hécate). Como la luna, Creciente, Llena, Menguante.

Tres son las Moiras (o Parcas), que decidían el destino de los hombres, Cloto la que hilaba el hilo de la vida, Láquesis que lo medía, y la más terrible, Átropos que lo cortaba."
Tres las Gorgonas: Medusa, Esteno y Euríale. Tres las Grayas, las ninfas del Estigia, que compartían un único ojo y que fueron engañadas por Perseo para obtener el yelmo de Hades y los objetos mágicos necesarios para lograr su hazaña.

Triple era la división del calendario de los antiguos, en 3 estaciones, no en cuatro como nosotros.360 días, en 12 meses, de 30 días, y 4 días de renovación. Múltiplos de 3, como las 24 horas.

Triple es el dios de los cristianos, Padre, Hijo y Espíritu Santo, representado por un triángulo equilatero apuntando hacia arriba.

Triples son las historias de los hermanos, el mayor, el del medio y el menor (que siempre es el héroe). Como los tres chanchitos (o los tres cerditos), o la fábula de tres hermanos de Silvio.

Triples los chistes, de primer acto, segundo acto, tercer acto, y los chistes de 3 personajes, normalmente de paises vecinos (un argentino, un peruano y un chileno…), o de tres potencias (el presidente de estados unidos, el de rusia y por supuesto el de chile van en un avión…).

Tres son las oportunidades, tres son los deseos que otorga el genio de la botella.

¡La tercera es la vencida!

Tres partes debe tener un drama dice Aristóteles, principio, medio y fin. Tres actos, según el paradigma de Syd Field para los guiones: planteamiento, confrontación, desenlace.

“Te amo”, te amo, te amo”, repite tres veces el Señor Darcy a Lizzy, en la versión fílmica de Orgullo y Prejuicio, favorita de mi esposa. Y las tres mujeres de mi casa suspiran por igual al ver esa escena. Yo prefiero cuando Leonidas usa la triple fórmula en 300: “My Queen, My Wife, My Love” (mi reina, mi esposa, mi amor).

Tres, siempre tres.
Algo hay cableado en nuestro cerebro que reclama esta estructura triple, esta triple repetición, el triple suspiro. Tres.

Tres puntos definen un plano, por eso la [mesa más estable es la de tres patas. Entonces, ¿qué es lo que el número tres tiene para aportarnos?

Las tres P

When the world is running down
You make the best of what's still around
— The Police

Como líder administrador, gerente, jefe tu principal preocupación debería estar en tres cosas, nos recomienda Julie Zhuo en su libro:  The Making of a Manager.

Yo las llamo las 3 P de la administración:

Propósito, Personas y Proceso

El propósito se encarga de definir el por qué, el Why que menciona Simon Syntek en su famosa charla TED. Synek no propone una estrategia de negocios en esta charla, lo que nos explica es la forma en que los líderes inspiran. Es importante distinguir esto.

El segundo elemento son las personas, es decir el quién. Son el elemento más importante, es a ellos a quienes debe dirigirse la  visión.

El tercer elemento de este triángulo dorado es el cómo, es decir, el proceso.Preocúpate de establecer y comunicar bien el propósito, elige a las personas adecuadas, luego configura y mejora continuamente el proceso, que es la forma cómo se hacen las cosas. Esa es la clave para empezar a avanzar.

Las voy a resumir en este diagrama:

Este es un verdadero power trio que, yo creo, te permitirá salir adelante con todos los proyectos que emprendas y comprometas. 

Propósito, Personas y Proceso.

En el centro del triángulo surge el qué, el producto, el resultado de tu gestión.

Colofón

Synchronicity
A connecting principle,
Linked to the invisible
Almost imperceptible 
– The Police

Sólo quiero agregar una cosa más.

Kierkegaard nos dice que la vida consiste en una serie de decisiones que tomamos día tras día. Nuestra existencia es, finalmente, el resultado de esas decisiones. Tomamos esas decisiones en función de lo que somos y de lo que queremos ser.

“La vida no es un problema a ser resuelto sino una realidad que debe ser experimentada”.

Comprenderán entonces que en 2011 este triángulo que les he mostrado no era un concepto que yo tuviera claro o definido. Apenas estaba avanzando tomando las mejores decisiones que me parecían pertinentes en ese momento. Cada elección era una apuesta. Cada apuesta tenía resultados y consecuencias. No todas las decisiones fueron acertadas, y cometimos muchos errores.

Kiekegard dice “La vida sólo puede ser comprendida mirando hacia atrás, pero ha de ser vivida mirando hacia adelante”. Lo que nos dice el filósofo danés es que para comprender lo que somos debemos mirar a nuestro pasado.

Esta serie me ha permitido comprender muchas cosas de lo que soy como persona, además de entender cómo nuestro equipo ha llegado a ser y funcionar de la forma en que lo hace. Pero lo más importante, es que no debemos quedarnos atrapados en el pasado, hay situaciones que ya no podemos cambiar, quedarse pegado lamentando esto es morir lentamente. Me niego a eso, por supuesto. Cuando me sienta tranquilo y completo significa que estoy listo y resignado a morir. Así que con lo valiosas y entretenidas que son estas memorias, lo mejor aún está por llegar. 

Notas

El capítulo 9 de esta serie se encuentra acá.

El inicio de la serie completa está en este enlace.

R-E-S-P-E-C-T
Find out what it means to me
— Aretha Franklin

El rock y el pop han contado desde siempre con grandes voces femeninas. El rango de mis favoritas va desde el soul de Aretha Franklin, hasta la vanguardista Björk, pasando por las hermanas Wilson (Heart), la actitud punk de Hayley Williams (Paramore) y Shirley Manson (Garbage). De mi juventud rescato a las maravillosas Cyndi Lauper y Pat Benatar. Por supuesto a Christine McVie y Stevie Nicks de Fleetwood Mac. Y una lista como esta no puede dejar de incluir a dos grandes cantantes que nos abandonaron muy jóvenes: Janis Joplin y Amy Winehouse.

Son voces fuertes y maravillosas, que no tienen problemas en decir las cosas como son, con franqueza, pero sin odiosidad, con respeto y firmeza, justo dos de los valores que considero son esenciales para liderar un equipo de alto rendimiento.

Esta es la novena parte de esta serie y ya entro en la etapa actual de mi vida profesional. Son un poco más de diez años los que llevo trabajando en Previred, mi actual casa profesional. Más que continuar con la veta auto biográfica, quiero terminar esta serie con algunos artículos enfocados en los pilares que hemos ido construyendo para sostener nuestro trabajo en la organización. Por supuesto contaré algunas anécdotas o datos biográficos que considere relevante, pero no implica que seguiré con una secuencia cronológica lineal como hasta ahora.

Reformas

All that I want
Is to wake up fine
Tell me that I’m alright
— Paramore

Tal como se expresa en los principios del manifiesto ágil: “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor”.

A eso me he dedicado todos estos años desde que recibí la invitación de Esteban Segura a unirme a formar la gerencia de nuevos negocios de Previred en agosto de 2008. Tal como conté, al final del capítulo anterior, fue un encuentro casi fortuito el que nos puso en contacto y que permitió que me incorporara a este proyecto.

Dos mil ocho fue el año en que se promulgó la reforma provisional del primer gobierno de Michele Bachelet. Esta reforma planteaba la necesidad de implementar una serie de cambios normativos que requerían la coordinación entre las instituciones públicas y privadas de previsión social. 

En esas reformas aparecía el pilar solidario, se establecían servicios para agilizar la atención de los futuros afiliados a través de las oficinas de ChileAtiende, se implantarían una serie de aportes estatales para fomentar el ahorro provisional en jóvenes y mujeres. La industria de la seguridad social requería desarrollar un músculo tecnológico que respondiera rápido a los desafíos que proponía la reforma. Fue así como se le encargó a Previred ejecutar una serie de proyectos, y para esto se decide crear una unidad especializada en brindar estos servicios.

El ocho de septiembre de 2008 estábamos Esteban y yo sentados en una sala de reuniones, empezando a modelar la nueva gerencia. Se nos uniría unos días después Vania Orloff, quien además durante esas primeras semanas nos capacitó de manera muy generosa en el funcionamiento del sistema de seguridad social chileno. 

Los tres estableceríamos nuestra una unidad con total independencia, una decisión audaz de la gerente general de ese entonces, Rosita Ackermann, quien confiaba plenamente en nuestro criterio y capacidades. Esteban estaba a cargo de la dirección general y la gestión comercial, Vania de todo lo operativo y yo de tecnología.  Mi desafío personal era armar todo el equipo de tecnología, desde infra estructura hasta desarrollo.

Value Driven Development

“I drove all night to get to you
Is that alright”
— Cyndi Lauper

¿Cómo logras desarrollar un marco de trabajo que soporte el desarrollo orientado al valor (“Value Oriented Development”)?

En nuestra experiencia, en estos años de trabajo, hemos desarrollado un marco de trabajo sostenido en tres pilares esenciales:

1. Establecer una Cultura.

2. Mejorar en las Prácticas y Técnicas.

3. Medir del Desempeño 

El foco de este post está en el primer pilar, que tiene que ver con el cambio cultural. ¿Cómo construyes, o sostienes una cultura? ¿Y por qué es importante la cultura?

El software, o cualquier servicio, no se surge espontáneamente, son las personas son las que lo construyen. Hay personas que creen que uno es capaz de desdoblarse y separar los sentimientos, todo lo que te hace persona, de los aspectos profesionales. Y no es así. Vamos con todo al trabajo, y esto es lo que debemos reconocer, sobretodo los que estamos ejerciendo el liderazgo.

Tal como puse casi al final de mi primer libro:

El software es desarrollado por gente para la gente. La gente se equivoca, estima mal, es optimista, es ignorante, es inteligente, es brillante, es deficiente. La gente es el factor clave.

Y como creo en eso, es que aprendí a preocuparme de ese entorno en el que se desarrolla el quehacer de la gente, la cultura.

Cultura

There's definitely, definitely, definitely no logic
To human behavior
But yet so, yet so irresistible
And there's no map
— Björk

Cuando partimos en nuestra unidad de nuevos negocios no lo hacíamos en el vacío, ya habían algunos proyectos lanzados que teníamos que empezar a administrar. [Recibimos apoyo de la organización, pero rápidamente empezamos a movernos de una manera distinta, dada la libertad que teníamos. Incluso contratamos los servicios de un datacenter distinto al que usaba la organización para sus servicios.]{style="letter-spacing: 0.01rem;"}

Yo empecé a seleccionar ingenieros para armar el equipo de desarrollo. Traté de traer gente con quienes había trabajado, pero no se dieron las condiciones. Pero tuve la fortuna de encontrar a un joven muy inteligente, con un gran corazón y una gran actitud, Felipe Bello. Junto a él llegó otro joven con muchas ganas de aportar, se trataba de Nicolás Vergara. Juntos los tres empezamos a desarrollar nuestros primeros servicios.

Felipe tenía un magister en minería de datos, así que durante ese tiempo fue un apoyo importante para poder armar una serie de pruebas de concepto para servicios de información que podíamos brindar. Fue un tiempo intenso, porque no teníamos muchos recursos y debíamos cumplir con plazos normativos.

Era la época el caos de expansión. Nos quedábamos hasta tarde. Había mucha operación manual y creábamos y creábamos nuevos servicios prácticamente cada día. Pero era difícil encontrar talento.

Mars Need Women

All your life you've never seen
A woman taken by the wind
Would you stay if she promised you heaven?
Will you ever win? 
— Fleetwood Mac

Fleetwood Mac comenzó como una banda más del british blues, una época en que cultivaron grandes éxitos. Pero es innegable que hay un cambio radical cuando se incorporó Stevie Nicks y Christine McVie pasó al frente. Se convirtieron en una banda totalmente distinta y probablemente más exitosa. Ese es el mágico poder que tienen las mujeres cuando se incorporan a cualquier equipo.

Cuando estaba partiendo, empezando a formar mi equipo me encontré con un amigo que me dio varios consejos sobre cómo organizar equipos productivos. Una de las cosas que me dijo es que incorporara mujeres rápidamente al equipo. Una razón, me dijo, es que si partes con un equipo sólo de hombres se formará una cultura más dura, donde la rudeza será la norma principal, y después será difícil incorporar a más mujeres en el equipo, porque la toxicidad las alejará. Tomé nota del consejo y fue uno de los principios que establecí como esencial para conformar mi equipo: el equipo debería reflejar diversidad, así que apuntaría a tener la mayor cantidad de mujeres posibles. 

En 2009 se incorporó una de las primeras mujeres a mi equipo en Previred, venía recomendada por Felipe, pues habían trabajado juntos. Se trataba de Carolina Rojas, de acuerdo a Felipe, ella era una excelente ingeniero desarrollando software, pero tenía mucho potencial como líder y estaba buscando desarrollarse en la dimensión de gestión. Por otro lado yo necesitaba alguien que me ayudara a sacar adelante un proyecto que tenía fecha límite inamovible, y estaba siendo ejecutado por un proveedor externo.

Carolina, cuando recuerda la entrevista de trabajo, siempre menciona que le pregunté si ella conocía Java o algo de JBoss, a lo cual respondió con un no, y que a pesar de eso le dije que estaba contratada. Debe haber pensado que yo estaba chiflado, o muy distraído. En realidad, lo que me importaba era poner a prueba su actitud y ambición, esas ganas de crecer profesionalmente, que mostró en la entrevista. Detecté mucho potencial ahí y por fortuna no me equivoqué.  

[Años después escribí sobre esta idea de incorporar más mujeres a los equipos. Resulta que el resultado que tuvo Fleetwood Mac no era cosa de azar. Tal cómo lo explico en detalle en este artículo: Marte necesita mujeres, es muy importante la participación femenina en equipos de alto desempeño.

Este gráfico está tomado de esa nota:

El gráfico aparece en un estudio de 2007 que muestra cómo incorporar mujeres en un equipo permite alcanzar alto desempeño.

Me concentro en este gráfico porque habla de una de las dimensiones importantes de las que te debes ocupar para generar un ambiente de alto desempeño, la seguridad sicológica.

Seguridad sicológica

No sir, well I don't wanna be the blame, not anymore.
It's your turn, so take a seat we're settling the final score.
And why do we like to hurt so much? 
— Paramore

La seguridad sicológica es muy importante, pero no puede ser todo. Si sólo te concentras en la seguridad sicológica llevarás a tu equipo a una zona de confort donde estarán felices y cómodos, pero no darán lo mejor de si mismos. Debes motivar y exigir para que puedan llegar a su máximo potencial.

Se los graficaré con el siguiente dibujo:

En el eje vertical hemos puesto la seguridad sicológica, un elemento muy importante del que te tienes que hacer cargo como líder. En el horizontal el compromiso y la exigencia. Esto nos permite formar cuatro cuadrantes. El inferior a la izquierda es la zona de la apatía. No hay seguridad sicológica, nadie se compromete con nada, porque si bien nadie se preocupa por mantener un buen clima, no hay desafíos, así que las cosas no se mueven. No quieres estar en este cuadrante.

El cuadrante inferior derecho es la zona de la ansiedad, la angustia, es a donde empujamos a nuestro equipo al extremo y los llevamos al “ burnout", es la zona en que quemas a tu equipo. Puedes tener grandes logros, pero a un costo muy alto. Es la zona en la que empiezan muchas empresas. Nosotros pasamos muchas veces por ahí, al inicio de nuestra travesía como equipo, eso no lo puedo negar. 

Muchos de los jóvenes que recluté en los primeros días no soportaron el ritmo que llevábamos, y no nos preocupamos tanto por la seguridad sicológica. Es muy fácil caer en este cuadrante, creo que la mayor parte de los jefes lo hacen, pero hay que aprender de que no es positivo para nadie. En menos de un año sufrí la partida de Felipe, por ejemplo, la que fue dolorosa para mí, en lo personal, pero quizás fue necesaria para detectar que algo estaba haciendo mal. Una situación como esta te afecta como líder, pero te puede llevar a cometer otro error típico.

Cuando lo líderes se dan cuenta de lo malo que es estar en la zona de ansiedad, toman medidas correctivas. Toman un curso de liderazgo moderno versión 4.0 (o cualquier release que esté de moda), compran muchos legos y quedan convencidos que su misión en la vida es gestionar la felicidad de sus empleados, a los que empiezan a llamar colaboradores. Dejan de hablar de recursos humanos porque descubren que trabajan con personas. 

Les baja una iluminación culposa y agendan una reunión de una hora y media a la semana para escuchar los dolores del su equipo. Como el foco  es la felicidad, todo el mundo se relaja y caen en la famosa zona de confort. Esta zona está bien, es un avance después de todo. Pero tiene un serio problema, no hay mucho delivery. Y es porque si bien han dado un paso importante al reconocer que trabajan con personas, no las tratan como adultos, tampoco las respetan como profesionales. No les exigen grandes cosas. No quieren que piensen mucho, basta que sigan el procedimiento y tengan muchas actividades de reconocimiento. Ir más allá de la descripción del cargo es un gran no-no, tanto para los miembros del equipo como para los jefes. Es la zona en la que lo que más importa en la motivación, la que es una trampa, como ya veremos.

El cuadrante en el que quieres estar es el superior derecho. Donde la gente está realmente comprometida con su trabajo. Para llevar a las personas a este cuadrante debes exigir, plantearles desafíos, eso los lleva pensar más, a experimentar, a aprender. Es la zona de los adultos, de los verdaderos profesionales. Hay métricas, hay metas que cumplir, pero metas que tienen sentido para todos, porque son logros auto impuestos finalmente. Es donde la gente encuentra lo que le gusta hacer, donde liberan su verdadero potencial. Como dice Patty McCord, no se trata de empoderar a la gente, la gente ya tiene poder, lo que hay que hacer es establecer las condiciones para que lo liberen [1].

Conversaciones recurrentes

I want to be the one to walk in the sun 
— Cindy Lauper

La segunda mujer que se sumó al equipo fue Natalia Guzmán, como analista programador. Ella llegó un poco después que Miguel González, otra persona que se convertiría en uno de los miembros más valiosos de mi equipo.

Nuestro equipo inicial era pequeño, y mucho de lo que construimos fue con apoyo de proveedores externos. En 2010 el equipo de tecnología estaba dividido, yo me dedicaba totalmente al desarrollo de software con mi pequeño team. En infraestructura y QA nos apoyaba Rubén Valenzuela, que se convirtió en el tercer subgerente del área.

Fue a mitad de 2010 que la empresa sufre una primera re estructuración, al quedar Esteban a cargo de la gerencia general, tras la partida de Rosita Ackermann, la gerente original de Previred, quien no sólo había fundado la compañía, sino que en sus primeros diez años la posicionó como una herramienta esencial para el quehacer del sistema previsional. Miles de empleados usaban la plataforma para pagar sus cotizaciones previsionales. Por otro lado, en esos dos años la labor que realizamos en nuevos negocios había expandido la cartera de servicios de tal modo que nos integramos totalmente a la compañía. Fue en ese tiempo que llegó Claudio Sepúlveda a asumir la gerencia, que cambió el nombre a Gerencia de Apoyo al Giro. 

Recuerdo que Claudio nos regaló a cada subgerente el libro “La Meta” de Eliyahu Goldratt. Fue así como aprendí sobre la teoría de las restricciones de este pensador. Claudio nos trajo un estilo de liderazgo diferente. Su definición de equipo también se me quedó grabada, para él un equipo es “un conjunto de conversaciones recurrentes”.

Claudio nos desafiaba a intercambiar nuestras opiniones libremente, sobretodo a Rubén y a mí. Sospechaba que en varios aspectos no lográbamos avanzar por que ambos éramos personas demasiado conciliadoras y amables. Así que nos ayudó a ser más francos y directos para resolver nuestras diferencias. También me orientó en cómo liderar a mi equipo. El grupo fue creciendo, pasaron varios desarrolladores que estuvieron con nosotros varios años, como Bruno Vera e Ignacio Padilla.

Cuando Claudio llegó estábamos en la fase final del desarrollo de unos de los servicios más grandes. Un proyecto un año y medio de construcción, con el presupuesto más grande que habíamos manejado hasta ese momento. Fue también un desafío grande para Carolina, a quien nombramos jefa de proyecto, dirigió desde la licitación hasta la puesta en marcha de forma brillante. Fue en ese proyecto donde tuvimos que aplicar muchas técnicas de gestión a distintos niveles. Porque si algo nos caracterizaba hasta ese momento es que nunca nos atrasábamos en un proyecto. O para ponerlo de otra forma, la fecha de puesta en producción no era negociable. Y ese fue un elemento que empezamos a cultivar en nuestra cultura, cumplir nuestros compromisos.

Principios

En esos primero años se cimentaron algunos de los principios que tenemos como equipo. Hace poco hice una compilación de estos que he ido presentando en distintas partes, y que ahora les voy a compartir:

• Un equipo es un conjunto de conversaciones recurrentes.
• Si el plan no funciona cambia el plan, pero no cambies la meta.
• Fallar no es bueno, de lo que se trata es de aprender rápido, no de fallar rápido.
• Es mejor ser eficaz que eficiente. Sin embargo, la eficiencia nos gusta.
• Hay que cumplir, más que prometer.
• La confianza es un valor fundamental para nosotros, siempre partiremos confiando, pero como dicen por ahí: “confía, pero controla”

Nadie puso esto en piedra al principio de nuestra jornada de diez años, estos principios los fuimos adoptando gradualmente. Pero la cultura no es todo para lograr éxito y prosperar. La cultura te ayuda con el aspecto de la seguridad sicológica, con formar un equipo comprometido más que motivado. Pero, ¿cómo trabajas con la exigencia? ¿Cómo mejoras en lo técnico?¿Cómo fomentas la entrega de valor? De eso hablaremos en el siguiente artículo de esta serie.

Notas

[1] Sugiero ver este video de Patty McCord: https://www.youtube.com/watch?time_continue=4&v=iBa9EoEbb38

La primera parte de esta serie está acá

(Para escuchar la banda sonora de este post haz click aquí)

Thunder, thunder, thunder, thunder
I was caught
In the middle of a railroad track
— AC/DC

Recuerdo que una vez mi mujer, me pidió que hablara con nuestro hijo acerca de la música que estaba escuchando. Al parecer ella había visto a Matías viendo un video de Slipknot, y bueno, no creo que haya tenido imágenes agradables y debe haber quedado algo

Como soy un convencido de la relevancia de la tercera ley de Newton[1] en la crianza de los hijos,  compartí tiempo con Matías conociendo sus gustos musicales y conversando sobre diversas bandas de metal. Escuchamos algunos temas clásicos de Iron Maiden, Black Sabbath, pasamos por el funk metal, Smashing Pumpkins, Metallica, por supuesto, y revisamos algunas bandas contemporáneas, que le gustaban a él, como Körn, System of a Down, y por supuesto Slipknot. La verdad es que es muy difícil no admirar la técnica de Joey Jordison, pero no podía decirle eso a mi esposa ;-)

Creo que escuchar música aggro no necesariamente es algo malo. Los adolescentes tienen luchas internas, y sufren problemas, en su escuela tienen conflictos con otros chicos de su edad,  peleas, bullying, incluso incomprensión de sus padres, y  canalizan su ira de cierta forma en la música que escuchan. Creo que más que criticar su ropa, sus gustos musicales, debemos acompañarlos y escucharlos más. Algo que nos cuesta aprender, por supuesto. Olvidamos que pasamos por esa misma etapa en nuestro camino a la madurez. Pero no se trata de esto este post, así que retomemos la historia donde la dejamos.

Redes

We fought him hard we fought him well
Out on the plains we gave him hell
– Iron Maiden

En agosto de 2007 estaba sin trabajo. Desde el primer momento empecé la búsqueda de trabajo. Envié emails a todos mis conocidos. Tenía desde años una relación comercial con Don Enrique Rodriguez, mi primer mentor. Lo conocí cuando yo estudiaba ingeniería, fue el primer trabajo que tuve. En esos años desarrollé una serie de sistemas de ventas para su ferretería localizada en Buin. Pasé varios veranos trabajando con él perfeccionando el sistema y dándole mantención. Fue un ingreso permanente por varios años, incluso cuando desarrollaba mi carrera profesional. Posteriormente él fue adquiriendo diversos locales y utilizó el mismo software. Llegó a ser presidente de ChileMat, una red de ferreteros a nivel nacional, y entre las iniciativas que impulsó fue la actualización tecnológica de las ferreterías de la nueva cadena. Se armó un equipo de programadores que empezaron a desarrollar software para la cadena y para los locales, basados en los sistemas que yo había escrito a fines de los ochenta. Yo los asesoré en esto por varios años, capacité a los programadores, lo ayudé en el diseño y arquitectura. Varios sábados viajaba a Buin a trabajar con Enrique en estos proyectos. Fue en uno de esos viajes que tuve el accidente que les comenté en la parte siete.

Después de renunciar a BioKey hablé con Enrique y le pedí su apoyo. Junto a esto empecé a explorar diversas ideas. Una fue la de formar mi propia empresa y dedicarme por completo a desarrollar software, confiando en que Enrique podría ser mi principal cliente. También conversé con otros amigos, tuve varias entrevistas y un par de ofertas.

Algo que siempre recomiendo a los jóvenes profesionales es que trabajen en armar sus redes. Compartir con otros profesionales es esencial, y en momentos de crisis es cuando más se nota. Como dice Enrique, “más vale tener amigos que plata”, y tiene toda la razón.

Estuve sin trabajo exactamente veinte días. Finalmente conversé con Ubaldo, quizás lo recuerden porque en la segunda parte de esta serie hablé de nuestro viaje a Borland.

A él y su socio, les interesaba mi experiencia en biometría, puesto que se venían algunas licitaciones importantes donde estos conocimientos serían valiosos. También me apoyó contactándome con un abogado, que me ayudó a negociar los términos de mi salida de BioKey y me dio consejos legales al respecto. Otra cosa que me dijo Ubaldo es que quería incorporar más canas a su equipo. Así que decidí aceptar su oferta.

Heavy Metal Poisoning

That heavy metal (heavy metal) is poisoning
It's a music wasteland, that destroys the young (yeah!) 
– Styx

Algunos han definido el heavy metal como una de las mayores sub especies del Hard rock, con menos síncopa, menos blues, más “showmanship” y por supuesto más fuerza bruta[2]. Algunos dicen que los antecedentes del género se encuentran en la música de la triada sagrada: Led Zepellin, Black Sabbath y Deep Purple. Pero quizás su cúspide, de lo que llamaremos heavy metal clásico, está en la mitad final de los setenta y principios de los ochentas, con bandas como Judas Priest, Motohead, Iron Maiden, Deff Leppard, Van Halen y AC/DC.

El heavy metal dio origen a una cantidad enorme de sub ramas, como el Death Metal, el Trash Metal, el Black Metal, el Power Metal, el Glamm Metal, el Aggro Metal (en donde algunos colocan a Slipknot), etc.

Ubaldo es un gran fan del metal, y de sus géneros más alternativos, y hasta el día de hoy mantenemos “amistosas” discusiones sobre el valor de la música que él escucha, y aunque no he podido convencerlo que mejore sus gustos musicales, hay cierta intersección en nuestros gustos, principalmente en el heavy metal más clásico.

Un año intenso

Run to the hill
Run for your lives
— Iron Maiden

Entré a trabajar a EXE en septiembre de 2007, estuve un año en esa empresa y la verdad es que fue bien intenso. En ese tiempo actuaba de gerente de operaciones Eric, un amigo de años, que aportaba más canas que yo :D. En esos meses compartimos junto varios almuerzos charlando de meta matemáticas, filosofía y ciencia ficción. Tengo un gran aprecio por él, un docente por sobre todas las cosas, pero un gran amigo y mejor consejero.

Hice algunas cosas nuevas trabajando allá, participé por primera vez en una certificación ISO. También en una auditoría informática a una gran empresa concesionaria, un trabajo en donde aprendí de tecnologías que no me imaginaba, y en especial sobre como organizar una auditoría, algo que me sería muy útil años después. Ayudé a organizar el equipo que estaba a cargo del desarrollo de un producto propio de la empresa. Aporté con algunas lineas de código en el desarrollo de ese producto. Y también participé en varios otros proyectos. También fui parte de un equipo que se armó entre varias empresas para participar de una gran licitación a nivel nacional. Como podrán ver, fue un año bien movido.

En las empresas que desarrollan proyectos de software que siempre hay mucho qué hacer. El problema, en mi opinión, es la fuerte competencia y la realidad incómoda que el cliente no siempre tiene bien claro lo que quiere y cuenta con un presupuesto que suele no estar alineado con su verdadera necesidad.

El problema de estimar

Estimar cuánto costará construir, en tiempo y esfuerzo, es un arte. Y es la principal razón del éxito o fracaso de las empresas que desarrollan software.

Hay estudios en el campo de la ingeniería de software que dicen que al principio del ciclo de vida de un proyecto, antes de la recolección de requisitos, se estima con un nivel de incertidumbre de factor cuatro. Esto quiere decir, que una vez ejecutado el proyecto, el esfuerzo actual o alcance real del proyecto puede ser hasta 4 veces o 1/4 de la primera estimación.

Esto es lo que llamamos incertidumbre de estimación. En general esta incertidumbre va disminuyendo a través del curso y ejecución del proyecto, aunque este hecho no está garantizado.

Esto se refleja en este diagrama:

Esto es lo que se conoce como el cono de la incertidumbre.

El eje vertical refleja el grado de sobre estimación o sub estimación del alcance el proyecto. El eje horizontal muestra las etapas del proyecto. Podrán ver que un diseño detallado de las especificaciones es la única manera de reducir la incerteza. Pero el gran problema es que pocas veces nos dan tiempo para hacer ese diseño detallado. Debemos estimar en base a la intuición o juicio experto. Pero en el lado izquierdo del diagrama vemos que ocurren tres fenómenos:

Uno: Los ejecutivos sub estiman el tiempo y esfuerzo de un proyecto.

Esto se conoce como el exprimidor de Parkinson, en relación a la llamada Ley de Parkinson, que dice que el “trabajo se expande para ocupar todo el tiempo disponible para su completitud”. Entonces, los ejecutivos aplican el opuesto, o Exprimidor de Parkinson, tratan de reducir el tiempo para aumentar la productividad de sus equipos o de los proveedores.

La Ley de Parkinson se da por nuestra naturaleza humana. Si te dan todo el tiempo del mundo para realizar un trabajo, entonces tenderás a relajarte un poco, dado que no hay urgencia. También puede ocurrir que empieces a agrandar la tarea, más de lo que necesita ser, buscando incrementar la complejidad con el fin de llenar todo el tiempo disponible.

Por otro lado, si te dan menos tiempo para realizar la tarea tu aproximación será con un mayor sentido de urgencia. Reducirás el trabajo a lo esencial y concentrarás toda tu energía para lograr sacar el trabajo dentro del plazo que te han dado. Eso es el exprimidor de Parkinson, y los ejecutivos tenderán a ocuparlo.

Dos: Los ingenieros también subestiman.

Los que ejecutan la tarea también subestiman su esfuerzo. Pero a diferencia de los ejecutivos, que tienen una motivación clara, lo que ocurre con los ingenieros es el exceso de confianza. En este caso estamos ante la presencia de la Ley de Hoftstadter, la que dice que “siempre tomará más tiempo del que esperas, aún cuando tomes en cuenta la Ley de Hoftstadter”.

Hay un fenómeno relacionado, que se conoce como la Falacia de la Planificación. Un fenómeno observado por Kahneman y Tversky en 1979. Lo que actúa en este caso es lo que se conoce como sesgo de optimismo, el que nos hace creer que es poco probable que experimentemos un evento negativo. Ocurre que los ingenieros tienden a desestimar, o ignorar otros fenómenos externos al proyecto, los que pueden poner en peligro la ejecución del mismo. Desde la posibilidad de enfermarse, hasta el hecho de estar usando una biblioteca de software que no es compatible con el ambiente productivo del cliente. El “overhead”, suele ser ignorado por los ingenieros.

Tres: los directores de proyectos estiman mejor

Esto depende de la experiencia de los directores de proyectos, por supuesto. Con el tiempo, los jefes de proyecto saben y conocen una gran variedad de impedimentos que surgen en los proyectos. Un buen gestor  es aquel que está muy consciente de los riesgos del proyecto. Finalmente, gestionar un proyecto es gestionar los riesgos del mismo. Esto, sumado a un registro histórico y estadístico puede llevar a mejores estimaciones.

La clave, en mi opinión, es que debes contar con buenos jefes de proyectos en tu equipo, esos que sepan cuestionar las estimaciones tanto de los ejecutivos como de los desarrolladores.

Muchas empresas de desarrollo de software en Chile, según mi experiencia, se concentran en contratar buenos programadores, pero descuidan la selección de los jefes de proyectos. Además creo que hay una muy mala formación de gestores de proyecto. En mi opinión, muchos son sólo tomadores de pedidos, y no se encargan de lo realmente importante, que es lograr que las cosas pasen. No anticipan riesgos, no motivan a los equipos, no informan ni escalan los problemas, tampoco transmiten sentido de urgencia. Hay algunos que sólo se dedican a complacer a ejecutivos, clientes y desarrolladores, no quieren quedar mal con nadie. No se exigen, ni exigen. Además cuentan con malas habilidades negociadoras. Terminan aceptando cosas sin consultar con sus equipos, y un largo etcétera, en el que no quiero ahondar porque sino me va a dar rabia.

Así que acá un consejo a mis amigos que tienen empresas de desarrollo de software, por favor, elijan buenos jefes de proyecto. Formen buenos jefes de proyectos, contraten a los mejores jefes de proyecto. Sean conscientes de que serán víctimas de la Ley de Parkinson, de la Hoftstatder, o caerán en la falacia de la estimación. El mejor antídoto que he visto para eso es contar con buenos gestores de proyectos.

Encuentros inesperados

I think of all the education that I missed
But then my homework was never quite like this 
– Van Halen

Aquel año laboral fue muy intenso, como ya les dije. Hice casi de todo, incluso actuar como agente comercial. Fue en una visita a un potencial cliente, una empresa que tenía sus oficinas en el edificio de la Cámara Chilena de la Construcción, que me encontré con Jorge Rojas, mi ex jefe de la CCS. El trabajaba en Habitat en ese tiempo. Conversamos un rato, le conté en dónde estaba y él me contó de los desafíos de su nuevo trabajo.

A la semana siguiente tenía que volver al mismo edificio, esta vez para realizar una demostración a ese cliente, una empresa que yo apenas conocía, cuyo nombre era Previred. En el ascensor me encontré con Esteban, otro ex colega de la CCS, me saludó y me dijo que justo quería hablar conmigo, me entregó su tarjeta y me dijo que lo llamara. Pero esa historia la contaré en la siguiente parte.

El hecho es que esos encuentros abrieron la posibilidad para ingresar a mi actual trabajo, del que hablaré en los últimos capítulos de esta serie. En septiembre de 2008 me preparaba para empezar de nuevo. Hablé con Ubaldo, y nos despedimos en buenos términos, le agradecí su apoyo y oportunidad, él también me agradeció mi trabajo en conjunto y me deseo mucho éxito. Volvería a vestir traje y corbata, pero el futuro se veía desafiante, y realmente lo fue...

Notas

[1] Toda acción genera una reacción de igual intensidad en el sentido contrario. 

[2] Según este artículo de New York Times  https://www.nytimes.com/1988/07/10/magazine/heavy-metal-weighty-words.html?pagewanted=all

La primera parte de esta serie se encuentra acá:  https://www.lnds.net/blog/lnds/2019/03/17/el-fin-de-la-agilidad

When all the little ants are marching
Red and black antennae waving
They all do it the same
They all do it the same way
— Dave Mathews Band

La primera canción de Dave Mathews Band,que recuerdo haber escuchado, es una versión en vivo de “Ants Marching”, me gustó tanto que la usé en la banda sonora de un video familiar que hice de nuestras vacaciones de veranos del 2004.

Ese año fuimos a La Serena, compré la cámara de video allá mismo. Hay hermosos y divertidos momentos de mis hijos mayores jugando con Francisca, que acababa de cumplir dos años. 

No recuerdo exactamente si fue a fines de 2003 o principios de 2004 que mi amigo Marco me contactó con una idea. A esas reuniones se sumó Gustavo, un colega argentino que trabajaba con Marco. Cuando tuve la crisis,  que les conté en la parte 6, trabajé en un proyecto de factura electrónica para la empresa en la que trabajaban ellos. Yo respetaba a Gus pues me quedó claro que era un brillante y muy prolijo programador.

Marco me contó que se le había acercado un exitoso empresario, a quién yo conocía también, pues habíamos explorado negocios cuando trabajábamos en Énfasis. Su empresa representaba a la marca Handkey, que vendía un dispositivo como este:

Este aparato permite medir la geometría de la mano, lo que es muy útil para identificar personas, dentro de una población limitada. Es por esto que este artefacto empezó a ser usado en algunos clubes deportivos y gimnasios de la capital. El problema que tenía este empresario es que no podía escalar este negocio por falta de software adecuado.

Pero Marco pensó en una idea más amplia, ¿por qué no desarrollar software de plataforma que permitiera implementar servicios de identidad de personas usando biometría? [Fue así cómo elaboramos un plan de negocios que le presentamos a este señor, con el fin de crear un emprendimiento centrado en soluciones que usaran la biometría.

Nuestra propuesta de valor era más o menos la siguiente: “siempre que necesites identificar a alguien, en alguna parte de tus procesos de negocios, nosotros te entregamos la tecnología para responder tres preguntas: Quién, Dónde y Cuándo".

Así nació Biokey Technologies. A propósito decidimos usar un nombre en inglés porque lo visualizamos como una Startup que podría salir al extranjero. Nos pusimos algo siúticos, tomamos cargos en inglés, por ejemplo Gus era el Chief Technology Officer, Marco el Chief Marketing Officer y yo el Chief Operating Officer. [Nos instalamos en las oficinas de la empresa de nuestro inversionista principal, y empezamos a operar en una sala de exhibiciones. Cuando debían ocupar esa sala nosotros salíamos y nos instalábamos en la cocina o salíamos a trabajar en algún café cercano.

Los primeros meses fueron de intenso diseño. Mucha pizarra, discusiones y Marco llenaba ceniceros con sus puchos. Estudiamos y tomamos decisiones arquitecturales relevantes.

Cuando trabajas en arquitectura de software debes considerar primero el contexto en el cual operarán tus soluciones. Además debes definir ciertas metas que debe satisfacer la arquitectura. Para cumplir esos objetivos defines los principios de negocio y luego los principios técnicos que guiarán tus decisiones de arquitectura. Esto l[o voy a resumir en este diagrama:]{style="letter-spacing: 0.01rem;"}

Este diagrama es muy importante porque es la guía de trabajo del buen arquitecto de software. Si quieren saber más detalles les sugiero leer el trabajo de de Rozanski y Woods [1].

Bueno, tal cómo les dije antes nuestra propuesta de negocios era ofrecer un modo de ayudar a nuestros clientes a responder esas tres simples preguntas: ¿Quién? ¿Dónde? y ¿Cuándo?

Entonces decidimos que construiríamos una red de dispositivos biométricos distribuidos, de todo tipo y sabores. La biometría nos ayudaría a responder la pregunta del quién. La estructura de red nos permitiría responder el dónde. El cuándo era trivial, bastaba registrar el timestamp de cada transacción.

Cómo los tres teníamos experiencia previa en criptografía, y en documentos y medios de firma electrónicos, podíamos asegurar la integridad y confiabilidad de las respuestas a estas tres preguntas.

Esos eran los principios que guiaron nuestra arquitectura.

Pero una vez que tienes estos principios hay cuestiones prácticas que decidir. En particular la tecnología específica que debes usar. Fue acá donde sorprendimos a todos los que nos conocían. Decidimos usar la plataforma .Net de Microsoft.

Cuando empezamos a presentar nuestras soluciones a potenciales clientes, gente que conocía nuestro background tecnológico, les extrañaba que usáramos .Net y no Java, además que, al menos yo, éramos conocidos como fans de Java.

Una de las razones para esta decisión era totalmente práctica: la mayor parte de los dispositivos biométricos funcionaban en Windows, además tendríamos que desplegarlos en computadores con Windows. Había otra razón estratégica, queríamos formar alianza con Microsoft, algo que logramos por cierto. La tercera, la más importante, era que tanto Gus y yo teníamos ganas de aprender C#. “Si no es divertido, ¿para qué hacerlo?”

Jam Bands

Yeah
One, two, princes kneel before you
That's what I said, now
Princes, Princes who adore you
Just go ahead, now 
— Spin Doctors

El término jam bands se aplica a esos grupos cuyos conciertos en vivo generan una fuerte cultura de fans. Es un fenómeno que empezó con The Grateful Deads en los 60, y que tiene entre sus exponentes a excelentes bandas como Phish, The Alman Brothers Band, Blues Travellers, Ozryc Tentacles, Spin Doctos y por supuesto, mi favorita, Dave Mathews Band.

Es un término muy amplio que abarca diversos estilos musicales, pero algo que tienen en común que aglutina a bandas que cuentan en sus filas con grandes músicos capaces de dar un gran espectáculo en vivo, no tanto por su virtuosismo como por el sentimiento que entregan en cada performance.

Bueno, en esos años, trabajando en Biokey yo me sentía como que interpretaba la sección rítmica de una banda de jam. Con Gus nos dividimos el trabajo. Él se preocupó principalmente del frontend y yo del backend.

Los primeros meses escribimos mucho código. El objetivo era mostrar una primera versión de nuestra tecnología para una importante exposición minera.

Los recuerdos se confunden con los años, pero me parece que fue justo cuando estábamos constituyendo la empresa que tuve un accidente doméstico y caí al salir de la ducha, fracturándome el cuello del húmero izquierdo (eso es el hombro, niños). Esto me tuvo fuera de combate al menos tres meses. Me sentía frustrado, pero aún así apoyé a los muchachos en organizar las primeras labores y en el diseño.

A pesar de los problemas de partida, fuimos avanzando. Armamos pruebas de concepto. Cuando ya me recuperé empezamos la verdadera jam session. Escribíamos código y armábamos nuestra plataforma mientras Marco buscaba alianzas y prospectaba negocios.

Sin embargo, creo que caímos en uno de los errores que Roberto Camhi, en este reciente artículo llama pecados capitales. Nuestro fallo estaba en el timing. Nuestros conceptos estaban algo adelantado para la madurez del mercado chileno en el uso de la biometría en 2004. 

Sonará arrogante, sin embargo creo que ninguna empresa relevante que se dedica a la biometría en Chile tiene una propuesta tan claramente estructurada a nivel conceptual y arquitectónico como la que desarrollamos. Pero esto, por desgracias, es una confirmación de que la excelencia técnica no lo es todo para triunfar en los negocios.

En retrospectiva creo que una de nuestra principales ventajas es que invertíamos mucho tiempo en investigación. Quizás eso no le gustaba a nuestro inversionista, pero estábamos convencidos que era uno de los elementos diferenciados de nuestra propuesta.

Les daré un ejemplo de lo que hacíamos en BioKey Technologies. Nuestra plataforma ofrecía un modelo de seguridad basado en el trabajo de Ratha, Connel y Bolle, que se detalla en este paper [2]. En ese artículo estos investigadores exponen que hay ocho puntos de ataque a un sistema biométrico. Pues bien, nuestra propuesta explicaba estas ocho vulnerabilidades y proponía soluciones y mitigaciones para cada una. Ese era el rigor técnico que aplicábamos en Biokey, y tal como les dije, no lo veo mucho hoy en la industria chilena que se dedica a esto. 

What Would You Say

Knock knock on the door. Who's it for?
There's nobody in here
Look in the mirror, my friend
I don't understand at best
And cannot speak for all the rest
— Dave Mathews Band

Como en los primeros meses no lográbamos ventas de nuestros productos ejecutamos algunos proyectos que nos permitieron obtener ingresos que necesitábamos. Cómo ya gran parte de la tecnología estaba construida podíamos desviar parte de nuestra atención a resolver algunos problemas de la industria, de ese modo también estos clientes podrían más adelante comprarnos nuestras soluciones.

Sucedió que para Microsoft éramos vistos como expertos en .Net, así que nos recomendaron a una importante empresa con sede en Valparaiso a mejorar el performance de su nueva plataforma operativa web. Lo mismo hicimos con otra empresa de cable. La cantidad de aberraciones arquitectónicas que tuvimos que ver en ese tiempo dan para escribir otra serie. La transición de las aplicaciones cliente servidor a aplicaciones web, era algo que le estaba costando a los ingenieros nacionales. Microsoft no ayudaba mucho con Visual Studio y sus primera versiones del .Net Framework. Muchos programadores creían que era correcto aplicar el paradigma de respuestas a eventos de Visual Basic, y el modelo de dos capas, que imponía de cierta forma las herramientas de Microsoft. Eso cambió con el tiempo, cuando Microsoft finalmente implementó MVC, pero quizás fue algo tarde, en mi opinión, creo el daño ya estaba hecho. Nosotros usábamos C# pero de una manera distinta a lo que promovía Microsoft. Cómo veníamos de Java estructuramos nuestra arquitectura de modo muy distinto a la forma a la que te obligaba el IDE Visual Studio.

Accidente

Driving along this highway
All these cars and upon the sidewalk
People in every direction
— Dave Mathews Band

En la segunda mitad de 2005 la ansiedad me estaba comiendo. En el proyecto yo empezaba a sentirme decepcionado, no era la idea participar nuevamente en una empresa de desarrollo de proyectos. Yo había firmado para desarrollar productos y plataforma. Por otro lado, tuve que resolver algunos antiguos conflictos con mi madre y mis hermanos, que llevaron a situaciones tensas. Recuerden también que arrastraba un caos económico arrastrado de los años previos. 

Nos habíamos definido un nivel de sueldo inicial que estaba de acuerdo al plan original. Si bien era un buen ingreso, estaba por debajo de lo que todos los socios habíamos estado acostumbrado, pero lo aceptamos porque era una forma de auto motivarnos, de modo que si el negocio era bueno, si lográbamos vender nuestros productos, entonces el éxito significaría mejores sueldos.

Pero eso no estaba pasando, ya les explicaré cuál fue el error que cometimos. Lo que me ocurrió en ese tiempo fue que la ansiedad me estaba llevando a la depresión. Recuerdo que mi amigo Marco me llevó un par de veces a la clínica, pues yo pensaba que estaba con un ataque cardiaco. En realidad eran ataques de pánico. Tuve que empezar a ir al siquiatra y empezar un tratamiento. Me diagnosticaron depresión.

Para empeorar las cosas, en enero de 2006 sufrí un grave accidente automovilístico, la guadaña de la parca pasó rozándome los pelos. Estuve casi un año sin conducir después de eso. La única forma de salir adelante la encontré en la escritura. En agosto de 2005 empecé a escribir este blog, al principio era una forma de escape. Después la escritura me fue ayudando de a poco. Creo que lo principal que aprendí de ese tiempo fue que debía dejar de guardarme tanto las cosas. En Ants Marching Dave Mathews escribe:

But we never say a thing
And these crimes between us grow deeper

Aprendí que había cosas que también me guardaba, en todas mis relaciones, con mi familia, mis amigos, y en la empresa. Así que tuve que aprender a manifestarlas.

Un bolsillo lleno de kryptonita

Come on downtown and stay with me tonight
I got a pocket full of kryptonite 
 — Spin Doctors

Pero aún así seguimos investigando y desarrollando tecnología. Desarrollamos nuestra propia implementación del formato WSQ que certificamos ante el FBI. Ganamos un premio a la innovación por este trabajo por parte de la AIE. Además firmamos un convenio con las universidades chilenas en 2007 para desarrollar algoritmos que facilitaran la utilización de soluciones biométricas en Chile.

Ejecutamos varios proyectos en ese tiempo. Pero la ansiedad empezó a comernos también. Uno de los errores que cometimos también ha sido identificado por Roberto Camhi, es lo que él denomina “foco producto”. Teníamos una solución tan robusta que insistíamos en que era en eso lo que debíamos enfocarnos. Pero vender una solución, más que resolver el problema del cliente, es la razón de que muchos emprendimientos fracasen.

Empezamos a pivotear, a desarrollar soluciones de control de asistencia, o de control de identidad mucho más simples. También a desarrollar proyectos específicos. Entonces fue cuando empezaron las discusiones entre los socios. En un momento sentí que teníamos cuatro visiones distintas de cómo dirigir la empresa, eso eventualmente terminaría por dividir a la empresa. Finalmente julio de 2007 tuve una fuerte discusión con mis socios.  

Publiqué un comentario en este mismo blog, sobre una política pública que involucraba a un socio de negocios estratégico. Eso me pareció incorrecto y lo dije abiertamente. Eso fue una imprudencia de mi parte, eso es cierto. Sin embargo, significaba un conflicto ético para mí. Tenía que decidir entre seguir apoyando esa alianza de negocios, o defender mi libertad de pensar y expresar mis opiniones. Lo más duro de ese momento fueron las discusiones con mi amigo Marco. Tuvieron que pasar varios meses para que nos reconciliáramos con Marco y aclaráramos nuestras motivaciones de ese momento, ambas legítimas por cierto. Pero esa es una historia que continuará en la siguiente parte.

En la mitad de 2007 estaba nuevamente cesante. Pero aproveché mi red de contactos y les manifesté abiertamente que estaba en busca de trabajo. Recibí varios llamados, y tuve conversaciones muy interesantes. Estaba de vuelta en el mercado, y el mercado parecía tener interés por mis servicios. Así fue cómo recibí la llamada de Ubaldo, pero eso lo contaré en la octava parte.

Notas

[1] Software Systems Architecture,  Nick Rozanski, Eóin Woods [ https://amzn.to/2Xc8F4i

[2] “Enhancing security and privacy in biometrics based authentication”, [N. K. Ratha, J. H. Connell, R. M. Bolle]https://www.researchgate.net/profile/Jonathan_Connell/publication/220353130_Enhancing_Security_and_Privacy_in_Biometrics-Based_Authentication_Systems/links/555a010508ae6fd2d8281b10/Enhancing-Security-and-Privacy-in-Biometrics-Based-Authentication-Systems.pdf

La primera parte de esta serie se encuentra acá:  https://www.lnds.net/blog/lnds/2019/03/17/el-fin-de-la-agilidad

La octava parte de esta serie se encuentra acá:  https://www.lnds.net/blog/lnds/2019/04/21/el-fin-de-la-agilidad

"¿Cómo diablos llegué a este punto? ¿Qué hago acá en esta escalera en el edificio de un cliente, discutiendo con este tipo por teléfono, recibiendo sus insultos? ¡Es tiempo que lo mande a la cresta!"

Wake Up!

I’ll give you a dose but it’ll never come close to the
Rage built up inside of me
— Rage Against the Machine

En abril de 2003 estaba sin trabajo, arruinado porque llevaba varios meses sin recibir sueldo. Estaba angustiado, mi cuerpo y mi mente no respondían. Agotado y cansado. 

La salida desde la CCS había sido un completo fracaso. “Paraba la olla”, como decimos en Chile, en base a pitutos. La historia de cómo llegué a esto aún me da rabia, porque fui engañado, estafado como muchos ciudadanos, como el mismo estado de Chile.

Después de dejar la Cámara, fui a trabajar a una Startup, creada por una persona que conocí a través de CEO. Él dirigía una exitosa agencia de diseño web, tenía varios contratos importantes, la mayor parte con gobierno. Sus oficinas estaban en una hermosa casona en Providencia, donde a veces se realizaban algunos de los almuerzos con emprendedores que les conté en  la parte 5

Cuando llegué a trabajar la Startup aún no se constituía. Así que trabajé con el equipo de la agencia, reemplazando al encargado de tecnología que se había marchado. Fue ahí donde conocí a Rafa, quien era el desarrollador de la empresa. El resto eran administradores de cuentas y un par de diseñadores gráficos. Mientras se realizaba el due dilligence para recibir el capital semilla, que daría pie a la Startup, yo aproveché de conocer su tecnología, y apoyé algunos proyectos de la empresa matriz.

Cult of Personality

Look in my eyes, what do you see?
The cult of personality
— Living Colours

Recuerdo que uno de los socios tenía una agencia de modelos que compartía domicilio. No era raro ver en el segundo piso a hermosas chicas corriendo en ropa interior para cambiarse ropa durante sesiones fotográficas, para armar sus bookings. Por allí pasaron varias modelos que empezaban a ser famosas en esos momentos, por su participación en los incipientes programas llamados reality shows,  y otros programas de farándula que invadieron la televisión de la época.

Yo debí sospechar algo en ese momentos. El ambiente era muy extraño. Con Rafa trabajábamos en la parte trasera de la casa. Un día llegó un chico alemán, de unos 22 años de edad a pedir trabajo. Sabía diseñar, programar en Python y conocía una extraña plataforma llamada Zope[. Le eché un vistazo, era un servidor de contenido web muy interesante. Lo contratamos, porque había que dejar reforzada el área técnica de la agencia antes de que con Rafa migráramos.

Debo decir que al menos durante ese tiempo, cumplieron el compromiso de pagarme lo acordado. Pero estaba preocupado, porque yo no había firmado para eso, yo debía estar desarrollando software para una plataforma de juegos interactivos móviles.

Bulls on parade

The microphone explodes, shattering the molds
[— Rage Against the Machine]{style="letter-spacing: 0.01rem;"}

Cuando le preguntaron por Twitter a Tom Morello qué ciudad tiene los mejores fans, el músico respondió, Rock: Santiago, Baseball: Chicago.

Para Rage Against the Machine, uno de sus mejores conciertos fue el que se denominó  Battle of Santiago, de 2010. Su estilo que mezcla el funk, el rap con el metal, con letras políticas los ubica como uno de los mayores exponentes del Rap Metal y del Funk Metal.

La incorporación de Wakeup en la banda sonora de The Matrix me impresionó mucho, creo que dejó marcado en mi mente el mensaje de esa película, es el punto final adecuado. Lástima que no hayan hecho una segunda o tercera parte de The Matrix[1].

Dicen que la música de RATM fue usada para torturar prisioneros en Guantanamo por parte de la CIA [2]. La idea era alterarles sus nervios al poner esta música agresiva a todo volumen. Es una terrible ironía y una muestra de que el sistema es capaz de absorber todo, incluso lo que va en su contra para usarlo a su favor.

Para mí el Funk Metal está asociado a energía violenta, a esa rabia contenida que fui acumulando durante 2002 y 2003, que explotó en fuertes dolores estomacales y depresión.

Evidence

Anything you say, we know you’re guilty
— Faith no more

De repente ingresaron a esta comedia unos ejecutivos, con experiencia en retail y televisión. Serían el brazo comercial y ejecutivo de la startup.

En estos días, a principios de 2019, los emprendedores de varias startups exitosas, como Cornershop y NotCo están compartiendo su visión de cómo debe armarse una Startup, a través de una clase en la Universidad de Chile[, cuyo contenido se está haciendo público. 

Si ven el primer video de este curso tendrán la visión de uno de estos emprendedores sobre la manera de lograr una Startup exitosa. Son consejos de tomados de su propia experiencia, que al menos a él y sus socios le resultaron. Pues bien, la gente de la Startup, en la que yo estaba hizo exactamente lo contrario.

Primero armaron un directorio rimbombante, había un ex ministro, un ex director de televisión, gerentes de retail y por supuesto un representante del capitalista de riesgo.

El área de tecnología era vista como secundaria. Nos pagaban bien y nos dieron recursos para comprar equipos, pero apenas éramos dos. Apenas se me consultó por un plan informático o de desarrollo. La plataforma ya estaba lista para ellos, era cuestión de conectarla a las redes de teloperadores.

Ya es momento de que les cuente de qué diablos se trataba el negocio.

[En una reunión de CEO tuvimos de invitados a don Carlos Baradello. Este señor es actualmente un founder y administrador de un importante fondo de inversiones de riesgo en Sausalito, California. Pero en esos años él estaba a cargo de un importante área en Motorola. Visitó Chile porque esta compañía quería instalar un centro de I+D en nuestro país. Fue en ese almuerzo que varios nos dimos cuenta que el futuro era lo que se llamaba en ese tiempo “la web móvil”.

En Europa, producto de la moda de los reality shows y el auge de los SMS ya habían experiencias de televisión interactiva.  El Gran Hermano, por ejemplo, era un reality show, en donde el público podía votar usando mensajes desde sus celulares.

En 2002, estos chicos de la agencia, construyeron un prototipo para una trivia que sería usada en el mundial de futbol. Fue así que nació su idea de armar una Startup de juegos móviles usando SMS. Pero el ingeniero que había desarrollado la plataforma junto con Rafa los había abandonado. Así fue como se acercaron a mí en un almuerzo y me ofrecieron ser el CTO de esta nueva Startup.

Yo acepté, tras mi fallida negociación en la CCS. Así de repente, a fines de 2002 estaba instalando equipos en una amplia planta en un edificio en Vitacura. Era una oficina muy elegante. Compramos notebooks de gama alta. Teníamos una cafetera fancy, una asistente eficiente y simpática, unos cómodos asientos de cuero, y decenas de teléfonos celulares para probar.

Lo único malo, la única evidencia de que esto iba por un mal camino, pero yo no lo sabía, era que el inversionista se llamaba Inverlink Holding.

El Jarrón de Don Ricardo

Can you feel it, see it, hear it today?
If you can’t, then it doesn’t matter anyway
You will never understand it ‘cause it happens too fast
– Faith no more

Nos establecimos en septiembre de 2002, más o menos. Firmé un nuevo contrato, esta vez con la Startup, con el cargo de gerente de tecnología.  

Pero en noviembre los sueldos se atrasaron, lo mismo en diciembre y enero. En febrero ya no recibimos nada. Entre medio, en ese periodo no logramos ningún negocio relevante. A pesar de estar conectados con todas las empresas de telefonía celular, y las rimbombantes reuniones de directorios llenas de próceres, y el currículum de nuestros ejecutivos, no lográbamos vender mucho.

Parecía que los socios estaban más preocupados de pasar a las siguientes rondas de inversión, que de vender algo. Insisto, todo lo que no debe hacerse se hacía en esta empresa.

En febrero de 2002 se destapa el hecho de que la secretaria de Carlos Massad, director del Banco Central, le enviaba emails con información privilegiada a Enzo Bertinelli, con quien sostenía un romance. Esto desató una investigación que destapó uno de los mayores fraudes al fisco de nuestra historia. Inverlink había cometido varios delitos, y entre otras cosas obtenía fondos de manera ilícita de Corfo, con los que financiaba, entre otras cosas startups de tecnología, como aquella en la que yo estaba. Adivinen quién era uno de los directores de nuestra startup. Sí, el mismismo Enzo Bertinelli.

Fue ese tiempo, cuando se destapa el escándalo en CORFO, que afectaba a su yerno, que el presidente Lagos pronuncia su famosa teoría del jarrón:

“Acá no se ha perdido un peso del Estado de Chile. Si usted tiene un jarrón en su casa y entra un ladrón y se lo roba, cuando descubran el jarrón se lo van a devolver”

El problema es que el jarrón estaba roto. Y yo estaba en dentro de los fragmentos. 

Ni siquiera alcancé a renunciar. Un día al llegar a nuestro trabajo nos encontramos con la puerta cerrada, sellada, con cadenas y candados. Nos miramos con la secretaria y el Rafa. No había nadie más. Fuimos a tomarnos un café, nos despedimos, nos deseamos buena suerte y nos fuimos a la casa. Así como tantos otros empleados de las empresas Inverlink, las que iban desde pequeñas startups tecnológicas, pasando por compañías de seguro y de inversión, hasta una importante clínica de salud. Más de tres mil personas nos quedamos sin trabajo por culpa del jarrón robado, y nunca fuimos compensados. [3]

Reboot

Can’t stop, addicted to the shindig — Red Hot Chili Peppers

¿Recuerdan al joven alemán que habíamos contratado? Un día viernes nos visitó a nuestras oficinas de Vitacura. Él se había quedado a cargo de mantener los sitios de la agencia. Conversamos mucho. Era un chico agradable, inteligente. Había llegado a Chile por amor, nos contaba que tenía pensado volver a retomar sus estudios en Alemania en unos meses más. Nos despedimos ese viernes. El lunes me cuentan que estaba internado en la clínica en coma. El martes falleció de un accidente vascular cerebral. Tenía un tumor que no había sido diagnosticado. La noticia me impactó fuertemente. Fue devastador, recuerdo, me dio mucha pena ese hecho.

Como no tenía trabajo sobreviví participando en algunos proyectos freelance, en empresas de amigos.

En abril de ese año se me acerca Jorge, que actuó de gerente de la Startup para plantearme que había una empresa que estaba interesada en desarrollar tecnología móvil para logística. Yo tenía buena relación con él, porque fue el único que dio la cara durante la crisis finalmente, y trato de  ayudarnos. Además que lo respetaba por su gran inteligencia y honestidad.

El financiamiento en esta ocasión venía de una importante  empresa naviera nacional. Fue así que se armó una empresa que llamaron Inphone. Curioso y premonitor nombre. Era una pequeña Startup que aprovecharía los mensajes SMS para coordinar rutas, hacer seguimiento de flotas, y cualquier cosa que se nos ocurriera aprovechando SMS y las tecnologías de datos sobre GSM y GPRS, y que tuviera sentido para el mundo de la logística naviera.

Pero por alguna razón, algo torpe en mi opinión, también decidieron incursionar al inicio en el marketing móvil. Yo sentí que eso nos desenfocaría, pero me argumentaron que era algo que podía darnos ingresos rápidos. Me ofrecieron una pequeña participación en la propiedad. Lo bueno que esta empresa al ser parte del holding de la naviera nos permitió recibir los mismos beneficios que sus empleados y ejecutivos. Creo que nunca tuve beneficios mejores después. 

De algún modo de todo esto se enteró el dueño de la fracasada Startup y fue allí cuando recibí una llamada suya. Quizás la conversación por teléfono más desagradable de mi vida. 

Se pasó el rollo de que yo le estaba robando la tecnología. Me insultó y yo lo mandé a buena parte. Nunca más nos vimos hasta varios años después, ocasión en que ni siquiera nos saludamos. Supongo que él piensa aún que le robé la tecnología, una tecnología que él nunca programó, por supuesto. 

Pero de todas maneras no fue así, por dos razones muy simples. Primero no tenía acceso a nada porque mi notebook y los servidores quedaron atrapados tras esas cadenas en aquella oficina de Vitacura. La otra razón es que nunca me gustó su tecnología, desarrollada en Perl con Apache, ni siquiera tenían un ESME[3]. Si lograron conectarse a las operadoras móviles fue porque pude construir un Gateway que permitía que su aplicación conversara con las redes de telefonía.

Barcos y Fiordos

Just one note
Could make me float
Could make me float away
— Red Hot Chili Peppers

En Inphone yo construí toda la tecnología que se desarrolló, porque yo era todo el departamento TI.

[Primero armé una plataforma de marketing digital en Java. También escribí un ESME bastante decente en java, basado en un proyecto opensource.]{style="letter-spacing: 0.01rem;"}\

Pero lo más entretenido que hice fue trabajar con unos GPS Inmarsat, que se usaban en los barcos que recorrían los fiordos del sur de Chile. 

Estos GPS tenían un buffer de 64 Bytes que podía se usado para transmitir mensajes. Construí una aplicación que permitía enviar mensajes pre codificados (cosas como: “entramos a puerto”, “se entregó carga”, “detenidos por mal tiempo”, etc.). Reservamos 4 bytes para los mensajes pre codificados (eso da un potencial de más de 4 mil millones de mensajes posible, creo que era más que suficiente). Los otro 60 bytes se usaron para enviar un breve texto.

El Capitan del barco tenía un notebook conectado al GPS inmarsat a través de la puerta serial. En la interfaz de usuario, una aplicación Windows escrita en Delphi, seleccionaba el mensaje pre codificado. Luego agregaba un texto si era necesario, y presionaba un botón para despachar el mensaje.

En Valparaiso un servidor visitaba periódicamente los servidores de Inmarsat y descargaba los mensajes desde los barcos que se recibían mediante archivos a través de FTP. Se descodificaban y se colocaban en un dashboard también en Delphi. El operador central podía enviar instrucciones de vuelta al barco de manera codificada de la misma manera, usando esos 4 bytes.

La codificación de mensajes e instrucciones las configuraba un operador y si se necesitaba agregar información debía repartir la tabla de mensajes a cada barco.

Todo esto se hacía porque en algunos fiordos no había señal de radio y el GPS era el único medio de comunicación.

Fue uno de los proyectos más entretenidos en los que he participado, y una de las cosas que más me satisface fue haberlo construido todo desde cero. Requirió programar a bajo nivel, para manejar la puerta serial y el protocolo de comunicaciones con el GPS, algo que ya había hecho en mi pasada por Enfasis. Tenía algo de mensajería móvil y además construí unos dashboard para informar estados y métricas de los barcos.

¿Me creerán que armé todo eso en menos de un mes?

Cuando estás concentrado y trabajando sólo, cuando todas las decisiones son tuyas, el código puede fluir muy rápido, pero además puedes sorprender a tu cliente superando sus expectativas. Y esto es muy relevante. Equipos pequeños, incluso una sola persona, pueden ser muy eficientes. Lo importante es que las personas sean talentosas, tengan claro qué quieren hacer y tengan espacio y tiempo para enfocarse. Eso es esencial para lograr verdadero desarrollo ágil.

Ignoro por cuanto tiempo se siguió usando esta solución, supongo que no mucho, la tecnología de comunicaciones satelitales se desarrolló muy rápido. Pero aún así, creo que es una de las soluciones más ingeniosas que he programado.

Pero a pesar de los beneficios de trabajar para la naviera, estaba sólo en ese trabajo. Pasaba días sin ningún colega en nuestra pequeña oficina cerca del metro Tobalaba. 

En la empresa éramos apenas tres. El gerente, un encargado comercial y yo que realizaba toda la ingeniería.

No estaba satisfecho, al contrario, me sentía muy deprimido. Quería emigrar, hacer cosas nuevas y trabajar en equipo con colegas que me entendieran.

Fue entonces recibí la llamada de mi amigo Marco, a principios de 2004, en que me invitaba aventurarme en el mundo de la biometría. Eso se los contaré en la séptima parte.

Notas:

[1]la leyenda urbana dice que hay dos películas que siguieron después, no sé si las vi, y si las vi prefiero olvidarlas.

[2] Pueden leer más datos interesantes sobre RATM en este hilo de Twitter: https://twitter.com/conarebo/status/1114312594066694146

[3] Pese a que hay un fallo que dice que se deben de devolver miles de millones de dólares al estado chileno, me pregunto si se se ha recuperado algo de esa pérdida. 

[4] un ESME es un servidor que permite conectar servicios TCP/IP a una red basada en SMS  https://en.wikipedia.org/wiki/External_Short_Messaging_Entity.

La primera parte de esta serie está acá:  https://www.lnds.net/blog/lnds/2019/03/17/el-fin-de-la-agilidad

La parte 7, continuación de este episodio está acá:  http://www.prosa.io/blog/lnds/2019/04/14/el-fin-de-la-agilidad

I’m going to Wichita
Far from this opera for evermore
I’m gonna work the straw
Make the sweat drip out of every pore 
— The White Stripes

Cuando estaba en el colegio formé parte de una banda en que tocábamos rock latino. Participábamos en fiestas y eventos en Chuquicamata y Calama. Varios años después todos los miembros del grupo estábamos en Santiago, así que nos juntamos por unos meses a ensayar, en un garaje o bodeguita, no recuerdo bien, en la casa del padre de nuestro segundo guitarrista. 

La idea era llegar a tocar en algún pub de la capital. Pero la idea no prosperó. Nos separamos y por años no nos volvimos a juntar, hasta que llegó agosto de 2000, y les propuse improvisar algo para mi matrimonio. Fue nuestra peor presentación, pero al final completamos un par de canciones de Miguel Mateos, tocadas al estilo de los White Stripes, sólo con una guitarra y batería. Con eso salvamos la noche.

CEO

Los meses pasaron, y llegó 2001, la burbuja de internet y la locura de todos por emprender algo en la web. En esa época un cuñado, que asesoraba a Conicyt, me contó que pensaban invitar a “jóvenes veteranos de la internet” para una reunión y explorar actividades para organizar en conjunto. Me pidió algunos nombres, y le indiqué que me interesaba participar también. 

Así fue que un día de 2001 estábamos en la oficina de Eric Goles, premio nacional de ciencias exactas, académico y por entonces el director de Conicyt. Recuerdo que una pared  tenía colgado un hermoso cuadro de gran formato. Una pintura moderna que mostraba la Máquina y el rostro de Alan Turing, y por supuesto una manzana a medio masticar, todo en una composición moderna y bien lograda. Estaba firmada por un artista reconocido. Goles nos contó cómo había solicitado esa pieza y luego nos empezó a relatar la historia de Turing, un acto un tanto innecesario, porque casi todos los que estábamos en esa oficina ese día éramos ex alumnos suyo, y además teníamos bien clara la historia de Turing. Pero así era él, así que había que tener paciencia. (Por esa época Eric Goles tuvo un programa de divulgación en televisión, así que supongo que tenía vocación de ser el Carl Sagan chileno, yo que sé).

Fue así que con los meses este grupo mantuvo la costumbre de juntarse a almorzar con cierta periodicidad, almuerzos al que invitábamos a emprendedores, autoridades, y personas interesadas en desarrollar un clima de emprendimiento en Chile. Nos independizamos de la organización estatal y sostuvimos estas actividades en la sede de la empresa de uno de los miembros del grupo.

De esos almuerzos nació CEO: Clima de Emprendimiento Organizado. Todos en nuestro interior sentíamos que algo relevante saldría de estas reuniones, pero el gran logro fue mantener esos encuentros por varios años.

El tiempo pasó, el 11 de septiembre de 2001 nos impactó a todos, y con este evento comenzó, en mi opinión, la época en la que vivimos, con sus luchas contra el terrorismo, fake news, desconfianza y la falta de paciencia.

Post Punk Revival

I say don’t you know
You say you don’t know
I say, take me out!
— Franz Ferdinand

El  Post Punk Revival, o Garage Rock Revival, fue un movimiento que partió a fines de los noventa y se extendió en los primeros años del 2000. Tomaban la influencia del grunge, el new wave, el blues y el punk. Mezcla interesante, con bandas como White Stripes, Franz Ferdinand, Elastica o Artcic Monkeys.

[Pienso que no es casualidad que White Stripes haya elegido usar los colores rojos y blanco e inventarse una historia de origen que los identificaba con la norteamérica profunda. O que Franz Ferdinand usara el nombre del archiduque de Austria, cuyo asesinato llevó a la primera guerra mundial. Este estilo musical, con sus letras y estéticas reflejaban el inicio de nuestra era contemporánea, con sus invasiones a Medio Oriente, y búsqueda de armas de destrucción masiva que nunca existieron.]{style="letter-spacing: 0.01rem;"}

Noviembre 2001

Hate to say I told you so, alright
Come on
I do believe I told you so
– The Hives

Quizás uno de los momentos más felices de mi vida fue el nacimiento de mi hija Francisca, a fines de noviembre de 2001. Sostenerla en mis brazos fue un momento de dicha total difícil de superar.

Pero esta linda historia personal pudo haberse convertido en un relato dramático digno de Charles Dickens. Después del parto hubo complicaciones inesperadas y Kika tuvo que permanecer varios días en la clínica. Fueron momentos difíciles y de mucha incerteza. Durante un mes mi deber era con mi mujer y mi hija, por sobre todo y estuve en la clínica durante todo ese tiempo sin ir a trabajar.

Recuerdo que de la Isapre,  que tenía contratada en ese momento, me visitó una ejecutiva y me dijo que ya nada podíamos hacer porque yo no había solicitado el seguro catastrófico a tiempo. ¿Pueden entender eso? 

[En ese momento en que estaba preocupado porque mi mujer pasaba la noche en la UCI. Momentos en que pedía que me pasaran a la bebé para alimentarla y abrazarla mientras caían lágrimas de mis ojos, porque estaba desesperado y no sabía qué podía suceder. En esos instantes el sistema me pedía que llenara un formulario, ¿para activar un puto seguro catastrófico? ¿Acaso no puede ser eso automático? O si se solicita ex post, cuando ya la situación se ha calmado un poco, ¿no pueden reconocerlo? 

Esos son los bugs que en nuestra legislación dejan nuestros representantes y que terminan perjudicando a las personas, aumentando este clima de desconfianza en todo y en todos, que caracteriza nuestro tiempo.

Leaving Las Vegas

I’m standing in the middle of the desert
Waiting for my ship to come in
— Sherryl Crow

Llegamos a casa, con la bebé y mi esposa recuperándose del duro trance. Por meses debía seguir tratamientos y apoyo. Pero fue mejorando rápidamente. La bebé empezaba a crecer y a recibir el amor de sus hermanos mayores.

Sin embargo yo no estaba tranquilo. Estaba endeudado y tampoco  muy conforme con mi sueldo. Y el clima de esa época era de emprendimiento. Había observado a muchos amigos “pegarse el salto”. Un colega subgerente se retiró de la cámara a armar su propio emprendimiento.

Fue así cómo recibí una oferta interesante de uno de los participantes de CEO. Estaría a cargo de formar el área de tecnología de su emprendimiento. La oferta era por casi un 30% adicional a lo que ganaba en ese entonces. Hablé con mi jefe. Yo aún no estaba convencido de querer irme del todo, porque significaba un riesgo, así que esperaba que me hicieran una contra oferta, después de todo había sido bastante exitoso y había aportado mucho en mi trabajo.

Mi jefe reaccionó y se movió como corresponde. Yo sentí que él no quería dejarme partir, y siempre se lo agradeceré. Pero le fue mal. Parece que para el resto de la organización yo no era tan valioso. La contra oferta fue ridícula, Jorge me la planteó con algo de decepción y vergüenza, creo yo.

Así fue como empecé mi salida de la Cámara de Comercio de Santiago. Pero en ese tiempo no sentí pena, al contrario, me dio rabia. Mi salida fue bien precipitada, en pocos días estaba en otra empresa preparando el camino para empezar una nueva Startup.

Ambientes Tóxicos

Due to lack of interest
Tomorrow is cancelled
– Kaiser Chiefs

Hay veces que una filtración de material tóxico empieza a envenenar un río, o laguna. Puede que la filtración sea pequeña, pero es sostenida. 

Eso pasa en las organizaciones. Hay filtraciones tóxicas que no tapamos a tiempo. Estas toxicidades se dan entre las personas y sus relaciones. No todos tienen que caerse bien en una empresa, pero, en mi opinión, es deber de quienes dirigen las organizaciones evitar que se produzcan estas fugas de toxicidad.

Yo sentí eso en ese tiempo. Sabía que no le caía bien a algunas personas de la organización en que trabajé hasta ese momento. Lo complicado es cuando no le caes bien a personas que tienen poder. No sé si a nivel consciente o inconsciente eso se me hacía insoportable también. 

Hay que aprender a manejarse dentro de las organizaciones. A conocer sus dinámicas, su política. Toda organización humana es política. Muchos jóvenes no entienden eso. Creen que todo se trata del mérito técnico, pero eso muchas veces es lo menos importante en el desarrollo de una carrera.

En toda organización hay facciones, con intereses particulares. Eso es normal, e incluso sano. Siempre he sospechado de un grupo humano donde todo es cordialidad y nadie está en desacuerdo. 

Lo importante, y la clave del liderazgo en mi opinión, es que a pesar de estas diferencias, todos estén alineados en pos de la misión y visión de la empresa. Cuando los intereses personales, o de las facciones, se alejan del camino trazado es cuándo empieza la decadencia de las instituciones. Es cuando la gente decide alejarse y buscar otros horizontes.

Así fue cuando en 2002 estaba adentrándome a la época más oscura de mi vida profesional, pero no lo sabía. Contaba con el apoyo de mi esposa, una hermosa bebé y mis hijos. Sin ellos no sé como habría sobrevivido a lo que vendría después, pero eso es algo que les contaré en la siguiente parte.

Notas:

Sherryl Crow no pertenece al movimiento Garage Rock Revival, pero su canción Leaving Las Vegas tiene el verso adecuado, así que perdón a los puristas.

La primer parte de esta “autobiografía no autorizada” la encuentras acá:  https://www.lnds.net/blog/lnds/2019/03/17/el-fin-de-la-agilidad.

La segunda parte:  https://www.lnds.net/blog/lnds/2019/03/18/el-fin-de-la-agilidad.

Tercera parte:  https://www.lnds.net/blog/lnds/2019/03/19/el-fin-de-la-agilidad.

Cuarta parte:  https://www.lnds.net/blog/lnds/2019/03/23/el-fin-de-la-agilidad.

Sexta parte:  https://www.lnds.net/blog/lnds/2019/04/06/el-fin-de-la-agilidad