Cualquier sustancia puede ser un veneno; es la dosis es la que realmente hace que algo sea venenoso. Con esta famosa cita Paracelso, padre de la toxicología moderna, establecía que la cantidad de una sustancia es tan importante como su propia naturaleza: una pequeña dosis de aspirina puede ser beneficiosa, pero en dosis altas puede ser mortal.
En la misma línea una pequeña dosis de elementos de calidad para un diseño software, como, por ejemplo, los patrones de diseño, puede ser beneficiosa para el mismo, pero dosis muy altas pueden resultar fatales. Y a este respecto el problema que solemos encontrar en ingeniería del software es que desconocemos la cantidad óptima de soluciones de diseño, como patrones u otros, la dosis necesaria y el valor que estos aportan al diseño.
El diseño software ha evolucionado mucho, y se han aportado al mismo un conjunto amplio y rico de estrategias de calidad, como los patrones, los principios (Martin, 1996), heurísticas (Riel, 1996), malos olores (Fowler, Beck, Brant, Opdyke, & Roberts, 2000), etc., sobre las que se ha realizado un gran esfuerzo para su mejor aplicación y clasificación (Garzás & Piattini, 2005), pero no tanto para su valoración.
No conocemos el valor que aporta cada uno de estos elementos a un diseño concreto, donde cada patrón o regla de diseño es considerada con la misma importancia. Por ello en muchas ocasiones los diseños se sobrecargan de patrones y similares, y donde se suponía que estos iba a aportar mejoras se reduce la calidad, y se introducen diversos problemas de mantenimiento (Wendorff, 2001).
Por ejemplo, supongamos un diseño que contiene una clase con un método tipo “cron” que envía periódicamente mensajes a dos objetos, perteneciendo cada uno de estos objetos a diferentes clases, que llamaremos clase A y clase B. Esto puede generar un problema de mantenimiento, porque si queremos ampliar la lista de objetos a los que se envía periódicamente el mensaje y estos pertenecen a otras clases, como por ejemplo las clases C y D, debemos modificar y volver a compilar la clase que contiene el cron. En este momento, observamos que la aplicación de un patrón “observer” (Gamma et al., 1995) puede aportar gran valor, porque solucionaría el problema del acoplamiento permitiendo añadir objetos receptores del mensaje de manera dinámica sin tener que modificar la clase del cron. A priori parece una opción económicamente rentable, ya que ahorraría tiempo (horas/hombre) de mantenimiento. Sin embargo:
- ¿Qué ocurre si en el futuro la clase cron nunca tiene que ser modificada?, ya que nunca se necesite cambiar su funcionalidad, la del cron, ¿hubiese sido rentable modificarla?
- ¿Cuál es el coste de refactorizar nuestro diseño para introducir el patrón observer? Pudiera ser superior a modificar la clase con el cron.
- ¿Es esta solución más valiosa que cualquier otra, y en qué medida? ¿es la prioritaria?
- Si se aplicara este mismo patrón en otros sitios similares, ¿aportaría el mismo valor que en este caso? ¿qué patrones son más prioritarios?
Es difícil saber qué dosis de patrones no es venenosa para un diseño.
Contestar estas preguntas es fundamental si planeamos un rediseño a gran escala, en el que se detectan cientos de problemas de mantenimiento y cientos de reglas, patrones y soluciones a aplicar. Y por ello, además, es difícil justificar en términos económicos las decisiones de diseño. Establecer qué rentabilidad obtendremos de dicha mejora, qué mejoras son económicamente más convenientes o su prioridad.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: La agilidad está muriendo. Bienvenido el postagilismo - Javier Garzás, sobre calidad software y otros temas relacionados
Se que es un post antiguo, pero vigente mi modo de ver.
Me ha pasado mucho lo que expones. Me he encontrado con novatos versados, es decir que conocen muchas cosas como los patrones, y ocurre lo de que para quien aprende a usar un martillo todo parece un clavo. Un uso indiscriminado e injustificado de los patrones de diseño y demás técnicas. Sólo por que es «bueno» usarlos, sin medir el aporte o la necesidad de tal solución o estrategia.
En ámbitos académicos se justifica esta tendencia, puesto que esos desarrollos tienen un propósito particular, pero en entornos reales y productivos, este tipo de decisiones o prácticas pueden ser mortales.
Igual siempre manifiesto que tan útil es saber usar algo, como saber cuando no usarlo…
Y es allí donde entra el sentido común y la experiencia.
Saludos