10 Consejos para la resolucion de problemas

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!).

      [[http://www.blogger.com/post-edit.g?blogID=305476992018108942&postID=7559781187194895076|\\

]]

Referencia

Tomado de http://manuelpereiragonzalez.blogspot.com/2010/10/10-consejos-para-la-resolucion-de.html –

Advertencia

Este documento es privado y es de u so exclusivo de sus autores y de SKINA TECH. Cualquier uso sin una autorización escrita es contra la ley de derechos de autor y de propiedad intelectual, y será motivo de una acción legal.