Nueva materia: «Artesanía de Software»

Hace ya tiempo venía dando vueltas en mi cabeza la idea de una materia para estudiar ciertas cuestiones «avanzadas» y en un punto hasta filosóficas de nuestra profesión. Dada la gran mezcolanza de temas no lograba darle nombre. Se me ocurrieron nombres como «Desarrollo Profesional de Software», «Programación Avanzada» y «Ejercicio profesional del desarrollo de software» pero ninguno me convencía. Finalmente, el pasado fin de semana me puse a escribir una descripción de los temas a abordar y mientras escribía la bibliografía de referencia me resultó evidente que el título debería ser «Artesanía de Software».

La idea de esta materia es estudiar ciertas cuestiones del ejercicio profesional del desarrollo de software. Es una materia avanzada, no por la complejidad de los temas a abordar sino por el hecho de que para poder abordarlos con profundidad y con una visión crítica es necesario tener algunos años de experiencia en el ejercicio de la profesión y más específicamente en programación. O sea, esta no es una materia para gerentes, analistas o maquetadores, es una materia para programadores.

Si tuviera que ubicar esta materia en el plan de estudio, sería una materia optativa del último año de la carrera.

Sobre los temas

Si miramos los planes de estudio de las carreras de sistemas vemos varias materias de programación: Algoritmos y Programación, Paradigmas de Programación, Programación Concurrente, Programación Orientada a Objetos, Taller de Programación, etc. Cada una de estas materias aborda alguna técnica o aspecto de la programación, pero hay ciertas cuestiones que son en cierto modo transversales a todas estas materias.

Entre estas cuestiones transversales hay temas tan básicos como la elección de los nombres de variables que uno podría pensar que deberían abordarse en las primeras materias de programación pero que en ocasiones no se abordan en profundidad o que incluso cuando sí se abordan, son cuestiones que resulta interesante replanteantearse luego de un par de años programando.

También tenemos algunos otros temas relacionados al versionado que es algo que utilizamos a diario pero que muchas veces lo hacemos en modo automático y sin considerar qué estamos metiendo en cada commit, que mensaje de commit ponemos, con que criterio creamos branches, etc.

Uno de los temas más polémicos y filosóficos que trata la materia es la discusión del desarrollo de software como ingeniería, ciencia u oficio.

Algunos otros temas a cubrir:

  • Profesionalismo, ética y contratos
  • Freelancing
  • Work-life balance
  • Aprender, enseñar, aprender a aprender y aprender a enseñar
  • Estimación, No-estimación, presupuestos y planificación
  • Lenguajes y paradigmas
  • Tipado estático vs. tipado dinámico vs. no tipado
  • Código de aplicación y código de pruebas
  • Las pruebas como documentación
  • Java, el nuevo cobol
  • El ascenso de JavaScript
  • Smalltalk…..
  • Mantenimiento y evolución
  • Trabajo con código legado
  • Código de infraestructura
  • Versionado y trazabilidad
  • Revisiones, Pairing y Mobbing
  • No-code / Low-code

Modalidad de cursada

La materia se dicta en una modalidad de aula invertida durante 16 semanas con un encuentro online de 3 horas por semana y con una dedicación estimada extra clase de unas 4 horas semanales.

La materia incluye lecturas (varias), videos (no tantos), código (tanto para leer y como para escribir) y debate (espero que mucho).

Participantes

Los candidatos a cursar la materia deberían:

  • Estar a menos de 4 materias para recibirse de una carrera de grado de sistemas/computación.
  • Tener al menos 3 años de experiencia programando profesionalmente en la industria.
  • Sentirse cómodos trabajando con al menos dos lenguajes de programación y tener alguna experiencia en al menos otros dos lenguajes (no cuenta HTML, CSS, ni bash).

Bibliografía

Estos son algunas de la fuentes y materiales en los que está basada la materia:

  • The Pragmatic Programmer, de Hunt & Thomas
  • Software Craftsmanship: The New Imperative, de Pete McBreen
  • Code Complete, de Steve McConnell
  • The Software Craftsman, de Sandro Mancuso
  • Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, de Oshineye & Hoover
  • The Design of the Design, de Brooks
  • Atomic Habits, de James Clear
  • Implementation Patterns, de Beck
  • Refactoring to Patterns, de Kerievsky
  • xUnit Test Patterns, de Meszaros

A esto se suman varios artículos (algunos formales y otros no tanto) y algunos videos.

Inscripción

Si el lector llegó hasta este punto, posiblemente se esté preguntando donde se dicta esta materia. La respuesta es que no lo sé. Por el momento tengo armada la estructura de la materia, algunos materiales, muchas ideas pero no tengo institución para dictarla. Claro que podría hacer un curso «no académico» y dictar esto por mi cuenta, pero precisamente lo pensé como materia porque me parece que es un contenido faltante en las carreras de grado de sistemas/computación. Creo que estos temas deben ser parte de la formación académica de los profesionales de esta disciplina.

En fin, por lo pronto y mientras veo como meter esto en una institución, si estás interesado en tomar este curso te invito a que completes este formulario y en cuanto tenga más definiciones me contactaré contigo.

Reflexiones de 6 meses de trabajo con Django

Hace unos 6 meses comencé a trabajar en un proyecto Python/Django. Si bien yo ya tenía cierta familiaridad con Python, nunca había trabajando con Django, la mayoría de las cosas que había hecho a nivel profesional tenían que ver con scripts para automatizar tareas de deployment.

Para ser justo, me parece que antes de compartir mis reflexiones debo explicar algunas cuestiones de contexto que pueden tener cierta influencia en mis percepciones.

  • El primer punto es importante: no estuve trabajando en un proyecto nuevo, sino en una aplicación existente. Más concretamente una aplicación creada hace ya varios años con Python 2.7 y Django 1.4.
  • La aplicación tiene una cantidad no despreciable de código JavaScript, no React, no Angular, JavaScript puro, «vanilla JavaScript» condimentado apenas con jQuery. Esto es un punto no menor, porque parte del tiempo lo he pasado trabajando con código JavaScript en lugar de Python.
  • La aplicación cuenta con unos 1000 test automatizados del código python y también tiene tests automatizadas de parte del código JavaScript.
  • Esta aplicación Django es la parte central de un ecosistemas de aplicaciones, la mayoría de ellas también construidas con Python pero no necesariamente con Django.
  • Finalmente el último detalle contextual es que las funcionalidades en las que estuve trabajando tuvieron que ver con cuestiones «algorítmicas/lógica de negocio», o sea, no tuve que modificar el modelo de datos.

Aclarado el contexto ahora sí mis percepciones. Definitivamente Django es a Python lo que Rails es Ruby con todo lo bueno y lo malo que eso pueda implicar. Django es un framework orientado a la creación de sistemas de información (CRUD) y como tal ofrece muchas facilidades para con relativamente poco código resolver muchas de las cuestiones planteadas por este tipo de aplicaciones: validaciones, persistencia de datos, envío de mails, autenticación, manejo de usuarios, sistema de backoffice/admin, etc. Todo esto complementado con una funcionalidad de scaffolding que genera una porción importante de nuestro código.

Todas estas facilidades que provee Django no son «gratis», tienen un costo asociado el cual implica que la aplicación tiene cierta estructura que en ocasiones puede ser un dolor de cabeza. En este sentido un punto que me resulta particularmente molesto es el grado de acoplamiento con la base de datos que dificulta la escritura de pruebas unitarias ya que al momento de escribir pruebas que utilicen las entidades de negocio (lo que Django llama models) es necesario tener una conexión con la base de datos. Otra cuestión que me resulta muy molesta es la convención de utilizar «pocos archivos pero muy grandes», ejemplo: en vez de tener un archivo por cada clase, un archivo por cada controller, etc, la propuesta es tener un archivo models con todas las clases de entidades, un archivo views con todos los controllers, etc, etc.

Por otro lado hay dos cuestiones que me resultan fantásticas: el debugger de línea de comando (que en realidad es un funcionalidad de Python, no de Django) y el Django shell, que al igual que el Rails console, nos permite manipular de forma interactiva los objetos de nuestra aplicación.

Otra cuestión, en este tipo de frameworks, es el manejo de la persistencia. Al igual que Rails, la persistencia está implementada al estilo ActiveRecord. Esto es que cada entidad/model hereda de una clase base provista por el framework la cual nos provee todo un conjunto de métodos para «llevar y traer» objetos de la base de datos y de esta forma no tenemos que lidiar con la escritura de SQL.

Finalmente el último punto que quiero mencionar es la sensación (y resalto que es una sensación) de que Django «nos lleva a hacer aplicaciones grandes» en contraposición con las tendencias actuales de micro-servicios. Ojo, no digo que el frameworks nos obligue a hacer aplicaciones grandes, sino que algunas de las funcionalidades que provee (como la posibilidad de tener varias aplicaciones dentro de un mismo proyecto) resulta muy tentador para seguir trabajando dentro del mismo proyecto/artefacto en lugar de crear un nuevo proyecto independiente.

En fin, si bien hay cuestiones que no me gustan nada, hay algunas otras que están muy bien.

Recomendación de libros de «autoayuda»

En esta ocasión voy a referirme a un conjunto de libros que en algún momento (y por puro prejuicio) los habria categorizado como libros de «autoayuda» sin siquiera tener en claro que implica «autoayuda». El punto es que más allá de la categoría son libros que me han resultado muy útiles e interesantes.

El primero de estos libros que quiero mencionar lo leí allá por 2008: Los 7 hábitos de la gente altamente efectiva. Ya en aquel momento este libro era un best seller. Tanto es así que a pesar de que originalmente está en inglés, también ha sido traducido a varios idiomas. De hecho, yo lo leí en castellano. Su autor, Stephen Covey, ha escrito varios libros más en relación a esta misma temática. A partir de este libro fue que empecé a trabajar la formación de ciertos hábitos en mi materia de Ingeniería de Software.

Otro libro que también leí por aquella época es el ya clásico de Francesco Cirillo: «The Pomodoro Technique«. Esta técnica ha cobrado tal popularidad que se han generado una importante cantidad de recursos relacionados entre los que se incluyen varios videos, apps y cursos. Personalmente esta técnica me ha ayudado mucho a enfocar mi trabajo y suelo recomendarla a mis alumnos y colegas. De hecho recuerdo que en la época que dictaba Ingeniería de Software en UNQ, esta era una de las lecturas obligatorias de la materia (mientras escribo estas líneas creo que debería incluir esta lectura en mi materia de UBA).

Finalmente esta semana terminé de leer el libro «Atomic Habits» de James Clear. Este lo compré a comienzos de 2020 a partir de una mención que hizo en Twitter mi colega @hhiroshi. El libro me gustó mucho por varias cuestiones. Encontré justificación «teórica» para varias cuestiones que suelo hacer. También encontré muchas cuestiones para experimentar. Muchos de los capítulos comienzan con anécdotas/historias que hacen muy llevadera la lectura. Un tema no menor en relación con la lectura es la extensión de los capítulos, tienen una extensión tal que permite completar un capítulo en unos 15 minutos (al menos a mi ritmo de lectura). El tema de la generación de hábitos me parece fundamental para trabajar de forma más efectiva. El tener incorporadas ciertas tareas como hábitos hace que uno pueda ejecutar esas tareas de forma «automática» sin necesidad de poner energía/atención extra y de esa forma poder ahorrar esa energía/atención para dedicarla a otras cuestiones de mayor prioridad/valor. Este libro ofrece todo un marco teórico junto con técnicas concretas para generar hábitos y también para eliminar hábitos.

Balance 2021

Se fue el segundo año de pandemia, pero a diferencia del anterior, este año ya estaba planeado para trabajar en forma remota. Y así fue, solo fui a la universidad para la clase de cierre de Ingeniería de Software @UNTreF y solo fui a la oficina 2 días para una reunión de planificación estratégica y para el almuerzo de fin de año.

Mi tiempo total de trabajo (en términos de horas facturables) este año fue radicalmente menor que el año anterior. A su vez, este año por primera vez en mi carrera tuve una dedicación pareja de trabajo en industria y trabajo en academia.

Dedicación Industria vs. Academia

Dentro de mi trabajo en la industria gran parte fue dedicada a cuestiones de capacitación. Lo referente al trabajo de consultoría fue principalmente relacionado a cuestiones de DevOps/Automatización de Pruebas/Infra/Deployment.

Dedicación de actividades de industria

En lo que respecta a las actividades de academia lo principal fue el dictado de mis materias pero adicionalmente a eso hice otra actividades como:

  • Dirección / Evaluación de trabajos finales de carrera
  • Evaluación de pares para la CONEAU
  • Revisión de artículos como miembro del comité de programa del track de educación de ICSE.

En lo que respecta a participación en conferencias este año participé en muy pocas. Sinceramente las conferencias en formato virtual no me resultan atractivas. Presenté sesiones en XP, Agiles Latam, Agile Brazil y Agiles en Español.

En lo que respecta a publicaciones apenas hice dos publicaciones pero ambas resultaron muy interesantes. Publiqué un reporte de experiencia en la conferencia XP y publiqué mi primer artículo en un journal: nuestro artículo final del proyecto Helena «What Makes Agile Software Development Agile» fue publicado en el journal IEEE Transactions on Software Engineering.