Ingeniería de Software en la Era DevOps

Este el título de la charla/tutorial que dí la semana pasada en el contexto de CIbSE. En Zoom hubo unas 80 personas conectadas pero de las actividades interactivas que propuse, participaron alrededor de 30, un buen número de todas formas.

El punto central de mi de charla fue el hecho de que los escenarios que enfrentamos actualmente en la entrega de software nos llevan a tener que lidiar con ciertas cuestiones que tradicionalmente la ingeniería de software no ha atendido presentes. Al mismo tiempo, dichas cuestiones son centrales dentro del movimiento DevOps. Esto plantea un dilema: ¿es DevOps una disciplina distinta a la Ingeniería de Software? Pues yo creo que no. A mi parecer la Ingeniería de Software debe incluir DevOps. De hecho algunas de prácticas DevOps no son nuevas, sino que han sido parte de la Ingeniería de Software desde hace mucho tiempo. Ejemplo: Integración Continua.

En línea con esta idea, durante mi disertación mencioné varios libros que deberíamos tener presentes a la hora de plantear una Ingeniería de Software que incluya la temática DevOps:

Según comentó la organización de CIbSE, en los próximos días estarán disponibles todos los videos de la conferencia.

Conferencia Iberoamericana de Ingeniería de Software, CIbSE 2022 (gratis)

CIbSE es una de las conferencias regionales más importante sobre ingeniería de software. La edición 2022 se llevará a cabo la semana próxima (del 13 al 17 de Junio) en modalidad virtual.

La agenda del evento incluye presentación de artículos de investigación, keynotes y sesiones/tutoriales sobre el estado del arte.

Este año tengo el agrado de haber sido invitado a dar un tutorial/disertación sobre DevOps el cual he titulado como «Software Engineering in the DevOps Era». El mismo está agendado para el próximo lunes 13 a las 13:30.

La agenda del evento incluye algunas sesiones muy interesantes, los invito a darle una mirada aquí.

En esta edición la participación es gratuita pero requiere registrarse aquí. ¡Nos vemos!

Inversión de Dependencias

Este el quinto principio de los principios SOLID y personalmente creo que es el que mayor impacto tiene a la hora de hacer soluciones testeables. Pero curiosamente me encuentro recurrentemente con una importante cantidad de gente que no lo usa o que lo interpreta incorrectamente. Es por esto que decidí hacer un video al respecto.

Me quedó un video bastante corto, ~10 minutos, en el que explico el principio utilizando código y diagramas. Espero les resulte útil.

Impresiones de la enseñanza de TDD y otras prácticas

El año pasado comenzamos con la práctica de encuestar informalmente a los alumnos sobre las algunas de las prácticas de desarrollo que estudiamos (y aplicamos) en la materia. Concretamente les consultamos con 3 prácticas que estudiamos en la materia, que consideramos muy beneficiosas pero que curiosamente en la industria no tienen un uso masivo (aún): Mob-programming, Trunk-based development y Desarrollo guiado por Pruebas (BDD/TDD).

Explicamos a los alumnos cómo utilizar estas prácticas y las aplicamos en el contexto de un proyecto de desarrollo.

Si bien los alumnos pueden no utilizar estas prácticas (hecha la ley, hecha la trampa) insistimos en las utilicen principalmente con dos argumentos (ya que en general a los alumnos no les basta con que el docente les diga «es por aquí» ¡ja!):

  • Son prácticas que traen importantes beneficios y cuya efectividad está ampliamente probadas
  • A pesar de lo anterior, son prácticas que en la industria no son mainstream y que incluso se las mira con cierta desconfianza en algunos contextos. En la materia les ofrecemos un ambiente seguro para que puedan experimentar con la práctica, contando incluso con la guía del equipo docente. Si prueban estas prácticas en este contexto ¿donde las van a probar? ¿en sus trabajos con la presión de su jefe, los deadlines y el apuro de la industria?

La actividad de encuesta es bastante simple, les presentamos un cuadro de dos ejes y les pedimos que indiquen ahí cómo fue su experiencia utilizando estas prácticas.

Puede resultar curioso para algunos que la la práctica con mejor evaluación es el desarrollo guiado por pruebas. Cabe destacar aquí que al hablar de desarrollo guiado por pruebas me refiero al uso de BDD/TDD, o sea, guiar el desarrollo a partir de especificaciones en forma de ejemplos (pruebas) generados colaborativamente entre usuarios y el equipo de desarrollo.

Libro: Refactoring, Improving the Design of Existing Code

Recientemente terminé de leer este libro. Había leído algunos fragmentos sueltos, algunos refactorings del catálogo, pero resulta que el libro es mucho más que el catálogo. Toda la primera parte del libro explica diversos conceptos de refactoring y diseño orientado a objetos en general.

Entre lo que más me gustó del libro (más allá de algunos refactorings) están el capítulo 2 (Principles) y el capítulo 3 (Bad Smells in Code).

El autor del libro es Martin Fowler pero hay capítulos en los que colaboraron otros autores. Destacan las colaboraciones de Kent Beck, en esos capítulos se evidencia el mismo tono de «charla de café» que en los libros Beck (TDD by Example, Extreme Programming Explained, etc)

Dada la época en que se escribió el libro (2001), los ejemplos y las menciones a lenguajes de programación están en torno a Smalltalk, C++ y Java (versión 1.2).

Importante aclaración: hay 3 ediciones de este libro una de 2001 y otras 2 de 2018 (una es la actualización de la versión 2001 y la otra es una versión ajustada a Ruby). Yo leí la versión 2001 porque me interesaba entender el tema desde la raíz, sin embargo si alguien está interesado en leer este libro le recomiendo leer la versión 2018.

Libros de Ingeniería de Software que 2022 merecen una mirada

En los últimos años han sido publicados algunos libros sobre ingeniería de software que a mi parecer son de consideración obligada para todo docente de esta temática.

Software Engineering at Google: publicado por O’Reilly en 2020 y con versión digital (pdf) fue liberada gratuitamente hace un par de día. Cubre cuestiones de cultura, procesos y herramientas. Un punto para destacar de este libro es que tiene varios capítulos dedicados exclusivamente al tema testing. Paso a comentar. Curiosidad: el primer capítulo comienza con una cita de Borges.

The Art of Agile Development (segunda edición) escrito por James Shore y con colaboración de varios referentes. Es básicamente un libro de Extreme Programming. Su primera edición fue en 2007 y me pareció de lo mejor. El año pasado James decidió hacer una nueva edición cuyos borradores fue compartiendo en forma temprana para obtener feedback y refinarlos. Tuve la oportunidad de participar de esa iniciativa y me pareció un idea excelente. Esta nueva edición no solo actualiza algunos contenidos sino que en un punto es un «major update» ya que también incluye algunos nuevos capítulos en los que trata temas como «DevOps» y «Scaling».

Modern Software Engineering: escrito por Dave Farley(autor del ya clásico Continuous Delivery) y publicado a comienzos de 2022. A diferencia de los dos libros anteriores, este me resultó un más conceptual/filosófico. Propone un enfoque muy pragmático y contrastante con los libros clásicos de la temática como los de Pressman y Sommerville.

Trabajos en «tech», cursos cortos y carreras universitarias

«Trabajar en tecnología» es uno de los temas de moda. Trabajar en «tech» le dicen. Si bien el término «tech» podría sugerir trabajos en las diversas áreas de ingeniería y ciencias aplicadas, la realidad es que en la actualidad el término «tech» se utiliza para referirse a todas aquellas profesiones/disciplinas relacionadas al mundo IT: programación, testing, diseño gráfico/UX, administración de sistemas, datos, IoT, etc..

Este tema ha disparado diversos debates en redes sociales que incluyen posiciones muy variadas como:

  • «cualquiera puede trabajar en tech»
  • «no es necesario ir a la universidad para trabajar en tech»
  • «si querés trabajar en tech mejor no vayas a la universidad»
  • «todo lo que necesitas para trabajar en tech es perseverancia, ver videos de YouTube y practicar React»
  • «leer libros no sirve»
  • «no trabajes en tech si no amas la tecnología»
  • «aunque no te guste programar podes trabajar en tech»

Algunas de estas frases son hechos concretos mientras que otros son ideas , a mi entender, disparatadas.

En primer lugar hay un hecho: existen en la actualidad muchísimas oportunidades de trabajo en «tech». Al mismo tiempo hay incontables casos que demuestran que no es necesario contar con formación universitaria para conseguir un trabajo en «tech».

Personalmente no creo que la formación universitaria conspire contra conseguir un trabajo en «tech», al contrarío, yo creo que todo estudio, conocimiento y experiencia siempre suma. Sobre todo porque la universidad nos da mucho más que contenido. De hecho creo que es justamente «todas esas otras cosas» lo que marcan la mayor diferencia entre estudiar en la universidad o estudiar en alguna otra institución no-universitaria.

Sin embargo, si lo que uno está buscando es una oportunidad laboral y ponemos en la balanza la relación costo/beneficio en el corto plazo, es muy posible que la balanza se incline a hacia hacer una carrera corta y/o curso intensivo en lugar de una carrera universitaria. Explicito «en el corto plazo» porque una carrera universitaria demanda más tiempo que un curso o carrera corta y al mismo el retorno de la inversión de una carrera universitaria es a largo plazo.

Es posible que hoy en día, en muchas organizaciones tener un título universitario no represente un requisito de ingreso. Personalmente creo que el título universitario habilita una mayor proyección. O sea, de alguna forma conseguiste entrar, ahora el punto es hasta donde podes llegar. Ser programador («individual contributor«) puede estar bien para muchos y estoy de acuerdo que en muchos casos se puede prescindir de una carrera universitaria. Pero un rol de manager/liderazgo requiere de otras habilidades y formación que a mi parecer no son tan fáciles de conseguir con cursos informales.

No estoy seguro si es causa, consecuencia o simple coincidencia, pero este auge de las carreras en «tech» coincide con la «segmentación/especialización» de las incumbencias. Si miramos 20 años atrás la gente que trabajaba en sistemas eran literalmente analistas/licenciados/ingenieros en sistemas/computación, era gente que había pasado por una educación formal. Ea mucho menos habitual encontrarse con gente trabajando en sistemas que no hubiera pasado por la universidad. Tal vez había una porción de profesionales que no había completado su carrera pero al menos tenían algunos años de educación formal. Hoy en día la situación es bastante distinta, empieza a ser más habitual encontrar con gente que nunca hizo el intento de una carrera formal en sistemas. Es aquí donde entra en juego la «segmentación/especialización»: en general esa gente que no pasó por la educación formal en sistemas, es típicamente un especialista: desarrollador backend, tester, devops, desarrollador frontend o incluso más especialista aún «desarrollador React» (#graciasJavaScript). De hecho mientras lo escribo, dudo de que el término correcto sea «especialista», pues pienso en la medicina: el pediatra es médico, sabe de pediatría pero también tiene conocimientos generales de medicina. El desarrollador frontend ¿sabe de cuestiones generales de desarrollo (algoritmia, configuration management, testing, etc)? Tengo mis dudas, pero al margen de eso tal vez la situación actual del mercado/industria no requiere que el desarrollador frontend sepa nada más que frontend. Es aquí donde aparece una diferencia importante con las carreras universitarias de sistemas: no forman «especialistas».

Claro que el perfil de un egresado UTN es distinto al de un egresado de UBA Ingeniería, pero ambos son a los ojos del mercado/industria dos generalistas. La universidad no forma programadores, ni testers, ni devops. La universidad forma profesionales mucho más generalistas y que tienen a su vez la capacidad de auto-formarse en cualquier especialización. Este ha sido un punto clásico de tensión entre industria y academia. La industria muchas veces pretende que la universidad ya «le de gente» que sepa Cobol/React/Andriod (o la tecnología de moda) y la universidad (al menos la pública) siempre ha insistido en formar gente con conocimiento «más profundo y duradero» que la tecnología de moda. Hoy en día esto ha llevado a que (parte) de la industria ya no busca gente en la universidades y al mismo tiempo lleva a la universidades a replantearse la formación que otorga (mmm, no creo que todos en la universidad se esten planteando esto, pero si algunos).

En fin, creo que es un tema que aún da para mucha charla. La gran duda que me surge es con que nos entraremos dentro de 3 o 4 años cuando tengamos que evolucionar esas aplicaciones construidas en gran medida (o incluso en su totalidad) por gente que tuvo una forma rápida/no universitaria en sistemas.

Continuará….

Test-Driven Development for Embedded C

Ayer terminé de leer este libro. En una palabra: Excelente.

Lo había tenido en radar por mucho tiempo pero recién ahora con el envión de mi trabajo de investigación sobre TDD decidí invertir tiempo en leerlo. El autor del libro es James Grenning, uno de los 17 autores del Agile Manifesto pero lo que puso el libro en mi radar fue la charla de Grenning «TDD Guided by ZOMBIES» en la cual propone una heurística para definir el orden de la secuencia de tests al hacer TDD.

El hecho de que el título del libro haga referencia a Embedded C es en gran medida anecdótico ya que casi todo el contenido es directamente aplicable a cualquier lenguaje o eventualmente fácilmente extrapolable. Es cierto que algunos capítulos están muy centrados en C y en el desarrollo de software embebido, pero varias de las problemáticas relacionadas a la dependencia del hardware son fácilmente extrapolables a las dependencias de infraestructura que uno se encuentra en el desarrollo de aplicaciones de más alto nivel.

Al margen de TDD, creo que el libro resulta muy valioso para gente trabajando en software embebido ya que provee un conjunto de técnicas que sin duda facilitan/aceleran el desarrollo del software embebido. De hecho lo interesante de las técnicas que propone son aplicables a todo desarrollo a bajo nivel, sea o no embebido. Personalmente he trabajado muy poco con software embebido pero sí he hecho desarrollo en C/C++ y de haber sabido las técnicas mencionadas en este libro creo que habría obtenido mejores resultados.

El libro me ha parecido muy completo, explica los fundamentos de TDD, trata con suficiente detalle las cuestiones de tooling para poder automatizar pruebas en C, escribir código modular y hasta implementar mocking en C. También trata cuestiones de patrones, code smells y trabajo con código legacy.

Para mi es 10 puntos, muy recomendado.

Y un día volvimos al aula…

Todos con tapabocas, con menos distanciamiento que el recomendado pero con puertas y ventanas abiertas, el pasado lunes 21 de marzo volvimos al aula. Si bien creo que nos adaptamos muy bien a las clases online no hay como la interacción dentro del aula.

Algunas clases de MeMo2 claramente conviene que sean virtuales, principalmente aquellas que incluyen actividades de programación. En esos casos resulta muy conveniente que el alumno pueda trabajar sobre su propia computadora. Del mismo modo, hay otras clases en las que la presencialidad es un valor diferencial. Un claro ejemplo de esto es la primer clase de curso, donde conocemos y comenzamos a intentar generar una relación de confianza que facilite el proceso de enseñanza-aprendizaje.

Llevamos 2 semanas de clase y hasta el momento tengo en claro que la primera clase debería ser presencial (por lo que mencioné previamente) mientras que la segunda debería ser virtual, para que los alumnos puedan hacer el setup de sus computadoras durante el tiempo de clase y que eventualmente podamos asistirlos en vivo.

Como de costumbre, en la primera clase les pedimos a los alumnos que completen la encuesta de perfil. Una vez más nos encontramos con situaciones incómodas como ser el tener alumnos con cantidades muy dispares de materias aprobadas: en un extremo 15 y en el otro 32.

También tenemos disparidad en la edad: gente de 21 y gente de 42.

Un rubro en el que notamos un cambio respecto del histórico de la materia es en el laboral. Este cuatrimestre tenemos que el 81% de los alumnos ya trabaja en un actividad afín de la carrera, porcentaje que tradicionalmente estaba en torno al 70%.

Cierre y estadísticas del desarrollo de Fira

El lunes pasado fue la presentación formal Fira, el trabajo final de carrera de Facundo Gertsner y Matias Feld y del cual fuí director. La presentación la hicimos presencialmente en la facultad acorde a la normativa vigente pero adicionalmente fue transmitida por Twitch, donde quedó disponible para posterior visualización.

Comparto algunas métricas que pueden resultar de interés para otros alumnos:

  • 23 iteraciones de desarrollo
  • Más de 860 horas de desarrollo
  • Más de 600 pruebas automatizadas
  • ~1300 commits
  • Más de 20 GB de assets

A estos números hay que contextualizarlos considerando:

  • Desde que comenzamos a hablar sobre el trabajo con los alumnos (fines de 2020) hasta que se presentó el trabajo (mazo 2022) pasaron más de 14 meses.
  • Adicionalmente a las horas de desarrollo, los alumnos invirtieron una cantidad no menor de horas en capacitación e investigación, principalmente dedicadas a aprender Unreal (el motor sobre el que está construido el juego)

Algunas otras cuestiones que me parecen interesantes para destacar por no ser tan habituales en los trabajos finales de carrera:

  • Matias y Facundo decidieron aprovechar el trabajo final de carrera para comenzar un emprendimiento comercial. Esto resulta muy interesante pero trae también algunos desafíos como ser el hecho de regular las potenciales tensiones entre el aspecto comercial y el aspecto académico. Ejemplo: comercialmente el producto podría requerir más tiempo de desarrollo que el inicialmente estipulado; al mismo tiempo desde el punto de vista académico pretendemos que los alumnos terminen su formación en un tiempo acotado. Es justamente en este tipo de cuestiones donde el director debe guiar a los alumnos.
  • Al momento de finalización del trabajo académico, el producto no se encontraba comercialmente finalizado pero sí había tenido una validación de mercado (como director no habría podrido dar el trabajo por finalizado sin esta validación). El juego tuvo ~400 descargas de la versión beta y más de 25 mil visitas a la página de promoción.
  • El desarrollo de un juego de este tipo requiere del desarrollo de piezas artísticas (imágenes, texturas, animaciones, sonidos, música, etc). Esto implicó que parte del trabajo de los alumnos incluyera la gestión con los artistas/profesionales proveedores/creadores de estas piezas. Este trabajo de gestión es una tarea habitual para un ingeniero pero resulta algo casi inédita en un trabajo final de carrera.

Bueno, esto es todo sobre Fira. Felicito a Matias y Facundo por el trabajo realizado y les agradezco por haberme permitido ser parte de esta aventura.