“Good enough” Software Engineering

Por estos días me encuentro leyendo el libro “Software Craftsmanship: The New Imperative” de Pete McBreen. Es un libro que tiene casi 20 años y que a mi entender no ha tenido gran difusión. De hecho yo lo encontré por casualidad. No es mi idea en este artículo resumir el libro sino simplemente detenerme en esta idea de “Good Enough Software Engineering” que es una de las ideas que menciona el autor en la primera parte del libro y que recientemente me resonó mucho a partir de un intercambio de mensajes con mi colega Carlos Peix.

McBreen pone en tela de juicio el “enfoque formal” propuesto por la ingeniería para el desarrollo de software. Argumenta que la ingeniería de software resulta sin duda un enfoque apropiado para ciertos tipos de sistemas que implican el desarrollo conjunto de hardware + software y que ponen en juego la vida humana. En este sentido menciona proyectos militares y aeroespaciales. Sin embargo cree que el enfoque de ingeniería de software no es apropiado para el desarrollo de lo que llama “software comercial”, cuyo desarrollo no requiere del desarrollo de un hardware particular y que no pone en juego vidas humanas, pero que tiene ciertas restricciones de mercado. Dicho de otra forma: los trade-offs que pueden hacerse en cada uno de estos dos tipos de proyectos son distintos y eso da lugar a distintos enfoques. Según MeBreen el desarrollo de software comercial va mejor con un enfoque de “good enough software” que con un enfoque de “Ingeniería”.

Creo que somos varios a los que nos resuenan estos cuestionamientos que hace McBreen. De hecho recuerdo un artículo de David Parnas publicado en IEEE Software: Software Engineering – Missing in Action: A Personal Perspective, en el cual también se cuestiona el enfoque de ingeniería para el desarrollo de software. McBreen insiste en que para muchos contextos (la mayoría según él) hay enfoques más apropiados que el de ingeniería de software. Más aún, cree que hay varios enfoque posibles pero se inclina a hacia un enfoque de “artesanía”.

Estas reflexiones plantean interesantes dilemas para practicantes y académicos. Como practicantes debemos entonces ante cada nuevo proyecto decidir que enfoque utilizar. Como académicos aparecen algunos cuestionamientos profundos:

  • ¿está bien que las carreras de informática sean ingenierías o deberían ser licenciaturas y de esa forma despegarse de la “carga conceptual/cultural” que la ingeniería impone?
  • ¿es posible/conveniente cubrir dentro de una misma carrera enfoques de ingeniería y de “no ingeniería”?
  • ¿deberíamos tener carreras más específicas en línea con distintos enfoque de desarrollo?

Mi sensación es que en la actualidad muchas carreras, independientemente de su nombre, proponen un enfoque ingenieril pero luego una importante porción de sus egresados terminan trabajando en proyectos que podrían resultar más afines a un enfoque de artesanía.

Un detalle importante aquí es que un enfoque de ingeniería no es más completo ni abarcativo que un enfoque de “no-ingeniería” sino que es divergente. Esta divergencia que yo veo no es necesariamente conceptual sino “operativa” en un punto: las carreras tienen un límite de tiempo, enseñar un enfoque de ingeniería trae de entrada toda una base de conocmiento que reduce el espacio/tiempo para estudiar otras cuestiones. Esto queda muy en evidencia cuando en la actualidad vemos “ingenieros de software” que no buenos desarrolladores. Mi percepción es que muchas de las carreras actuales de “Ingeniería” (más allá de que sean formalmente ingenierías o licenciaturas) no forman buenos desarrolladores.

En fin, creo que este tema da para mucho, continuaré.

Estilos de TDD: London vs. Chicago

Hace un tiempo cobró cierta popularidad entre los practicantes de TDD el debate sobre los denominados estilos o escuelas de TDD: “London” y “Chicago”. Hay varias explicaciones en la web sobre las diferencias de estos estilos ([1][2][3][4]) que podríamos resumir brevemente en dos dimensiones:

  • Flujo
    El estilo Chicago (también denominado “tradicional”) propone un desarrollo de adentro hacia afuera, se comienza por los objetos del dominio y luego se agrega la capa de interface/controllers.
    El estilo London propone un desarrollo de afuera hacia adentro, lidiando de entrada con las cuestiones de interface/controllers y llegando a los objetos de dominio a partir de las necesidades que la interface/controllers nos va demandando.
  • Aserciones:
    En el estilo Chicago los tests hacen asserts sobre el estado de los objetos y los resultados.
    En el estilo London los tests están más enfocado en la interacciones entre los objetos y para ello depende en gran medida del uso de mocks.

Estos dos estilo dieron un salto de popularidad a partir de una serie de videos realizados por Bob Martin y Sandro Mancuso. En estos videos Bob (Chicago) y Sandro (London) muestran y comparan el desarrollo de una aplicación (Rest API) utilizando estos dos estilos.

Al estilo Chicago se lo suele asociar al libro Test-Driven Development by Example de Kent Beck mientras que al estilo London se lo suele asociar con el libro Growing Object-Oriented Software Guided by Tests de Freeman y Pryce. Sin embargo, a mi parecer, comparar los enfoques London y Chicago a partir de estos dos libros me parece errado porque el alcance y foco de las propuestas descriptas en estos libros es distinta. El libro de Beck es un libro que tiene un foco claro en el uso de TDD a nivel del modelo de objetos de dominio. Por su parte, el libro de Freeman tiene un foco es más amplio, apunta al proceso de desarrollo de una aplicación (no solo del modelo de objetos de dominio). Es así que el libro de Freeman contempla también cuestiones como arquitectura hexagonal, walking skeleton e integración continua. Tengamos presente que el libro de Beck es de 2003 mientras que el de Freeman es de 2009. Al mismo tiempo en su perspectiva de desarrollo de una aplicación, el libro de Freeman plantea un doble ciclo de tests donde el ciclo interno es el que coincide con el ciclo de TDD que plantea Beck. Es por esto que no creo que sea Freeman o Beck, sino que los veo como complementarios.

Volviendo a London vs. Chicago, un punto central en la discusión es el uso de mocks. Si solo pensamos TDD para el desarrollo del modelo de objetos de dominio puede que el uso de mocks no resulte útil. Pero si ampliamos el foco de la discusión y consideramos el desarrollo de una aplicación completa incluyendo las cuestiones de “infraestructura” (interfaces, persistencia, etc.), entonces los mocks toman otra relevancia/utilidad.

Continuará…

[1] https://josemyduarte.github.io/2018-12-09-tdd-outside-in/
[2] https://devlead.io/DevTips/LondonVsChicago
[3] https://dev.to/hiboabd/a-beginners-explanation-of-the-chicago-london-approaches-4o5f
[4] https://nvoulgaris.com/comparing-tdd-flavours/


Sobre mi sesión de trunk-based development @ Agiles2020

En lunes pasado presenté mi sesión sobre Trunk-based Development en Agiles 2020. La presentación fue vía Zoom pero como al finalizar el tiempo estipulado aún quedaban algunas cuestiones por hablar, la continuamos por Jitsi. Participaron unas 50 personas y yo personalmente quedé muy conforme con como salió la sesión.

Hay una cuestión que salió durante la charla y que no deja de llamarme la atención al hablar de modelos de branching. Hay gente que cree que tener un repositorio centralizado y un build server es hacer integración continua. Pues no, no lo es, no es suficiente pues la práctica de integración continua implica que adicionalmente todo el código debe ser integrado al menos una vez al día. Cuando digo integrado me refiero a integrar en un mismo branch todo el trabajo en curso. Esto es algo básico que está explícitamente mencionado en el clásico artículo de Fowler sobre Integración Continua como lo muestra la imagen a continuación:

Hacer Feature branches puede o no ser integración continua dependiendo de la duración de esos branches. Si los branches viven a lo sumo 1 día, está ok. En fin, es un tema que me resulta importante y en breve le dedicaré un artículo en profundidad.

Finalmente quiero agradecer a la organización de Agiles 2020 por haberme invitado a presentar y también a los participantes que se sumaron a la sesión. Les comparto aquí las diapositivas utilizadas en mi sesión.

Egreso online de Ingeniería en Computación @ UNTreF

El miércoles pasado asistí a una defensa de trabajo final de carrera en modalidad online. El ponente fue Gonzalo Cozzi, quien presentó su trabajo final para obtener el título de Ingeniero en Computación de la Universidad Nacional de Tres de Febrero. Los jurados evaluadores fueron Carlos Fontela, Diego Fontdevila y Diego Marcet. También estuvo en la defensa el director de la carrera Alejandro Oliveros. Yo participé en la presentación en calidad de director del trabajo presentado.

La presentación de Gonzalo fue muy sólida, ordenada y en tiempo. Los jurados felicitaron a Gonzalo por el trabajo realizado. Yo como director del trabajo también quedé muy satisfecho, tanto con el resultado como con todo el proceso de trabajo.

El trabajo en cuestión consistió en el desarrollo un radiador de información incluyendo una solución integral de software y hardware y soportando distintas arquitecturas de despliegue:

  • SmartTV + Cloud
  • SmartTV + Raspberry Pi
  • TV/Monitor + Raspberry Pi

El software está desarrollo con una arquitectura hexagonal, la cual a partir de un modelo de ports and adapters permite integrar distintas herramientas de una habitual con los proyectos de desarrollo. Out-of-the-box hay soporte de conectores para GitHub, GitLab, Redmine y Travis-CI.

Todo el código del proyecto está disponible en GitHub bajo licencia GPL-V3.

Algunos punto interesantes para destacar de este trabajo:

  • Se buscó proveer una solución integral contemplando software y hardware.
  • El trabajo está publicado con licencia de código abierto.
  • El trabajo está desarrollado de forma tal que permite muy fácilmente incorporar extensiones lo cual puede significar un oportunidad interesante para trabajos finales de otros alumnos (interesados no duden en contactarme).
  • Adicionalmente a la presentación formal de trabajo en la universidad, el mismo también fue presentado en un congreso de ingeniería.

¡Felicitaciones Gonza!

Abajo (los jurados): Carlos, Diego y Diego
Arriba: Nico, Alejandro y Gonzalo