De regreso al Desktop 15 años después

Duramente más de 15 años trabajé con una computadora portatil independientemente de si trabaja en la oficina de un cliente o en mi oficina. En este último caso solía usar dispositivos externos(monitor, teclado y mouse, etc) para trabajar más cómodo.

Hablo en pasado porque hace un par de meses decidí comprar una computadora de escritorio para dejarla fija en mi oficina. Una de las principales motivaciones para esto fue contar con Linux, ya que mi computadora portatil es MacOS y eso me trae dificultades cuando tengo que dar soporte a mis alumnos que en su gran mayoría no usan MacOS. Por otra lado yo había dejado de usar máquina de escritorio por el tamaño físico de los gabinetes que realmente me resultaba incómodo. Pero resulta que desde hace un tiempo hay mini-pcs muy potentes. Así que con todo esto en mente comencé a investigar para comprar una mini-pc y ponerle Linux.

Luego de varias averiguaciones decidí comprar una mini-pc Bmax B4 Pro, 16 GB de RAM y 500 GB de disco. Vino con Windows 11 Pro de fábrica, el cual decidí conservar e instalarle un Linux en paralelo. La decisión de la distribución de Linux ya lo compartí en un post anterior: ubuntu.

Todo el set de periféricos ya lo tenia, paso a detallar:

  • La BMax viene con dos puertos HDMI en los cuales conecté mis monitores gemelos Dell. Nota al margen para el modelo del monitor: Dell P2018h de 20 pulgadas, una joya, puede ponerse en orientación vertical y funciona como hub USB (tiene 4 entradas USB), conexión HDMI, VGA y DisplayPort.
  • Camara USB Logitec C922 Pro Stream Full Hd.
  • Parlantes Edifier R1000TCN
  • Micrófono USB Fifine K669B
  • Impresora laser Samsung M2020w
  • Teclado y Mouse estoy utilizando los de una vieja iMac conectados por USB. Hice una configuración custom en el Linux para que el mapeo de teclas resulte igual al que tengo en la MacBook.

Con todo esto, del CPU salen 5 cables: alimentación electrica, 2 hdmi para los monitores, audio y un USB para el monitor que funciona como hub. A su vez el monitor hub recibe: cámara, micrófono, impresora y teclado (que a su vez tiene conectado el mouse).

Luego de 1 mes de trabajo con este setup estoy muy cómodo.

Pair-Programming: una práctica subestimada y malinterpretada

La práctica de Pair-Programming es en mi opinión una práctica poco utilizada. Creo que muchos la prueban en algún momento pero luego la abandonan. Al mismo tiempo creo que mucha gente tiene una idea equivocada de lo que es esta práctica.

Respecto de la mala interpretación: la idea general es que dos personas trabajan juntas en una única máquina. Eso no es pair-programming, o mejor dicho faltan cosas. La práctica de pair-programming implica una serie de cuestiones adicionales como ser: cada uno de los programadores tiene un rol que va rotando siguiendo una dinámica predeterminada de forma tal que el teclado de cambia de manos, se trabaja en pequeños incrementos, etc, etc.

Respecto de la subestimación: hay gente que cree que esta práctica baja la productividad y por ello algunos se oponen a su uso. La realidad es que hay varios estudios desde hace mucho tiempo que demuestran que esto es falso, ya escribí sobre esto hace un tiempo.

Ahora bien, justamente por estas dos cuestiones es que en mis cursos de ingeniería de software estudiamos y practicamos pair-programming y en general tiene una muy buena aceptación por parte de los alumnos (más detalles en otro post).

En lo personal hago mucho pair-programming con los equipos que trabajo y suelo complementarlo con otras prácticas como trunk-based development, integración continua y TDD. Creo que justamente el combo de prácticas es lo que hace «que cierre».

Sobre la Orientación a Objetos y su pobre uso en la actualidad

La programación orientada a objetos (POO) tiene ya más de 40 (¿50?) años y sin embargo….

Para empezar me parece importante destacar el hecho que la POO no solo es una «tecnología de programación» sino algo mucho más amplio: es un paradigma. Esto implica que además de programar utilizando ciertas herramientas (encapsulamiento, polimorfismo, etc, etc), también tiene impacto en la forma en que planteamos los problemas y diseñamos nuestras soluciones.

Hoy en día creo que todos los lenguajes de programación de uso masivo tienen soporte para POO. Al mismo, en las carreras universitarias de sistemas se enseña POO.

Sin embargo, una y otra vez vemos (en la industria y en la academia) soluciones que utilizan objetos pero que no son orientadas a objetos. Abundan las soluciones con objetos contenedores de datos por un lado y objetos con lógica/algoritmos (pero sin datos) por otro. Para el resto del artículo me voy a referir a estas soluciones como «soluciones procedurales (SP)». Este fenómeno de «datos por un lado» y «comportamiento por otro», no es nuevo. De hecho hay varios frameworks que proponen este enfoque. Ya desde los años 2000 J2EE proponía nombre a estos objetos: «session beans» y «entity beans». Esta estrategia puede resultar práctica e incluso conveniente pero es contraria a la propuesta de la orientación objetos donde se supone que cada objeto encapsula dentro de sí, datos y los algoritmos que operan sobre esos datos.

A esto se suma al hecho de que hay gente que cree que construye soluciones orientadas a objetos porque usan clases, herencia, y demás herramientas de la OO pero que en realidad son soluciones procedurales porque siguen separando datos y comportamiento.

No digo que esté mal hacer soluciones procedurales, de hecho creo que hay situaciones donde este enfoque puede ser el más conveniente. Pero esta confusión entre soluciones procedurales y soluciones orientadas a objetos traen dos situaciones potencialmente problemáticas.

Un problema es cuando decimos (o creemos) estar haciendo algo (una solución OO) pero en realidad estamos haciendo algo distinto (una solución procedural).

El otro problema es usar un enfoque cuando en realidad sería mejor utilizar el otro.

Los primeros 15 años de mi trabajo docente fue intentando enseñar POO y por ello soy consciente de la dificultad de enseñar/aprender este tema. Hoy en día en los cursos que dicto en la universidad se supone que los alumnos ya llegan sabiendo OO aunque lamentablemente en la mayoría de los casos vemos importante falencias. Creo que en parte esto se debe a que muchas veces se enseña OO utilizando «problemas simplificados», o sea: los alumnos saben hacer modelos computables orientados a objetos de ciertos problemas, pero sin tener que lidiar con infraestructura (interfaces de usuario, persistencia, etc.).

Lo que veo en mis cursos es que cuando les planteamos problemas en los que tienen que lidiar interfaces de usuario, persistencia, etc, se «desvían» y terminan haciendo soluciones procedurales :-(.

Curso online de TDD

Hace ya un par de años que decidí no dictar más cursos de TDD, sin embargo desde ese momento me encontré con varias situaciones en las que necesité de un material introductorio a TDD, a modo de nivelación, para poder explicar luego el uso de TDD en escenarios más avanzados/reales. Busqué pero no encontré ninguno que me resultara convincente, entonces decidí generar mi propio material.

Es por esto que estas últimas semana estuve trabajando en un curso en video de «Introducción a TDD» que ya está disponible en la plataforma Udemy.

Si bien el curso está armando con C# y Nunit, la tecnología termina siendo anecdótica pues todo lo explicado es completamente aplicable en otros stacks de tecnología y todo el código es fácilmente traducible.

La idea de este curso es explicar los fundamentos de esta técnica de desarrollo ¿Vas a podes con este curso utilizar TDD inmediatamente en tu trabajo de desarrollo cotidiano? Depende, sin duda te va servir para entender la técnica y aplicarla en ciertas partes de tu código, pero de ahí a poder utilizarla al 100% en escenarios «reales», hay un largo trecho, hace falta mucha práctica y también utilizar algunas técnicas que intencionalmente no están cubiertas en este curso. Justamente la idea es: 1) comenzar tomando este curso, 2) practicar e incluso intentar aplicar la técnica en algunas partes/momentos de tu trabajo, 3) tomar una curso/taller más avanzado que tengo planeado publicar para mediados de 2025 y que incluirá muchas de las cosas que habitualmente doy en mis cursos de ingeniería de software.

Si sos estudiante de FIUBA y tenés pensado tomar mi curso de Ingeniería de Software 2, te recomiendo hacer este curso a modo de nivelación/repaso, escribime desde tu cuenta @fi.uba.ar y te tramito un pase gratuito.

Los seguidores habituales de este blog, también pueden escribirme y les tramito un pase.

Revisión y ajustes de «Construcción de Software: una mirada ágil»

Como mencioné hace unas semanas, estuve releyendo el libro. Bueno, lo terminé y encontré varias cuestiones. Aquí voy.

Contexto

Antes que nada me parece importante mencionar que el objetivo del libro era dar una idea general de agile incluso cuando algunos capítulos ofrecen bastante detalles de técnicas.

Sin duda que en estos últimos 10 años surgieron muchas cuestiones que podrían/deberían mencionarse en un libro de introducción a agile, algunos temas en este sentido podrían ser: escalamiento, #noEstimates y dual-track agile. Pero también es cierto que varias de las cuestiones que aparecieron no están necesariamente relacionadas a agile, por ejemplo «observabilidad» y «testear en producción» son prácticas que uno podría utilizar sin trabajar en un contexto agile del mismo modo que uno podría trabajar en un contexto agile sin usar estas prácticas.

Al margen de las prácticas yo creo que el mayor cambio que hemos presenciado es que hace 10 años agile era mainstream mientras que hoy en día ya ha supero eso y ahora es el enfoque por default (incluso cuando haya personas/organizaciones que no lo dominan).

Generalidades

La primer cuestión que detecté es que tendríamos que haber numerado explícitamente los capítulos, o sea, en la edición actual los capítulos solo tienen un nombre pero no tienen un número lo cual resulta incómodo cuando uno quiere referirse a un capítulo en particular :-(.

Como era de esperar (o no tanto) detecté algunos errores menores de tipeo (typos).

Creo que en ningún lado explicamos como es el flujo completo de un proyecto ágil, tenemos capítulos que tratan sobre cada una de las partes y tenemos también un capítulo que, a modo novela, cuenta un relato de un proyecto pero no tenemos un capítulo que explique la secuencia de eventos, ceremonias, etc. de un proyecto de punta a punta.

Me parece que falta más énfasis en la entrega continua, es una cuestión que está mencionada pero de forma muy tímida, discreta. Tal vez sea que la entrega continua es mi foco de trabajo actual (y desde hace unos años) pero si tuviera la posibilidad de hacer un ajuste en el libro, definitivamente sería poner más énfasis en la práctica de la entrega continua.

Muy relacionado con lo anterior, falta también más énfasis en stories pequeñas, de hecho creo que debería haber una sección (o incluso un capítulo) de slicing.

La práctica de Pair-Programming, que tiene más de 20 años y es core en XP, está apenas mencionada, creo que deberíamos haber escrito un capítulo al respecto (admito que cuando escribimos el libro, yo mismo no le daba la importancia que le doy en la actualidad a esta práctica).

En todo el libro hablamos constantemente de cliente pero en algunos casos creo que hubiera sido más conveniente hablar de usuario y obviamente hacer la diferenciación explícita entre usuario y cliente.

Finalmente, en lo personal, creo que cambiaría el orden de algunos capítulos.

Sobre cada capítulo

Nota previa: creo que la mayoría de los capítulos puede calificarse en uno de dos grupos: de mindset o de práctica. Los capítulos de mindset buscan explicar cuestiones de valores, principios, el espíritu de alguna cuestión casi sin entrar en cuestiones de prácticas o técnicas, aquí claramente están los dos primeros capítulos. Al mismo tiempo hay otros que se meten más concretamente en prácticas y técnicas, en cómo hacer concretamente alguna cuestión como es el caso del los capítulos de estimación (4) y retrospectivas (11). Dicho esto, los capítulos de mindset siguen siendo completamente válidos y casi que no requieren actualización. Por su parte los capítulos de prácticas, en su mayoría, requieren actualización ya sea por variaciones de las prácticas o por cambios en las herramientas.

Capítulo 1, «¿Por qué cambiar?»: es bastante filosófico/conceptual y si bien se podrían agregar algunas párrafos/secciones, creo que todo lo que dice sigue siendo válido.

Capítulo 2, «Iterativo por naturaleza»: también tiene un tinte bastante conceptual y apunta a explicar la necesidad de trabajar en forma iterativa. Me parece que hoy en día esta es una cuestión ampliamente aceptada aunque no en todos los casos correctamente implementada. Al igual que el capítulo 1, creo que se podría ampliar pero me parece que el contenido actual sigue siendo válido.

Capítulo 3, «Delineando el alcance»: explica las generalidades de las User Stories y la técnica de descubrimiento conocida como Visual Story Mapping(VSM). El contenido sigue siendo completamente válido y actual, aunque creo que amerita algunos ajustes relevantes. En primer lugar, cuando escribimos el libro no había una publicación formal de la técnica Visual Story Mapping, las fuentes disponibles eran algunos posts del blog del Jeff Patton (creador de la técnica) y de algunas otras personas que habían participado de alguna capacitación con el propio Patton. Al poco tiempo de la publicación de nuestro libro, finalmente Patton publicó un libro sobre esta técnica: User Story Mapping, Discover the Whole Story, build the right product. A partir de esto, nuestra descripción de la técnica difiere un poco de la descripción que hace Patton en su libro, lo cual no lo veo como un problema, nuestra descripción sigue siendo una herramienta válida y útil de comunicación/relevamiento. En este sentido creo que lo que sí le falta a nuestro libro (y en particular a este capítulo) es mostrar un ejemplo concreto del uso de la técnica. Finalmente algo que me suele ayudar mucho a entender el alcance de una funcionalidad es la técnica Example Mapping y por ello creo que agregaría una sección sobre la misma.

Capítulo 4, «Estimar no es predecir»: el contenido sigue siendo válido aunque mi práctica de estimación ha variado un poco. Creo que también que faltaría agregar algunos ejemplos concretos de las técnicas explicadas. Finalmente, si hubiera una nueva versión, sin duda agregaría alguna mención al movimiento #NoEstimates.

Capítulo 5, «Planificación constante»: aquí me parece que hay espacio para varios ajustes en línea con la idea de trabajar en un esquema de entrega continua. Planificamos el trabajo para toda la iteración pero esperando entregar los ítems apenas los vamos terminando sin esperar necesariamente al final de la iteración. Al mismo tiempo haría más énfasis en iteraciones cortas: una semana o a lo sumo dos. Creo que también es necesario ajustar la definición del slack pues me parece que no es precisa ni clara. Definitivamente agregaría algún apartado sobre técnicas slicing.

Capítulo 6, «Empezando por la aceptación»: este capítulo está muy bien y seguramente sea este el lugar para explicar con cierto detalle la técnica de Example Mapping. Este es uno de los capítulos que cambiaría de orden (lo pondría antes).

Capítulo 7, «Arquitectura y Diseño en emergencia»: gran parte de este capítulo habla de cuestiones que van más allá de agile, pero al margen de eso, su contenido sigue siendo actual.

Capítulo 8, «Probar, Probar, Probar»: trata de testing y dado que hace mención a varias herramientas requiere una actualización de las mismas. Al mismo tiempo creo que un punto para revisar es la taxonomía de pruebas, en lo personal, hoy en día no me convence del todo la taxonomía que escribimos.

Capítulo 9, «Esto está listo»: es más conceptual que práctico y ha envejecido bien. Nada que ajustar.

Capítulo 10, «Integrando el producto al instante»: al igual que el capítulo de arquitectura, tiene algunas cuestiones que van más allá de agile y al igual que el capítulo de pruebas hay cuestiones de herramientas a actualizar. Al mismo tiempo creo que falta mencionar más explícita y enfáticamente que hacer integración continua implica que todo el equipo trabaja simultáneamente sobre el mismo branch (o que si se crean branches, no deben vivir más de 1 día). Finalmente me resulta curioso que hablamos de feature flags sin utilizar el término feature flag.

Capítulo 11, «En retrospectiva»: es el más largo y si bien sigue siendo completamente válido, dista un poco de lo que es mi práctica actual de retrospectivas, principalmente la parte de preparación.

Capítulo 12, «Reuniendo al equipo»: creo que está muy bien, tal vez profundizaría sobre Pair-Programming (si no agregara un capítulo exclusivo para esta técnica).

Capítulo 13, «Irradiando Información»: muy bien, no creo que necesite cambios, tal vez un agregado para escenarios remotos.

Capítulo 14, «¿Quién manda a quién?»: es muy de mindset y sigue aplicando completamente.

Capítulo 15, «No hay como un buen ambiente»: me gusta mucho, sigue aplicando completamente tal como está aunque creo que faltaría agregar algo de operaciones y/o ambiente productivo.

Capítulo 16, «La fantasía de evitar los cambios»: completamente actual, nada que ajustar.

Capítulo 17, «Formalizando compromisos»: completamente actual, nada que ajustar.

Capítulo 18, «Construyendo con calidad día tras día»: completamente actual, nada que ajustar.

Capítulo 19, «Un día de desarrollo ágil»: creo que fue una muy buena idea para ejemplificar como fluye el día de un equipo trabajando con agile, sin embargo hoy en día creo que faltaría agregar alguna mención/situación relacionada a la operación/producción.

Capítulo 20, «Todo muy lindo pero…»: completamente actual, nada que ajustar.

Capítulo 21, «La riqueza de la diversidad»: completamente actual, nada que ajustar.

No sé si algún día escribiremos una segunda edición, pero en lo personal voy a escribir algunas línea relacionadas a los capítulos marcados en rojo y tal vez también para los naranjas.

Sobre la movida de la Agile Alliance y el PMI

El pasado 3 de enero se anunció «la unión» de la Agile Alliance (AA) al Project Management Institute (PMI) y por todos lados saltaron opiniones, muchas de ellas bastante críticas.

En lo personal el hecho en sí mismo no me resulta demasiado relevante. Al mismo tiempo lo que me llama la atención es la reacción «de la comunidad», muchos de los denominados agilistas.

En lo personal, he estudiado el PMBoK pero nunca me certifiqué como PMP ni fui parte del PMI. Por otro lado sí he tenido membresía de la Agile Alliance, ya que al ser speaker de su conferencia anual (Agile XX) solían otorgar una membresía como parte de los beneficios de speaker. Tampoco tengo ninguna certificación del universo Agile. En términos generales no soy partidario de las certificaciones, no les veo gran valor, pero eso es tema de otro post.

Respecto de la noticia en cuestión solo quiero compartir algunas preguntas para que el lector pueda reflexionar y sacar sus propias conclusiones:

¿Hasta qué punto estas organizaciones representan a los practicantes y a la práctica en sí misma? La misma pregunta podríamos hacerla para «la comunidad» ¿hasta qué punto la comunidad (la gente que organiza y participa activamente de eventos y del debate público) representa a los practicantes?

Aquellos que critican a la AA, ¿cuán involucrados están (o han estado) con la AA?

Cuando hacemos proyectos: gestionamos los proyectos o los proyectos nos gestionan a nosotros ¿qué preferimos?. Sin duda hay distintos enfoques para la gestión pero en lo personal me parece que algunos agilistas reniegan exageradamente de la gestión y en este sentido muchos han demonizado al PMI y su enfoque de gestión.

Sin duda que dentro de estos dos movimientos hay posiciones extremas. Podríamos pensar en los tradicionales gerentes de proyectos del mundo PMI y los fundamentalistas abrazadores de árboles dentro del mundo ágil. ¿Cuán representativos son estos estereotipos del grueso de los practicantes?

Una cuestión que sería importante tener presente es que el PMI como organización ha propuesto un enfoque de gestión que en cierto modo muchos ven como lejano, distante o incluso hasta contrario al enfoque de gestión de Agile. Debemos decir también que Agile surgió del mundo IT mientras que el PMI es mucho más amplio y por supuesto que no es lo mismo gestionar proyectos de IT que proyectos de Ingeniería Nuclear, Civil o Naval.

Finalmente, creo si leemos el comunicado dejando de lado cualquier prejuicio, el anuncio resulta interesante e incluso hasta prometedor. Veremos.

Una mirada ágil, 10 años después

Mi libro «Construcción de Software: una mirada ágil», que escribí con colegas de FIUBA, ya tiene más de 10 años. Lo publicamos en 2014 y desde ese momento algunas cuestiones han cambiado. Sin embargo creo que todo el contenido del libro es aún válido y por ello lo sigo usando en mis cursos. De hecho el libro está disponible gratuitamente en forma digital desde el año pasado, solo hay que completar este formulario y una copia registrada llega por correo en el transcurso de un par de horas.

Si bien el libro sige siendo actual, hay algunas cuestiones que en la actualidad suelo manejar de una forma distintas a la que quedó descripta en el libro. El auge de DevOps, las transformaciones digitales y la pandemia dispararon y/o aceleraron varios cambios haciendo algunas partes del libro cobren mayor relevancia y tal vez alguna otra ya no tengo tanto valor.

Cabe destacar que cuando escribimos el libro lo pensamos para un lector que posiblemente ya estaba familiarizado con el desarrollo de software tradicional y por ello en el libro apuntamos a destacar aquellos puntos en los que los métodos ágiles tenían una propuesta innovadora. Hoy en día los métodos ágiles son el estándar de facto (al menos desde la intención ya que en la práctica no todos los logran). Más aún, muchos de lo que empezaron en la profesión en los últimos años bien podrían ser denominados «nativos ágiles».

Esta semana empecé a releer todo el libro tomando algunas notas para una potencial segunda edición que incluya actualizaciones a algunos capítulos e incluso tal vez algún nuevo capítulo. En las próximas semanas, a medida que avance en la revisión, iré publicando mis notas «de actualización».

[off-topic] Políticos en la oposición

Hace un par de semanas me encontré con una compañera de la secundaria que fue diputada por el «Frente de Todos (contra todos)» y cuyo mandato terminó en el 2023. Hablando con ella sobre las medidas tomadas por el gobierno actual y sobre la inacción [1] de su espacio político, ella me dice «la gente votó a Milei, ahora que se lo banquen«. Esta respuesta me generó una mezcla muy variada de sensaciones: risa, bronca, impotencia y finalmente resignación.

No todo el mundo votó a Milei, más del 40% votó al Frente de Todos (contra todos) y con una expectativa que va más allá de ganar o no la elección. De una u otra forma, esa expectativa puede resumirse en que hagan algo para mejorar nuestra sociedad en línea con los valores y principios de su movimiento. De hecho, el puesto de presidente lo ganó Milei, pero hay varios legisladores que obtivieron una banca. Ojo, esto que digo no es solo para el Frente de Todos (contra todos) sino para todo movimiento: si te presentas a elecciones y alguien te vota entonces tenés una obligación con esos votantes. «No vale» que te quedes cruzado de brazos hasta la próxima elección y menos aún si ganaste una banca legislativa.

Y no me vengas con «estamos votando en contra», no alcanza, espero que traigas ideas, que te muevas, que hables con la gente, que acompañes, que traigas ideas porque con solo votar en contra no se construye nada.

Libro Recomendado: Tidy First?

Ayer terminé mi primer lectura de vacaciones, el libro más reciente de Kent Beck: «Tidy First?: A Personal Exercise in Empirical Software Design».

Primero los datos: el libro es bastante corto, apenas 99 páginas distribuidas en 33 capítulos lo cual sigue el estilo típico de los libros de Beck: capítulos cortos. En este caso está llevado al extremo porque hay capítulos de menos de 2 páginas. El libro es el primero de una serie, que según el propio Beck, tendrá 3 libros. El libro arranca con cuestiones muy concretas y gradualmente se va poniendo más teórico/filosófico.

Pero… ¿qué es un «tidy»? Como la traducción puede sugerir, un tidy es un emprolijamiento. Una mejora en la estructura del código de cara a facilitar su entendimiento/evolución. En un punto es cómo un refactor, pero más chico.

Ahora mi opinión: el libro me gustó mucho, mezcla cuestiones muy concretas/prácticas (los «tidyings») con cuestiones más teóricas/filosóficas (cuando tidy y cuando no, cuánto tidy, etc). Todo esto analizado una visión económica. Creo que son muy pocos los libros que tratan este tipo de cuestiones. A su vez, la organización en capítulos cortos hace que la lectura me resulte muy cómoda. Si bien es libro que cualquier programador debería poder entender sin dificultad, creo que los programadores más experimentados van a sacarle mayor provecho.

Proyectos de verano 2025

Desde mediados de diciembre hasta mediados de Marzo es el período que denomino «cuatrimestre de verano» y que en mi caso se caracteriza por tres cuestiones:

  1. Mis actividades en la universidad son mínimas en gran medida por el receso de verano
  2. Como consecuencia del punto anterior tengo más tiempo disponible que durante el resto del año. Obviamente parte de ese tiempo lo utilizo para descansar pero también para hacer «proyectos distintos», por ejemplo proyectos «experimentales», proyecto con nuevos clientes, etc.
  3. Investigación y generación de material, escribo, hago videos, etc, etc.

Para este «cuatrimestre de verano de 2025», tengo poco trabajo agendado con clientes con lo cual, si la situación no cambia, ya tengo dos temas en los que trabajar.

Por un lado quiero hacer algunos experimentos con tecnologías de inteligencia artificial. Creo que mi proceso de desarrollo podría mejorar (en términos de productividad/velocidad) a partir del uso de herramientas como Co-Pilot y JetBrains AI.

Por otro lado quiero escribir una actualización de algunos capítulos de mi libro «Construcción de Software: una mirada ágil» que ya tiene más de 10 años y ya tengo identificado algunos capítulos que requieren una actualización.