Por Francisco Mesa
Todas las personas que se dedican al desarrollo del software se tienen que enfrentar a una situación en la que más que poner a prueba sus hard skills en un lenguaje o framework, mide su aplicación de buenas prácticas y comprensión del ciclo de vida en el desarrollo.
Esta semana he recordado una situación para la que no te suelen preparar durante la formación reglada, o no, del desarrollo del software. Es una situación que aparece regularmente y que obliga al equipo a enfrentarse a situaciones en las que cuentan más las soft skills que un conocimiento detallado de la tecnología.
Tener que resolver un dilema no es una situación exclusiva de la programación. Ni mucho menos. Más bien se puede afirmar que está relacionada directamente con todas las actividades creativas, o que requieren un esfuerzo intelectual. Otras profesiones, como la investigación científica, o el periodismo que he podido conocer de primera mano, también se encuentran con situaciones parecidas. He comprobado cómo tienen que tomar decisiones sobre qué redactar, o con qué enfoque hacerlo, teniendo al alcance de la mano solo informaciones parciales que parecen llevar a una conclusión.
En este proceso de descubrimiento es vital el conocimiento del creador del momento, su entorno, historia, hechos recientes… y otros elementos propios del oficio. Si nos abstraemos de las situaciones específicas, podemos encontrar en otras profesiones ciertas características comunes al desarrollo del software: trabajar con incertidumbre, necesidad de conocer el dominio del negocio, la importancia de contar con experiencia en situaciones parecidas y generar conocimiento que radiografía la complejidad intrínseca del problema.
La creación de software con una pirámide de tests que respalden y documenten la semántica del código ayudan al cliente a reducir su TCO (total cost of ownership) que va mucho más allá del desarrollo del software. Los objetivos de cada persona involucrada en este ciclo son diferentes y si el objetivo de un desarrollador es crear software de calidad, el del responsable del proyecto es que, además, sea software mantenible y, por lo tanto pueda adaptarse y pasar por diferentes manos sin sufrir una curva de aprendizaje pronunciada cada vez que una persona tiene que modificar el código.
Aprender a trabajar con estos elementos de incertidumbre deberían de incorporarse durante la formación de los desarrolladores ya que son parte del negocio. La construcción de software casi nunca es un ejercicio en el que se conocen todos los requisitos del problema, en un entorno claramente definido y con todas las preguntas necesarias ya respondidas a priori para ser utilizadas a medida que sean necesarias. No. En el mundo real la captura de requisitos ha sido históricamente uno de los grandes hándicaps del desarrollo del software y por ese motivo es tan importante la documentación y la incorporación de metodologías ágiles que adelanten esta captura de requisitos. En otras ocasiones, simplemente no se conocen, o no es fácil verlas ya que se está creando un entorno nuevo.
Por si fueran pocos estos elementos, hay una variable limitante que condiciona lograr con éxito los objetivos: el tiempo. El informativo de radio, televisión, la edición impresa, o la urgencia de publicar en internet condiciona la actividad del periodista. ¿Sucede lo mismo en el desarrollo de software? Cualquiera que haya leído la pregunta y que tenga como profesión la programación mostrará perplejidad ya que conocen de primera mano el estrés que pueden generar los deadlines. Se puede pensar que practicando estrategias divide y vencerás, definiendo sprints y manteniendo un backlog se reduce significativamente la incertidumbre, pero la experiencia nos demuestra que no es así. Aparecen problemas inesperados, no siempre se cuenta con hard skills suficientemente desarrolladas para el proyecto, o se cambian/aparecen requisitos durante el proyecto. Problemas que deben de abordarse lo antes posible sin por ello entorpecer el ritmo del trabajo.
Tom Cargill popularizó en 1985 la aplicación empírica del principio de Pareto al desarrollo del software:
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time
Tom Cargill, Bell Labs
Un 180% de tiempo que recuerda al colectivo profesional los problemas de cumplimiento de los tiempos inicialmente previstos en un proyecto de desarrollo debido a la incertidumbre inicial, los cambios de especificaciones durante el desarrollo, o cualquier otra situación que retrasa el proyecto.
En no pocas ocasiones es necesario afrontar una pequeña parte del código, ese 10%, que incorpora la complejidad intrínseca del problema y cuya comprensión y creación de la solución requiere una inversión de tiempo muy superior al resto del proyecto, sin llegar necesariamente al extremo de que suponga un 90% del tiempo invertido. Si los retrasos ya suponen de por sí un problema, aunque se obtenga finalmente una solución correcta y funcional, puede caerse en el error de no plasmar de forma evidente sus características intrínsecas. Los motivos son diversos: agotamiento mental, dificultad en entender una abstracción del problema, o un deadline cercano en el tiempo.
Es en este momento cuando surge el dilema del equipo de desarrollo. Una duda marcada por la disyuntiva de elegir entre incrementar el tiempo invertido en mejorar la calidad del chunk de código, reduciendo la inversión que se tenga que realizar a posteriori para su compresión, o dejarlo en una solución de compromiso, mejorada o no respecto a la inicial, con el fin de evitar posibles retrasos innecesarios. Todo esto sucede mientras se sigue invirtiendo un valioso tiempo en esta decisión.
La respuesta ideal al dilema para el proceso de desarrollo es obvia, cuanto más legible sea el código, más se reduce el coste final para el cliente. Este objetivo en parte va en sentido contrario a los que tiene el product owner que no puede esperar indefinidamente por una solución. La experiencia también nos demuestra que en el mundo real no siempre se puede llegar inicialmente a una solución óptima por las limitaciones propias del proyecto, ni el propio cliente final que puede no conocer el negocio al nivel de detalle que requiere la creación de una solución informática.
El grupo de desarrollo, y esto incluye al product owner, tiene que enfrentarse regularmente a este dilema. Es decir, ponen en la balanza alcanzar los objetivos en tiempo, reducir el coste total del software y obtener la mejor calidad posible en la solución.
Estas situaciones son ajenas a la calidad del equipo. Aparecen por muy experimentado que sea y capaces de crear código de calidad de forma eficiente. Por todos estos motivos es tan importante que el equipo de desarrollo, especialmente en las empresas de servicio, aplique las buenas prácticas de programación, practique principios como SOLID, TDD, Clean Code… Cuanto más formado y experimentado esté el equipo en estos principios, mejor solución de software se genera, mejor comprensión del problema será capaz de conceptualizar el equipo y desarrollará para las próximas personas que tengan que realizar cambios. Es decir, se reduce la aparición de estos dilemas y el tiempo necesario para resolverlos. No solo se trata de que suponga un menor coste final del producto, también hace más fácil reconocer qué falta para llegar a la solución óptima, poder transmitirlo al cliente y facilitar el proceso de mejora en futuras iteraciones del código.
Disclaimer: Considéralo un artículo WIP. ¿Te sientes identificado? ¿Hay alguna premisa incorrecta?
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
