Archivos de Categoría: Blog 1

Sí, me temo que he perdido demasiado el tiempo a lo largo de mi vida. Empiezo a tener la sospecha, probablemente muy fundada, de que he perdido excesivo tiempo en lo que luego resultaron ser de poca utilidad (o simplemente y llanamente tonterías) para el entorno profesional. Al menos en su versión extendida 😀

Primero me pasó con los patrones de diseño. Leía todo sobre ellos. Cuando descubrí en la Universidad el libro de The Gang of Four sobre patrones a usar en la programación, quería usarlos todos, demostrar que los conocía, que todo el mundo viera lo brillantemente diseñada que estaban mis aplicaciones.

Los usaba fueran útiles o no, fueran necesarios o no, y lo que es peor, tanto si los entendía como si no. Se trataba de incluir el máximo número posible para demostrar solvencia y criterio.

Afortunadamente, esto se me pasó con el tiempo, y entendí muy bien lo que había pasado cuando años después leí sobre los millones de dólares empleados por las empresas en refactorizar su base código para eliminar diseños confusos e innecesariamente complejos que solo hacían más difícil que la gente supiera qué diablos prentendía hacer aquello.

Me ha pasado también con otras cosas, la reflexión en el código o los algorimos de ordenación, pero fue lo mismo con Agile y con Scrum.

Agile ha sido una gran ayuda profesional. No creo que nada me haya ayudado tanto en mis proyectos como la agilidad, pero me temo que me habría bastado con saber 4 o 5 principios y valores básico y luego tratar de ponerlo en práctica. Eso habría sido suficiente.

Sin embargo, el resto, todo lo que rodeó a eso, las ceremonias, las preguntas en las dailies, las discusiones si mencionabas la palabra «proyecto», si eras Agile de pura cepa y 5 jotas o no porque habías escrito la tarea a realizar en castellano simple y llano y no habías escrito una historia de usuario con el formato Connextra (Como usuario x, quiero la app hay y, de forma que obtenga z).

Más me habría valido aplicar el principio de Pareto, dedicar un tiempo a aprender las bases de la nueva moda del momento, y luego aprovechar el resto del tiempo a cosas más importantes.

Quién no se ha visto alguna vez tratando de sustituir un sistema viejo? Una forma de trabajar que ya no aguanta cambios, al que ya no le valen un simple trabajo de pintura para seguir adelante.

He estado leyendo últimamente sobre un patrón para afrontar estos cambios: el Strangler Fig pattern (el patrón de la higuera estranguladora) del que habla Martin Fowler en https://lnkd.in/ezBrWa6h

Este tipo de planta pone una semilla en la copa de otros árboles, comienza echando raíces hasta el suelo de forma que, con el tiempo y poco a poco, termina sustituyendo al árbol original que queda hueco en el interior de este tipo de Ficus.

En IT este patrón trata de hacer lo mismo, poner un proxy al frente de la vieja aplicación que derive, rama a rama, endpoint a enpoint, las llamadas originales hacia el nuevo servicio, construido con nuevas tecnologías y en la nube, dejando a la vieja aplicación hueca y sin uso.

Con cada funcionalidad que sustituyas aprendes, revisas y mejoras. Por otro lado, tampoco causas un gran cataclismo en la empresa al hacer un cambio drástico, de golpe, hacia un nuevo sistema que quizás no está lo suficientemente maduro como para soportar todo el peso de una compañía.

Cuando se trabaja en equipo notas bastante pronto qué compañeros son los que resuelven de forma más eficiente, los que te sacan de apuros ante cualquier asunto, los que tienen Acabativa como los llama Yoriento. No son los más inteligentes, ni los más experimentados ni los que tienen un título universitario de renombre. Son los más decididos, los que se deciden a empezar a cortar y tomar resoluciones. Los que se ponen el cuchillo en la boca y empiezan a avanzar, encuentren lo que encuentren.

En una gran número de ocasiones no queremos empezar a atacar un problema hasta no tener todos los datos, hasta no saber seguro qué hacer. El problema es que nunca podrás estar seguro. Solo estás buscando excusas en tu mente para empezar a trabajar fuerte en ello (mañana, cuando esté el tech lead será mejor día, seguro), para no decidirte por una de las opciones, y por tanto no correr el riesgo de equivocarte.

Mucho me temo que te vas a equivocar, tanto si lo pospones a mañana, a principios de mes, o al Q1, como si retrasarlo tu fuese a garantizar una ejecución perfecta. Pero no, casi nunca sabrás de antemano cuál es la mejor opción. Escoge la opción más «económica», la de menor coste o haz una prueba piloto/PoC, y mira los resultados. Seguro que aprenderás mucho más de ello que buscando excusas mentales para justificar por qué justo hoy no es buen día para empezar a teclear/diseñar/probar/construir.

Tampoco lo conviertas en un Spike eterno. Estos spikes o pruebas/investigación sobre un asunto han sido uno de los grandes males de Agile y los equipos de desarrollo. Suelen ser la excusa perfecta para darte tranquilidad mental y pensar que lo estás mirando, que estás en ello pero que todavía necesitas comprobar esto o aquello. Estas tareas de investigación deberían estar prohibidas si no entregan al finalizar un trabajo tangible, unas líneas de código o unos diagramas. Lo que sea que quiera que hagas, pero asegúrate de que te ayudan a atajar el problema, o incluso mejor, a descartar opciones.

Haz un premortem de tus proyectos para que te pongas en lo más negativo y así luches para que las cosas salgan bien.

El pensamiento positivo puede hacer que nos confiemos e idealicemos los resultados de nuestro trabajo o abandonemos a las primeras de cambio porque las cosas no van saliendo tan bien como pintaban. En cambio, imaginar todos los obstáculos de un proyecto hará que nos preparemos para resolverlos y amortigüemos los golpes antes de que ocurran.

Haciendo un premortem antes de empezar y calculando todo lo que puede salir mal nos va a acercar un poco más a nuestra metas. Habrá gente a la que no le guste que se esté dando una visión negativa del reluciente nuevo proyecto que se va a empezar, pero será mucho peor si al final las cosas empiezan a torcerse y no nos pilla preparados.

Te puedo asegurar que muchos de los obstáculos que habías previsto en el premorten terminarán pasando, pero además habrá otros muchos que ni siquiera se te pasaron por la cabeza cuando lo hiciste y te harán pasar un mal rato. Nada hay tan fácil que no pueda hacerse mal.

Extracto del libro Thinking in bets:

Despite the popular wisdom that we achieve success through positive visualization, it turns out that incorporating negative visualization makes us more likely to achieve our goals. Gabriele Oettingen, professor of psychology at NYU and author of Rethinking Positive Thinking: Inside the New Science of Motivation, has conducted over twenty years of research, consistently finding that people who imagine obstacles in the way of reaching their goals are more likely to achieve success, a process she has called “mental contrasting.” Her first study, of women enrolled in a weight-loss program, found that subjects “who had strong positive fantasies about slimming down . . . lost twenty-four pounds less than those who pictured themselves more negatively. Dreaming about achieving a goal apparently didn’t help that goal come to fruition. It impeded it from happening. The starry-eyed dreamers in the study were less energized to behave in ways that helped them lose weight.

Thinking in bets by Annie Duke

Hace como 1000 años (año arriba, año abajo) trabajaba en una Creamery de queso Blue Stilton en el centro de Inglaterra, una fábrica que producía y envasaba quesos azules en distintos formatos. Tenía que pagar el alquiler mientras me salía un trabajo como desarrollador de software.

Estaba en mi puesto de operario al final de una de las líneas de producción, y notaba que la máquina iba más rápido que yo. Recogía y etiquetaba cada pieza, pero al poco otra llegaba y se queda al borde de caer al suelo. Incrementaba la velocidad para evitarlo, pero de nuevo otra pieza corría el mismo riesgo. Volvía a recogerla en el último instante, y seguí así todo el tiempo que pude, recogiendo, etiquetando y colocando cada vez más y más rápido. La línea de producción no paraba, no importaba a la velocidad que fuera: ahora docenas de trozos de queso se apilaban esperando que los atendiera.

Cuanto más rápido iba, más trabajo había. Llegó un punto en el que ya no coordinaba mis movimientos. Pedí ayuda para parar la máquina antes de que todo aquello llegara al suelo Con todo el ruido en la fábrica nadie me oyó. Cuando no pude más, levanté las manos para intentar contener el río de envases que fluía por la línea, y en ese momento todo se paró.

No me había dado cuenta de que al final de la línea de trabajo había un sensor que, como en las cajas de los supermercados, paraba el movimiento si el último queso seguía allí sin ser atendido. Si yo recogía un envase, otro se ponía en su lugar inmediatamente después, y otro y luego otro. No importaba lo rápido o lento que fuera.

Esa misma sensación de estar haciendo el «tonto» la tuve mucho después, cuando al llegar al trabajo después del fin de semana, me encuentro docenas de correos en mi carpeta de entrada. Comienzo a responder tan rápido como puedo cada uno de ellos intentando dejar la bandeja límpia de nuevo y poder atender con tranquilidad las reuniones de mediodía.

Sin embargo, horas después, cuando creo haber terminado me encuentro otro montón de correos que han llegado nuevos. Son las respuestas a los correos a los que había estado enviando durante toda la mañana. Unos me pedían clarificación, otros solo me daban las gracias, pero algunos me apremiaban aún más. El atasco en la bandeja de correos lo estaba causando yo.

Podía haber seguido atendiendo la bandeja de correos otro par de horas, pero de nuevo tendría una pila de emails nueva. No es la bandeja de correos, ni el chat, la que debe dirigir tu trabajo. Vas a tener que priorizar lo urgente, pero sobre todo lo importante, y no dejarte llevar por el resto o no completarás nunca nada relevante de verdad. Solo estarás ocupado (muy ocupado!), pero la máquina no va a parar de entregarte nuevos trozos de queso para que les pongas una etiqueta.