Tiempo

Quizás hoy estoy particularmente sensible. Releer sobre Applicative me tocó el corazoncito técnico.

Escribir software así es simple. El reto es que la carga cognitiva es brutal. A un dev sin experiencia le puede tomar hasta 8 meses de estudio y práctica seguidos dominar esto con confianza. Un dev con experiencia le puede tomar fácilmente 4 meses.

¿Es el tiempo el criterio adecuado en todos los casos para evaluar una forma de escribir software? Si estoy pensando en mis inversionistas, seguro. Si pienso en el producto que quiero construir ¿también?

Se puede usar cualquier herramienta (lenguaje, framework, etc) para implementar cualquier requerimiento funcional. ¿Qué criterios usar entonces para encontrar la herramienta adecuada?

Pienso que de alguna manera es una relación inversa entre tiempo, el tipo de producto que quiero construir y el estado de madurez de un equipo.

Por ejemplo, usualmente, cuando inicio un proyecto de software con un equipo nuevo, restrinjo a que sus iteraciones sean de máximo 1 semana por los primeros meses. Eso implica que el equipo se somete a una intoxicación de ceremonias y prácticas por un tiempo. ¿Por qué? Porque es la manera más eficiente que he encontrado de que le cojan fastidio a Scrum y se empiecen a cuestionar qué es lo que realmente les genera valor como equipo. De esta manera se obligan a conocerse como equipo.

A medida que el producto va saliendo cada vez más frecuentemente a producción y el equipo va demostrando madurez, les hago caer en cuenta de que iteraciones de 2 o 3 semanas son muy cortas y les cuestiono la diferencia entre entregar iteraciones a entregar productos de software.

De ahí caemos, normalmente, a ciclos de 6 semanas (muy a la ShapeUp, curiosamente) donde las ceremonias pierden sentido y, aprovechando que la memoria muscular del equipo ha venido siendo entrenada por los psicólogos del desempeño, se puede fomentar a que el objetivo final sea entregar un producto de software completo.

Este estadio de madurez es valioso porque son equipos de 3 a 4 personas, que son responsables de entregar todas las capas de un producto digital. Eso implica calidad de software, infraestructura, UX, UI y desarrollo de clientes y servicios.

Este acercamiento lleva a que el equipo se obsesione por entregar su producto en 6 semanas y no entregando versiones de un “algo” cada Sprint. No obstante, llegar a este estadio toma tiempo, requiere muchísimo entrenamiento e inversión.

Con este ejemplo intento poner en consideración del lector la trascendencia del criterio tiempo. Como describí, un equipo pasa por diferentes estadios que le permiten ir mejorando lo que entrega y cómo funciona. ¿Pasaría lo mismo con los lenguaje de programación? Es decir ¿se podría entender la elección de tecnologías y herramientas -como el lenguaje de programación- como una variable dinámica que muta y oscila a medida que el equipo madura?

Conozco y practico la arquitectura evolutiva, pero lo que me cuestiono acá es diferente. Así como lo expliqué en el frente metodológico ¿deberíamos tener prácticas y tecnologías diferentes en la medida en la que el equipo y el producto evolucionan?

Por ejemplo, un lenguaje que históricamente ha demostrado que permite implementar aplicaciones Web muy rápido es PHP.

Eso implica que uno esperaría que un equipo sin mucha experiencia pueda entregar requerimientos funcionales muy rápido en esa tecnología. Creo que golang y python está en el mismo nivel de PHP: permiten ser productivos en plazos muy cortos debido a que la curva de aprendizaje es muy corta. Son herramientas diseñadas para ser fáciles de aprender.

El hecho de que esos lenguajes demuestren ser tan productivos en las etapas tempranas del desarrollo de un producto ¿implica que son herramientas más adecuadas de hacer software? Desde el punto de vista del inversionista sí porque tiempo es dinero, baby. ¿Desde el punto de vista del equipo? ¿Desde el punto de vista del producto?

La exploración que estoy proponiendo es que así como un equipo necesita unas formas de trabajo que cambian, así mismo las tecnologías y patrones arquitectónicos deben ir mutando en el tiempo. De esta manera, se le puede sacar el mejor provecho a estas tecnologías fáciles de aprender pero que, por lo general, terminan generando algún tipo de deuda en alguna otra parte.

Luego, a medida que el producto y el equipo van madurando, se puede pensar en tener acercamientos más simples pero menos fáciles como la programación funcional.

Quizás eso mismo pasa con algunos devs, iniciamos con lenguajes fáciles y terminamos deshilvanándonos la cabeza con teoría de categorías a medida que vamos adquiriendo maestría en nuestro oficio para hacer las cosas más simples.