Este blog etsá inspirado en la charla de Perla para la XConf Norteamérica 2022
El Radar se estableció originalmente como una solución de gestión del conocimiento. Se diseñó como una forma de comprender las experiencias de los trabajadores de Thoughtworks en todas las regiones, clientes, industrias y tecnologías. Y aunque los lectores de Thoughtworks y del Radar han crecido y evolucionado, seguimos creando el Radar en colaboración con una perspectiva global: hacemos una convocatoria en toda la empresa para recomendaciones de "blips" y animamos a que haya representación de todos los países en los que tenemos una oficina. (Un "blip" es la palabra que utilizamos para referirnos a un único elemento del Radar). A menudo recibimos recomendaciones similares sobre una tecnología desde extremos opuestos del mundo.
Dado que el Radar se basa en las experiencias de los trabajadores de Thoughtworks, es difícil negar que se trata de una guía con opinión. Pero más que eso, también se basa en la cultura de Thoughtworks. Todo el mundo en la organización es un apasionado de la tecnología - las opiniones fuertes son siempre alentadas. Esto significa que nuestras perspectivas, prejuicios y creencias están siempre presentes en el Tech Radar. Lo consideramos un punto fuerte. En este post exploraré algunos de ellos, dando una visión de algunos de los aspectos más interesantes del Radar en la última década y lo que demuestra sobre el Radar.Learning from our mistakes
Una parte de nuestra cultura consiste en admitir que a veces nos equivocamos. El Radar dedica el anillo Hold a las tecnologías que utilizamos pero con las que finalmente no tuvimos una buena experiencia. Al compartir nuestra experiencia, esperamos que otros aprendan de ella y eviten problemas similares o comprendan mejor las limitaciones existentes.
Con motivo del décimo aniversario de Radar, hemos reflexionado sobre algunos de los grandes errores de Radar. Uno de mis favoritos es el final de la vida de Java. En 2011, la compra de Sun por Oracle creó una incertidumbre considerable en el sector; queríamos asegurarnos de advertir a los lectores del Radar de que el final de la vida de Java era una posibilidad que merecía la pena considerar y para la que había que prepararse. Sin embargo, nuestros temores no se cumplieron: Java no sólo sigue existiendo, sino que sigue siendo muy popular. Es el lenguaje orientado a objetos con el que tengo más experiencia profesional y el primero que recomiendo a mis mentores. Aunque la idea del fin de la vida de Java parece remota, en aquel momento era un riesgo en el que merecía la pena pensar. Es un recordatorio importante de que, aunque los riesgos no siempre se materializan, sigue mereciendo la pena estar preparado.
En 2012, también incluimos Experience Design en Assess. En retrospectiva, parece pintoresco: el diseño de experiencias es hoy una parte enorme del desarrollo de software y del diseño de productos. La idea de que pudiera abarcarse en un solo blip corto parece extraña. En realidad, esto nos llevó a reflexionar: enseguida nos dimos cuenta de que el Radar no sólo debía debatirse con los desarrolladores. Al fin y al cabo, tecnólogos ≠ desarrolladores. Esta es una de las razones por las que ahora llevamos a cabo un amplio proceso de comentarios antes de publicar el volumen final.
Siempre es interesante cuando nos equivocamos, pero me gustaría señalar que también aprendemos de nuestras victorias; a veces acertamos. El anillo Adoptar está dedicado a nuestras experiencias positivas con la tecnología. Los fallos de este anillo siempre requieren experiencia de producción y nuestros equipos suelen consultarlos y utilizarlos a la hora de tomar decisiones tecnológicas.
No existen las balas de plata
Siguiendo con el tema de que a veces acertamos y a veces nos equivocamos, me gustaría presentarte la respuesta favorita de un tecnólogo a una pregunta: "depende".
Tanto en consultoría como en tecnología, la respuesta suele ser "depende": no existe una bala de plata. Cuando me uní a Thoughtworks tuve la oportunidad de recibir formación en nuestro programa Thoughtworks University; a los formadores parecía encantarles responder a las preguntas con "depende". En aquel momento me pareció una broma pesada, pero pronto me di cuenta de que no lo era. Es importante, y a menudo crítico, considerar en detalle los entresijos de cada escenario antes de tomar una decisión sobre cómo avanzar; al fin y al cabo, no hay dos desarrolladores iguales, ni dos arquitecturas iguales, ni dos empresas iguales. Siempre hay compensaciones que hay que tener en cuenta.
Vemos esta idea enfatizada en el Radar a través de un puñado de blips. Por ejemplo, los microservicios. Hoy en día es un patrón arquitectónico líder, tan popular que si estás lo suficientemente temprano en tu carrera puede ser uno de los únicos patrones arquitectónicos que hayas visto en sistemas back-end. Y realmente, no hay nada fundamentalmente malo en el enfoque; he utilizado microservicios con éxito en muchos de mis proyectos de clientes y muchos Thoughtworkers han escrito y presentado sobre el tema.
Sin embargo, los microservicios no son la solución adecuada para todas las situaciones. La última vez que hablamos de la envidia de los microservicios fue en 2018 para recordar a la gente que "los microservicios cambian la complejidad del desarrollo por la complejidad operativa y requieren una base sólida de pruebas automatizadas, entrega continua y cultura DevOps." Ese mismo año, la CTO de Thoughtworks, Rebecca Parsons, describió por qué los microservicios nunca llegaron al anillo Adoptar en el Radar en una publicación de blog. Destacó que la necesidad de matices en una recomendación de este tipo -debido a las compensaciones coste-beneficio que aportan los microservicios- significaba que era demasiado compleja para abordarla adecuadamente en un solo blip.
Hay otras señales en el radar que demuestran una forma de pensar similar. Por ejemplo, la envidia del Big Data, la envidia de la escala web y, más recientemente, SPA por defecto.
La importancia del feedback y la experimentación
Entonces, si la lección es que no hay una bala de plata, ¿cómo llegamos a una decisión en la que confiemos? La respuesta es que siempre hay que experimentar, recabar opiniones sobre la marcha y cambiar de rumbo cuando sea necesario.
Este hito cultural tiene que ser mi favorito, sobre todo por el impacto que ha tenido en mi carrera. Como desarrollador de software, he tenido el privilegio de crecer en desarrollo back-end, desarrollo front-end e ingeniería de datos. Más recientemente, pasé dos años como Asistente Técnico del Director Técnico, una función que puso a prueba y fortaleció mis habilidades multitarea, de facilitación y de influencia. Por el camino, recogí opiniones y aprendí mucho, desde las cosas que me gustan hasta las que no, y desde las áreas en las que soy fuerte hasta las que necesito desarrollar.
Los procesos que adoptamos para el desarrollo de software y el diseño de productos pueden beneficiarse de esta mentalidad. Dentro del Radar, vemos el tema de la experimentación en puntos como Replantearse las reuniones de stand up remotas. Llevamos mucho tiempo haciendo reuniones, pero en 2020 nuestra forma de trabajar cambió radicalmente y dimos un rápido giro hacia el mundo remoto. Con este cambio, propusimos experimentar con un tipo diferente de standup, uno que es realmente más largo y permite la discusión que de otro modo habría tenido lugar de forma natural por caminar hacia el escritorio de alguien o caminar juntos a la estación de café. Una vez más, se trata de un experimento: no sabemos si funcionará para todo el mundo. Sin embargo, si decides probarlo, merece la pena que vuelvas a hablar con el equipo para conocer su opinión y ver cómo puedes adaptarlo para que funcione en tu equipo.
Y eso nos lleva a la retroalimentación, probablemente la parte más crítica de cualquier experimento. En Thoughtworks damos mucha importancia a los comentarios. Damos especial prioridad a los comentarios de nuestros compañeros y de quienes trabajan estrechamente con nosotros. De hecho, es uno de los elementos más significativos de nuestras revisiones de rendimiento: es algo que nos proponemos practicar a diario y que destacamos como fundamental para nuestro aprendizaje y desarrollo. El feedback es lo que me ha ayudado a tener éxito en cada giro de mi carrera.
Del mismo modo, durante la creación del Radar adoptamos un enfoque ascendente para comprender la tecnología sobre la que merece la pena escribir. La opinión de las 12.000 personas que trabajan sobre el terreno con nuestros clientes es lo que hace que el Radar sea una publicación tan especial. El tema de la información de retorno también está presente en el Radar a través de herramientas como Telepresence y Vite. Telepresence consiste en desplazar las pruebas hacia la izquierda y permitir pruebas locales más eficaces; permite a los desarrolladores conectar un proceso que se ejecuta localmente a un clúster Kubernetes remoto. Esto significa que pueden obtener retroalimentación más rápido para los cambios que de otro modo habrían requerido un despliegue para la prueba. En un tema similar, Vite prioriza la velocidad de retroalimentación en los pipelines front-end.
La relación entre cultura y tecnología
¿Qué nos dice esto sobre el vínculo entre cultura y tecnología? Consideremos la ley de Conway; este concepto habla de la relación observada entre la arquitectura de los sistemas de software y la organización de los equipos que los construyen. Del mismo modo, el Radar Tecnológico es un reflejo de los Thoughtworkers que lo construyen y de la cultura que seguimos desarrollando.
Durante el debate para el volumen 26 del Radar, el Technology Advisory Board (TAB) debatió muchos otros sesgos que existen en el Radar - mis ejemplos no son en absoluto los únicos. Desde nuestro apoyo al software de código abierto hasta nuestra creencia en la simplicidad y la colaboración, somos muy conscientes de que la visión presentada en el Radar Tecnológico es una visión sesgada. ¿Hay algo más en el último Radar que refleje nuestros valores culturales?
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.
