La extrema izquierda y la extrema derecha en el desarrollo de Software

En el mundo del desarrollo de software, así como en la política y en general, en cualquier otro ámbito profesional, nos encontraremos con una serie de circunstancias, situaciones y problemas ante los cuales nosotros y nuestros colegas tomaremos posturas que pueden clasificarse como posturas de derecha u ortodoxas y posturas de izquierda o “liberales”, así como toda la gama de puntos intermedios entre unas y otras. También, de forma análoga a como ocurre en la política, entre mayor sea el mosaico de posturas presentadas, mejor será el análisis y el consecuente plan de acciones para resolver la situación en cuestión. En empresas como Scio Consulting, donde la diversidad de opiniones es respetada y fomentada, dicho ejercicio se da de manera natural y nos permite realizar retrospectivas sobre ello.

Otra analogía entre la política y el desarrollo de software en este sentido es que, en general, a pesar de que las posturas de extrema derecha o extrema izquierda pueden llegar a funcionar en un contexto determinado, las posturas moderadas o centralistas tienden a presentar mayores beneficios a mediano y largo plazo, tanto para el individuo, como para el proyecto del que se trate y para la empresa en general. En este sentido, la finalidad de este artículo no es de ninguna manera menospreciar o dar como incorrectas o inadecuadas las posturas extremas, ya que a diferencia de la política, la industria del desarrollo de software es una industria noble en cuanto a la cantidad de enfoques, métodos y formas con las que se puede resolver el mismo problema. La finalidad es simplemente, presentar dos escenarios relativamente comunes en esta industria, analizar las posturas que se pueden tomar al respecto y resaltar los beneficios de las posturas moderadas.

Situación 1

El equipo de desarrolladores para un proyecto nuevo que se iniciará desde cero se reúne para discutir los detalles sobre la estructura y cobertura de las pruebas de código.

Postura altamente ortodoxa: El equipo debería tener un 100% de cobertura en cuanto a código escrito. Cada método en cada clase en cada capa del proyecto debe ser probado tanto en los escenarios definidos como en los no contemplados.

Postura altamente heterodoxa: El equipo de desarrollo debería de dedicarse a codificar únicamente funcionalidad y dejar a los analistas de calidad la realización y ejecución de las pruebas.

Ciertamente la postura ortodoxa puede garantizar y blindar la calidad del código escrito, pero, ¿el equipo dispone de suficiente tiempo? ¿Se ha estimado la duración del proyecto considerando que cada desarrollador analizará y probará exhaustivamente cada pieza de código? Por otro lado, si el proyecto usará frameworks, plugins y arquitecturas que ya han sido probadas exhaustivamente por sus autores ¿Valdría la pena probarlos nuevamente una vez integrados al código? La postura heterodoxa puede ser tentadora para el equipo de desarrollo, pero, ¿cómo se tendrá la certidumbre de que al realizar un cambio en el futuro no impactará funcionalidad dependiente o adyacente? Si en el futuro se requiere de una reescritura parcial o total del código ¿deberá de confiarse a los analistas de calidad la integridad del proyecto, con los recursos y tiempo que representan una regresión completa?

La postura moderada en este caso, al tratar de conciliar ambas, sugiere identificar la lógica de negocios, que suele ser la parte más sensible e importante de cualquier sistema, encapsularla adecuadamente y generar las pruebas unitarias y de integración que garanticen su integridad y correcto funcionamiento, “sacrificando” las pruebas relativas a los componentes externos, conexiones entre capas y cualquier cosa fuera del alcance directo de dicha lógica.

Situación 2

El cliente de un proyecto de una aplicación web importante de gran escala solicita al equipo de desarrollo un cambio completo en la forma y estructura de la interfaz de usuario. El equipo, quien tiene una deuda técnica moderada en el proyecto, decide que es buen momento para reescribir y mejorar un porcentaje importante de la lógica del servidor. El proyecto no cuenta con pruebas automatizadas que verifiquen la estabilidad del código después del cambio pero el equipo conoce la aplicación ya que ha trabajado en ella por un par de años.

Postura heterodoxa: Con la finalidad de “agilizar” los trabajos, los cambios de interfaz y los cambios de lógica en el servidor se efectuarán en paralelo, dejando al final la conexión de ambos cambios.

Postura altamente ortodoxa: Abordar al cliente para analizar la posibilidad de mantener la interfaz actual y realizar solo cambios parciales en los lugares que considere críticos.

En el caso de la postura ortodoxa, se está cuidando el estado funcional actual de la aplicación, pero seguramente los cambios parciales a los que se refiere tiendan a aumentar la deuda técnica del proyecto, además de que debe convencerse al cliente de tomar una postura diferente a la que inicialmente pensó y probablemente exponga en algún momento la deuda técnica del equipo. La postura heterodoxa por su parte es, en una sola palabra: temeraria ¿el equipo es consciente de que al concluir los trabajos, la única manera de garantizar la funcionalidad del sistema es realizar una regresión total, con el tiempo y recurso que ello implica? ¿Cómo se trabajaran ambos cambios en paralelo? ¿Si se trabaja en ramas de código separadas, existe la certidumbre de que los cambios son encapsulados y el trabajo de uno no genera conflictos con el otro? ¿Si el proyecto requiere mantenimiento mientras se efectúan los cambios, en que rama deberían trabajarse? ¿Qué tan seguido deberían realizarse integraciones al núcleo del código? ¿Qué ocurre si ambos trabajos requieren tiempos diferentes y uno termina mucho antes que el otro?

Una postura moderada probablemente propondría completar los cambios de la interfaz de usuario tal como los solicitó el cliente, sin tocar cualquier otra parte del código, y una vez verificado que el acoplamiento de la nueva interfaz ha sido exitoso, realizar los cambios que se requieran para solventar la deuda técnica, en orden prioritario, de manera focalizada y hasta donde el tiempo lo permita.

En ambas situaciones es fácil identificar que las posturas moderadas son las que tienen mayor probabilidad de éxito y sobre todo de mantener la salud del proyecto y de sus integrantes. Así que la invitación es finalmente, a debatir las propuestas que se generen ante una situación específica, escuchar o plantear las que se consideren más radicales en ambos sentidos y conciliar u optar por una que sea equilibrada o moderada.

Julio Orozco

Julio Orozco