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.

Llevas horas trabajando frente al ordenador y, de repente, la pantalla cambia de estado. Se fue la luz y se ha apagado, aparece la pantalla azul de la muerte o, simplemente, la imagen de fondo del escritorio porque la aplicación que estábamos usando se ha cerrado inesperadamente debido a algún problema. Bueno, problema ninguno, ¿verdad? Hemos ido salvando puntual y religiosamente nuestro trabajo cada 10 ó 15 minutos… Ah, ¿no? ¿En serio? ¡Pero cómo se te ocurre!

Esta situación se da más a menudo de lo que debería, y de lo que nos gustaría admitir. Precisamente un programador no debería encontrarse en la tesitura de haber perdido el trabajo de una hora, o dos, o ‘n’, por no guardar los cambios que estaba realizando en el código fuente. No debería pasar… pero pasa.

Si trabajáis con Visual Studio, sabréis que el IDE graba automáticamente los archivos que han sido modificados cada vez que realizamos una ejecución de la aplicación que estemos desarrollando. Esto es así para evitar posibles pérdidas de información si, por un casual, nuestra aplicación vuelve inestable al sistema o Visual Studio no es capaz de controlarla por algún motivo. Sin embargo, si el error se ha producido en otro momento (porque Visual Studio se cierre automáticamente, por ejemplo), podríamos encontrarnos ante un verdadero problema, ¿verdad? Bueno, que no “panda el cúnico”, como decía un conocido personaje televisivo de origen mexicano. Visual Studio realiza copias de seguridad de nuestro código cada cierto tiempo, siempre que tengamos establecida la opción correspondiente dentro del menú de “Herramientas, Opciones” (“Tools, Options”). En el grupo “Entorno” (“Environment”) encontraremos la opción “Autorrecuperación” (“AutoRecover”) que, de estar activada, irá guardando en los plazos que pueden establecerse ahí mismo las modificaciones que hagamos sobre nuestro proyecto.

¿Dónde se encuentran los archivos cambiados? Bien, estarán en la ruta:

My Documents\Visual Studio {versión}\Backup Files\{Nombre del proyecto}

Comenzando por el nombre “~AutoRecover”. De hecho, son los usados por Visual Studio cuando muestra las opciones de autorrecuperación tras un problema, pero si no fuera así ya sabemos dónde buscar las copias de seguridad.

Ah, y recordad: un Control+S (o Control+G, según el idioma) de cuando en cuando, no viene nada mal.

P.D.: Y no, no es algo que me haya ocurrido a mí, malpensados…