10 Consejos para la resolución de problemas técnicos inexplicables

En ocasiones, compañeros de trabajo y otros conocidos acuden a mi con problemas técnicos difíciles (de programación, sistemas, etc.) incomprensibles y/o aparentemente inexplicables, tratando de que les eche una mano en la búsqueda de una solución. Supongo que me he ganado fama de "gurú técnico" a base de encontrar soluciones inesperadas a problemas extraños (qué engañados les tengo a todos :-)
Seguro que si trabajáis con temas técnicos, habéis escuchado multitud de veces frases como estas:

• No lo entiendo! Pero si ayer funcionaba y no he tocado nada!
• Lo he probado todo y no soy capaz de saber por qué falla!
• Esto es imposible! Pero si el programa nunca debería pasar por ahí!
• Si en mi máquina funciona y todo está igual en esta otra, ¿por qué ahí no funciona?

He hecho un ejercicio de reflexión para tratar de analizar las reglas que inconscientemente aplico a la hora de tratar de resolver algún problema, esas reglas que sólo se aprenden a lo largo de años enfrentándote a este tipo de situaciones. Quiero compartir con vosotros algunos consejos/conclusiones que he sacado de esta reflexión, espero que os sirvan:

Consejo 1: Simplifica el problema

Cuando te enfrentas a un problema complejo suele haber muchas variables que pueden influir en él. En ese caso, hay que tratar de reducir el problema a su mínima expresión, para poder tratarlo sin tantas variables que introducen ruido al asunto. Muchas veces, cuando estás tratando de reducir el problema a uno más simple, das con la solución.

• Ejemplo: Imagina que tienes una aplicación que estás programando, que consta de 1000 archivos y más de 100.000 líneas de código. Tienes un problema con un archivo de la aplicación, concretamente en un método de una clase que no se comporta como debería. En ese caso, lo ideal es aislar ese método y tratar de probarlo independientemente del resto de la aplicación. Si es posible, además, quitar todas las líneas del método que no sean relevantes para el problema, hasta dejarlo reducido a su mínima expresión. Como digo, muchas veces aplicando este procedimiento de simplificación te das cuenta de la causa del problema.

Consejo 2: Se metódico en las pruebas
Lo primero que hay que hacer a la hora de enfrentarse un problema, aún a riesgo de parecer un autómata, es SER MUY METÓDICO. El más claro ejemplo de esto es que si para comprobar que algo funciona estás realizando las pruebas de una determinada manera, las realices siempre de la misma forma y en el mismo orden (aunque creas que lo que estás cambiando no puede afectar al resultado!!!).

• Ejemplo: Si estás realizando las pruebas en una máquina, hazlas siempre en la misma (aunque haya otra exáctamente igual). El cambio de máquina muchas veces introduce ruido en las pruebas (siempre suele haber problemas con idiomas distintos, encodings - UTF8, etc.).
• Ejemplo: Si para las pruebas estás lanzando dos scripts en un derminado orden, aunque los scripts sean independientes (teóricamente el orden no sea relevante), lánzalos siempre en el mismo orden.

Consejo 3: No mates moscas a cañonazos, primero Reflexiona!
Muchas veces cuando uno está enfrentándose a un problema incomprensible, tiene la tentación de "empezar de cero". Yo soy de la opinión de que esta tiene que ser la última solución, antes hay que tratar de descartar todas las otras vías. Volviendo a empezar de cero, corres el riesgo de tardar más de lo necesario, o lo que es peor, trabajar durante días rehaciendo algo para luego encontrarte con el mismo problema.

• Ejemplo: En nuestro día a día trabajamos a diario con las herramientas Maven, JDK1.6, Eclipse, etc. Tengo un compañero (con cariño eh!) que cada vez que no le funciona algo se lanza a reinstalar Windows, y todas las herramientas necesarias. Suele tardar un par de días en reinstalar todo, y algunas veces, cuando ha terminado, vuelve a probar lo que fallaba y... sigue fallando!. Muchas veces, si se hubiese parado a reflexionar sobre el problema en lugar de "tirar por la tangente", habría ahorrado mucho tiempo y esfuerzo.

Consejo 4: La máquina tiene la presunción de inocencia

Lo que he aprendido a lo largo de muchos años es que lo más probable frente a un error es que el culpable sea el ser humano, no la máquina. Lamentablemente en estos casos la presunción de inocencia es para la máquina, y no para ti :-(

• Ejemplo: Mucha gente, cuando algo no funciona, culpa a problemas en el hardware (las típicas frases "Eso es que la memoria está corrupta" o "A lo mejor el disco duro tiene clusters defectuosos"). La mayoría de las veces suele ser problema del programa, no del hardware.
• Ejemplo: Siempre me acuerdo de un antiguo compañero de trabajo que a menudo, cuando encontraba algún problema en Java aparentemente inexplicable, culpaba a la Java Virtual Machine. "Tiene que ser un error de la JVM!!" - decía. Siempre se confirmó que eran errores suyos en el código.

Consejo 5: A veces es más fácil hallar la solución que la causa

En ocasiones la gente se ofusca tratando de buscar la causa a un problema. Pasan días tratando de encontrar el por qué... cuando a veces existe un "atajo" (los ingleses lo llaman workaround) que te hace solucionar el problema, aunque no encuentres qué era lo que lo producía. Hay ocasiones en las que hay que saber rendirse ante el enemigo, y siendo prácticos, dejar atrás nuestra necesidad innata de conocer el por qué de las cosas. Ojo porque tampoco hay que abusar de esto, puede convertirse en un arma de doble filo (cada uno tiene que saber poner límites prácticos a su curiosidad, sobre todo si te pagan por producir ;-)

• Ejemplo: Un conocido tenía un problema con un programa en Java que se suponía que era compatible con la JDK1.3 y superiores. El tipo llevaba semanas persiguiendo el problema ejecutando el software con la JDK1.4, y no era capaz de encontrar la causa. Después de varios intentos fallidos de conocer la causa, le pregunté si había probado a ejecutarlo con la JDK1.3. Su respuesta fue que la 1.4 era compatible con versiones anteriores, por tanto si funcionaba con la 1.3 debería de hacerlo con la 1.4. "Muy bien" - le dije - "¿pero lo has probado?". Insistí en ello, y al probarlo con la 1.3 el error dejó de producirse. Nos quedamos con ganas de saber qué es lo que producía el error... pero solucionamos el problema!
• Ejemplo: La semana pasada un tipo me llamó porque estaba detectando errores de intentos fallidos en la conexión a SQL Server en un servidor. Después de darle muchas vueltas, probé a detener el servicio "Microsoft Reporting Services", y el error dejó de producirse. El tipo dijo: "¿Pero por qué ese servicio trata de conectarse a SQL Server? No lo entiendo", a lo cuál le respondí con otra pregunta: "¿Usas el servicio de Reporting Services o lo vas a usar en un futuro?". "No" - respondió. "Entonces me da igual saber por qué trata de conectarse, dejamos el servicio apagado y problema solucionado".

Consejo 6: Si ayer funcionaba y hoy no, algo ha cambiado

Cuando alguien viene a mi con la típica frase "Pero si ayer funcionaba y no ha cambiado nada!" siempre le respondo lo mismo: "Como mínimo ha cambiado algo: La fecha". Si estás en la típica situación en la que te fuiste el día anterior dejando algo funcionando y hoy ya no funciona, intenta pensar verdaderamente qué puede haber cambiado, y echa para atrás todo lo que haya cambiado para volver a la situación en la que funcionaba. Después vuelve a hacer los cambios probando uno a uno, para ver cuál es el que introduce el problema.

• Ejemplo: El día 19 de Septiembre estuve mejorando el Crawler para el BOCM del proyecto www.booletin.es. Para identificar hasta dónde llega la fecha de un boletín en una cadena de texto (Por ej: "19 de Septiembre de 2010. Bla bla bla"), estaba buscando "20" en la cadena de texto, y así identificaba dónde se encontraba el año en la fecha, y sabía por dónde cortar. Todo funcionaba bien con los boletines desde el 1 de Septiembre hasta el 19. Sin embargo, al día siguiente (20 de Septiembre) volví a probar el programa y fallaba. "Pero si no he cambiado nada!"- pensé. Sin embargo sí que había cambiado algo, el día del mes. El algoritmo funcionaba con todos los días del mes menos el día 20, ya que cortaba la cadena "20 de Septiembre de 2010. Bla bla bla" justo después del primer "20", y no después del año como pretendía.

Consejo 7: Pregúntale (bien) a Google

No creo que exagere si afirmo que el 90% de los problemas extraños se resuelven sabiendo buscar correctamente en Google. Cuando nos enfrentamos a un problema, lo más probable es que ya le haya pasado antes a alguien. Internet está lleno de foros en los que la gente plantea sus dudas/problemas, y en los que hay multitud de respuestas a ellos.Cuando me enfrento con un problema y ando perdido, acudo a Google y le pregunto. Es muy importante saber buscar bien, para encontrar lo que buscas. Para buscar algo, trato de buscar palabras distintivas de lo que ando buscando (es decir, palabras que debería de contener el documento que estoy buscando, y no deberían de contenerlas otros documentos que no busco).

• Ejemplo: La semana pasada un compañero de trabajo experto en tecnología J2EE (un arquitecto de los buenos) estaba buscando la solución a un problema con la herramienta Maven. Llevaba más de dos horas buscando en google y no encontraba nada. Me pidió que le echase una mano, y en cinco minutos (buscando los términos correctos en google) dimos con la solución.

A veces pienso que deberían darse cursos sobre cómo utilizar correctamente los buscadores, sería el tiempo mejor invertido por muchos (como dicen los economistas, tendría un ROI muy atractivo, se recuperaría la inversión en cuestión de días y el resto de la vida sería todo ganancias :-).

Consejo 8: Si no hay más remedio, baja de nivel de abstracción

Cuando todo lo demás falla y el problema parece inexplicable, debemos plantearnos que a lo mejor estamos buscando en el lugar inadecuado. Siempre que hablamos de tecnología, nos movemos en un determinado nivel de abstracción (Ej: Hardware < BIOS < Sistema Operativo < JVM < Programa Java) . En ocasiones el problema que estamos buscando no está en el nivel de abstracción en el que nos movemos, sino en un nivel inferior (por ej. a veces buscamos un error en el programa... y el error está en el Sistema Operativo). Tenemos que bajar a buscarlo ahí.

• Ejemplo: Esta semana he tenido un problema en un servidor: Al ejecutar un programa en este servidor se quedaba colgado. Sin embargo al ejecutarlo en mi máquina local (con la misma configuración) el programa funcionaba sin problemas. Finalmente, el problema no estaba en el programa, ni siquiera en el Sistema Operativo... pero tampoco en el Hardware!. El problema estaba en un nivel de abstracción que se encontraba escondido entre el Sistema Operativo y el Hardware. Resulta que se trataba de un servidor virtual, que se estaba ejecutando como una máquina virtual de VMWare. VMWare estaba teniendo problemas con el acceso a la cabina de discos, y esto estaba causando el fallo en la ejecución.

Consejo 9: Muchos ojos ven más que dos

Cuando estés atascado, pregunta!. Aunque pienses que las personas a las que puedes consultar no tengan la respuesta a tu problema, quizás te puedan aportar alguna pista (o a lo mejor tienen la respuesta y tú no lo sabes). Como poco, el contárselo a alguien te servirá también para aclarar tus propias ideas.

• Ejemplo: Esta anécdota es de mis favoritas. Hace muchos años hice una aplicación en Java que tenía que realizar un cálculo para cada hora de cada día del año. El programa empezaba con las 00:00h del 1 de Enero, e iba incrementando hora a hora hasta que acababa a las 23:00h del 31 de Diciembre. Al ejecutar el programa e ir incrementando hora a hora, llegaba un momento en el que se realizaba el cálculo dos veces para la misma hora. Yo no entendía qué podía estar pasando, ya que el programa funcionaba bien, pero en un momento concreto del tiempo (el 29 de Octubre de 2000) se duplicaba la hora. Después de dos días persiguiendo el fallo, me levanté muy enfadado de la silla y grité en alto "¿Pero qué demonios pasa el 29 de Octubre?". Para mi sorpresa, un compañero me miró y me dijo muy tranquilo: "ese día es el cambio de hora". Claro! No había caído en la cuenta de que el 29 de Octubre de ese año era el día en que se retrasaba la hora, por lo que a las 3h de la madrugada volvían a ser las 2h... y de ahí el hecho de que se duplicase. Mi compañero había dado en dos segundos con la solución al problema que yo llevaba buscando días.

Consejo 10: A veces la mejor solución a un problema es irse a dormir

Muchas veces nos obcecamos en resolver un problema, alargando la jornada hasta las tantas de la madrugada buscando la solución. Después de muchos años he aprendido que a veces la mejor solución es descansar. Cuando te levantas por la mañana, tienes la mente fresca y lúcida, y en ocasiones se te ocurren vías de solución que por la noche no habías imaginado. En otras ocasiones, mientras duermes, el cerebro sigue dándole vueltas al asunto y se aclaran las ideas: ¿a quién no le ha pasado el irse a dormir con un problema en la cabeza y levantarse con la solución?:

• Ejemplo: De pequeño solía jugar mucho al ajedrez. Con 13 años acostumbraba a resolver problemas de ajedrez complejos, buscando soluciones imaginativas a los problemas que se planteaban en libros y revistas. En una ocasión estuve varias horas pensando sobre un problema de "mate en 4" sin encontrar solución. Mi sorpresa fue cuándo me fui a acostar, y por la mañana me desperté habiendo encontrado la solución al problema (la cabeza había estado trabajando solita por la noche!).