Nota del autor

Si la entrada que estás leyendo carece de imágenes, no se ve el vídeo que teóricamente lleva incrustado o el código fuente mostrado aparece sin formato, podéis conocer los motivos aquí. Poco a poco iré restableciendo la normalidad en el blog.
Este blog es un archivo de los artículos situados previamente en Lobosoft.es y ha dejado de ser actualizado. Las nuevas entradas pueden encontrarse en www.lobosoft.es. Un saludo,
Lobosoft.

martes, 23 de febrero de 2010

La perfidia del software

En una de las asignaturas que estoy cursando este cuatrimestre se nos ha planteado un acercamiento a los “problemas retorcidos” o, usando un término que prefiero, “problemas perversos” (o pérfidos, o impíos, resulta difícil dar una traducción exacta a los conocidos en ámbitos anglosajones como wicked problems). Los problemas perversos fueron definidos por Rittel y Webber dentro del contexto de la planificación social, donde una aproximación meramente científica o técnica no sería suficiente para dar respuesta a aquellos aportando, por tanto, una solución total. Son problemas, por tanto, de difícil cuando no imposible solución (y no tienen nada que ver, por cierto, con las clases de complejidad computacional).


El desarrollo de software puede verse como un problema perverso ya que cumple con seis de las diez características que los definen, a saber:




  1. No existe una formulación definitiva del problema.

  2. No se puede saber cuándo termina el problema.

  3. Las soluciones que se pueden aportar no son verdaderas o falsas, sino buenas o malas.

  4. Cada problema es esencialmente único.

  5. Todas las soluciones para un problema de este tipo se pueden poner en práctica una única vez, ya que no existe una oportunidad para aprender mediante ensayo y error.

  6. Los problemas perversos no cuentan con un conjunto de soluciones posibles que pueda ser rigurosamente descrito.


Todo lo anterior nos lleva a que podamos afirmar que es más rápido crear una solución al problema que estimar cuánto tiempo tomará crear una solución que posea un determinado grado de exactitud y, aun así, la estimación seguirá estando mal.


La regla fundamental para manejar problemas perversos es que no deben ser tratados como los problemas clásicos. Según Rittel y Webber: "El enfoque de los sistemas clásicos ... se basa en la suposición de que un proyecto ... se puede organizar en fases distintas: “ comprender los problemas “,” recoger información”, “sintetizar la información”, “buscar soluciones” y similares. Con los problemas perversos, sin embargo, este tipo de sistema no funciona. No se puede comprender el problema sin conocer su contexto, uno puede buscar, no significativa de información sin la orientación de un concepto de solución, no es posible entenderlo primero, y luego tratar de resolverlo. "


La mejor manera de abordar los problemas perversos es de hablar de ellos, trabajar desde posibles enfoques y de forma colaborativa donde aparezcan en escena los intereses, prioridades y limitaciones existentes. Es imposible usar herramientas de análisis usuales antes de, ya no reducir el problema, sino posiblemente saber cómo enfocarlo. Durante esta fase puede ser interesante utilizar herramientas como Compendium.


Una vez implicados en el alcance de una solución (posiblemente de compromiso), dada la variabilidad del problema, que puede ir cambiando conforme se esté trabajando en él, resulta interesante aplicar metodologías ágiles para facilitar posibles cambios y evitar que supongan un problema a añadir. En este aspecto resulta muy útil, por ejemplo, el enfoque que aporta SCRUM. Pero esto podrá ser materia para otra entrada, dado lo interesante del estudio del software desde esta perspectiva.