En línea con la estrategia de enseñanza de TDD que seguimos en FIUBA y UNTreF, escribí este artículo que fue aceptado en el Simposio Argentino de Educación en Informática de las Jornadas Argentinas de Informática, JAIIO 52. Al margen de la presentación del artículo que haré en el contexto del Simposio, tengo planeado hacer un charla abierta (meet-up online) para compartir esta experiencia. Si están interesados esten atentos a este canal.
Es habitual hoy en día encontrar gente «autodenominándose» Software Engineer sin tener un título formal de ingeniero o disciplina universitaria aledaña. Personalmente no creo que sea una cuestión relevante pues a diferencia de lo que ocurre con otras ingenierías, la ingenieria de software no es una disciplina regulada, o sea: para construir un puente es necesario el aval legal de un ingeniero civil pero para construir un software no es necesario el aval legal de un ingeniero de software.
Por otro lado, algunos de los que somos Software Engineer «con título», dudamos de la denominación «ingeniero» o mejor dicho dudamos de que el Desarrollo de Software deba ser considerado formalmente una ingeniería. He aquí la paradoja:
No ingenieros que quieren ser ingenieros e ingenieros que dudan de serlo
Varios referentes de la disciplina se han pronunciado respecto de este dilema, uno de ellos es David Parnas en su artículo «Software Engineering – Missing in Action: A Personal Perspective«. Otro autor que trata la cuestión es Pete McBreen en su libro Software Craftsmanship.
Esta visión «ingenieril» del desarrollo de software llevó a que las carreras de Ingeniería Informática/Sistemas en Argentina tengan varias materias de ciencia básica (física y química entre otras) compartidas las demás ingenierías. En lo personal y viendo la carrera que yo cursé me hubiera gustando tener menos contenido ciencia básica y más contenido de específico de informática.
En fin, los años pasan y la polémica se renueva.
Este es un rol viene ganando cada vez más popularidad desde el auge de DevOps. Ocurre que en muchas organizaciones el testing lo realiza gente que no sabe programar y por ende no puede automatizar los tests que realizan (en realidad es posible utilizar herramientas del tipo record & play, pero en general esa estrategia tiene muchas limitaciones).
En un par ocasiones trabajé con equipos donde había gente en este rol y sinceramente no me pareció una buena idea. En todos los casos la dinámica de trabajo era:
De entrada esto me hizo recordar a la época en que una persona hablaba con el usuario (analista), escribía un documento de casos de uso y luego otra persona (desarrollador) leía el documento y programaba la funcionalidad. Si bien aún hoy hay equipos trabajando de esta forma creo que son minoría. Por algo será.
Otra cuestión que me resultaba poderosamente llamativa era la desconexión total entre estos automatizadores y los desarrolladores.
También ocurría que si en una determinada iteración no había trabajo de automatización, esos automatizadores, a pesar de saber programar, no se ponían a programar la aplicación.
Finalmente lo que para mí resultaba más perjudicial: toda la automatización de pruebas quedaba en manos de estos automatizadores, o sea: los desarrolladores no escribían ningún tipo de prueba automatizada, ni siquiera unitarias. Es bien sabido que para tener un buen flujo de entrega continua es necesario tener pruebas automatizadas, pero también es necesario que parte de ese trabajo de automatización lo hagan los propios desarrolladores comenzando por las pruebas unitarias.
En fin, no digo que tener un rol de Test Automation Engineering sea algo malo ni incorrecto. Solo digo que las dinámicas de trabajo que he visto en equipos que tienen personas en dicho rol, no generan un buen flujo de entrega continua. No digo que siempre sea así, pero sí lo fue en los casos que vi de cerca. Dicho esto, mi recomendación es que si tienes en tu equipo una persona en este rol o estás pensando en incorporarla, tal vez deberías detenerte un momento a pensar en la dinámica de trabajo del equipo.
El uso de feature branches en conjunto con pull-request es una práctica muy habitual en la actualidad, a pesar de que en general termina siendo un impedimento para implementar Continuous Delivery. Esto resulta en gran medida curioso porque mucha gente que utiliza feature branches y pull-request cree que hace Continuous Delivery.
Por definición Continuous Delivery implica Continuous Integración lo cual a su vez implica Trunk-Based Development, o sea: no hacer branches que duren más de un día. Siendo conceptualmente estrictos uno podría hacer feature-branches & pull-request y aún así hacer Continuous Delivery, pero entonces los branches y pull-request no deberían extenderse más de un 1 día, situación que no condice con lo que suele verse en la industria mayoritariamente en la actualidad.
Desde hace varios par de meses vengo trabajando con un equipo muy maduro en un sistema que ya está productivo hace años. Trabajan con una dinámica de feature-branches, pull-requests bloqueantes y puesta en producción al final de la iteración. Dado que la iteración dura 2 semanas, esta dinámica implica que todo ítem, por simple que sea, tardar 2 semanas en llegar a producción. A su vez esto provoca que cada release a producción sea bastante grande pues contiene todo el trabajo acumulado durante 2 semanas. Y obviamente, cuanto más grande, más riesgoso. En parte como consecuencia de esto cada release a producción implica un downtime del sistema lo que obliga notificar a los usuarios sobre el tiempo de downtime y al mismo tiempo obliga que el release se realice fuera del horario de oficina para así afectar lo menos posible a los usuarios.
Dado que a mi parecer el equipo está bien consolidado, cuenta con un interesante set de pruebas automatizadas, el producto está estable, hay un proceso formal de testing y release, considero que están en condiciones de transicionar a un esquema de Continuous Delivery y por ello la semana pasada le propuse hacer un experimento. La propuesta es identificar un par de items de backlog, de bajo riesgo, para liberarlos (ponerlos en producción) tan pronto estén listos. De esta forma se entrega valor al negocio más rápidamente y al mismo tiempo el release de fin de iteración es más pequeño y menos riesgoso.
El formato «vivo» creo que se popularizó con Twitch y digo creo porque sinceramente no es un formato que suela consumir. El formato «podcast» por su parte, ya lleva un buen tiempo en la red y si bien suelo consumir algunos podcast recién ahora pasé del otro lado para tomar el micrófono y ser protagonista.
Es que ayer salió publicado el episodio #30 del podcast Agile Latam en el cual tuve una interesante conversación sobre testing con Ettiane Salamanca de Inspirit. Pueden encontrarlo en Spotify.
Por otro lado, la semana pasada participé de mi primer vivo junto a Martin Alaimo con quien estuvimos hablando en LinkedIn sobre «Definition of Done«, lo pueden ver aquí.
Mi próxima intervención será durante julio en el podcast de otra empresa amiga.
La ingeniería de Software «tradicional» de la que venimos hablando desde los años 60′, que está descripta en los libros clásicos de la disciplina (Presmann, Sommervielle, etc), incluso la descripta en el cuerpo de conocimiento (SWEBoK) no trata las cuestiones relacionadas a la puesta en producción y la operación. Estas cuestiones, que en los últimos 15 años han tomado cada vez más relevancia debido al rol protagónico que ha tomado en software en el negocio, han sido resueltas en los contextos industriales con un conjunto de prácticas que se han englobado bajo lo conocido DevOps y SRE.
La Ingeniería de Software Continua es el nombre «formal» que se le ha dado en la academia a la inclusión de las prácticas DevOps y SRE en la Ingeniería de Software
Dicho de otra forma y de manera simplificada podría decir:
Ingeniería de Software continua = Ingeniería de Software (tradicional) + DevOps/SRE
La iniciativa del monotributo tech ha recibido muchas críticas por parte de empresarios del sector de software y servicios. En cierto modo es una actitud «muy argenta» que vemos cotidianamente en el fútbol: en lugar de alentar a tu equipo, insultas a tu oponente.
Parece que algunos empresarios en lugar de preocuparse en mejorar la oferta de valor para sus empleados (y no me refiero solamente a remuneraciones), critican una medida por «miedo» a perder empleados. Dicho de otra forma, en lugar de apuntar a que los programadores elijan sus empresas por ofrecer oportunidades atractivas, apuntan a cerrarle puertas a esos programadores de forma que sus empresas sean la única opción.
Personalmente creo que el monotributo tech tiene algunos puntos flojos y varias oportunidades de mejora, pero al margen de eso me indigna la actitud de algunos empresarios.
Blog de NicoPaez 