martes, 19 de octubre de 2010

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

66 comentarios:

israel olalla dijo...

Soy uno de tus seguidores en tu blog y esta última entrada me ha encantado, enhorabuena, porque das en el clavo en muchas cosas, seguro que soy uno de los que te han planteado dudas de las que comentas, asi que me he sentido identificado.
Yo creo que da como para hacer frases para el Tuitter, no? en plan los consejos del Pere.
Una duda ¿como ves el Testeo unitario?, especialmente para el primer punto. ¿Te gusta algún framework en especial?

Manuel Pereira dijo...

Hola Israel, me alegro de que te haya gustado! Según iba escribiendo los 10 consejos se me iba ocurriendo alguno más, pero el post ya empezaba a parecer un libro jejeje.
Para mi el testeo unitario es fundamental en un desarrollo. El primer consejo está muy dirigido a eso como bien comentas. Soy partidario del desarrollo dirigido por las pruebas (y del Xtreme Programming que casi casi aprendimos juntos ;-). Concretamente para Java uso el framework de toda la vida, JUnit (está muy integrado con todos los IDEs).
En la Comunidad de Madrid utilizamos JUnit y su integración con el IDE Eclipse.
También hacemos uso de las extensiones de Spring para pruebas unitarias, y de los plugins de Maven específicos para integrar las pruebas en el ciclo de compilación y despliegue.
Respecto a las pruebas de integración, utilizamos Selenium y también el plugin que lo integra con Maven.
Hablando de Maven, si no lo conoces te lo recomiendo, es una herramienta genial que facilita muchísimo la gestión de dependencias y la automatización de todos los ciclos de vida del software.
Un saludo!

aanton dijo...

Me uno a la felicitación de Isra!
Simplificar (aislar), "ayer funcionaba", googlear bien (últimamente acabo a menudo en stackoverflow), contar el problema (explicar con calma y en detalle un problema puede ayudarte a resolverlo y sólo necesitabas alguien que escuchara), ... cuanta razón tienes!

Y encima contado con casos reales! Chapó!

Anónimo dijo...

Muchas gracias, esos consejos siempre los aplicamos en mi equipo, sobre todo el de "irse a dormir."
DDF - Scrum Master

Anónimo dijo...

Está bien esta entrada del blog... :)

Y no solo diría que "a veces es mejor irse a dormir", sino que "a veces debe uno irse a dormir". La experiencia me dice que a partir de cierto número de horas delante del teclado, de cada 4 líneas de código que se añaden 3 están mal y la cuarta ni siquiera va donde la has puesto. El sueño hace milagros a veces...

XMen dijo...

Hola Manuel,
te explico dos anécdotas para ejemplificar el décimo punto que me parecen interesantes.
El primero es la última línea del manual de programación del motorola 68000 (soy muy viejuno). Más o menos viene a decir esto "si llevas muchas horas programando y ves que no funciona, levántate, da un paso hacia atrás. Si aún no lo ves claro, date la vuelta y baja al bar a tomar una cerveza. Mañana será otro día.
La segunda es mucho más peculiar. Cuentan que Robert Oppenheimer en pleno proyecto Manhattan, cuando tenían todo preparado para realizar la primera prueba de laboratorio de la existencia de la energía nuclear, y tras varios meses de trabajo muy duro, no puso en marcha el experimento e hizo que todo el mundo se fuera a comer. Así consiguió distendir el ambiente y todo el mundo volvió suficientemente relajado como para que no hubiera fallos por un exceso de tensión.
No conocía tu blog, pero volveré por aquí.
Un saludo

Pedro Bonilla dijo...

Muy bueno el post.

Sobretodo para enviárselo a aquellos compañeros que les gusta decir "Está malo!" o "No funciona!", pero que no son capaces de hacer un mínimo de pruebas para tratar de detectar el problema.

Gracias por estos tips. Son muy útiles.

Anónimo dijo...

Hola muy buena la entrada, me vi completamente identificado

quisiera agregar que la tecnica del "divide y venceras" funciona a muchos niveles


saludos

Edgardo

Manuel Pereira dijo...

Hola XMen, muy buenas las anécdotas, a veces viene bien mandar a todo el mundo a relajarse antes de seguir... en la primera empresa en la que trabajé teníamos un futbolín y creo que en gran parte fue el responsable de que el código contuviese menos bugs (eso y que se impidiese a cierta gente que salía de juerga los jueves tocar el código los viernes ;-).
Pedro, me alegro de que te haya gustado, yo tenía un compañero que cuando subía código al repositorio y esto hacía que a nadie le funcionase tenía una frase mítica: "A mí me compila eh!".
Anónimo, la regla del "divide y vencerás" es de gran ayuda, en realidad podría identificarse un poco con el Consejo 1 (simplificar).

Anónimo dijo...

GENIAL gracias por los consejos me ayudan mucho a mi y ami equipo.
José Luis Terrés Roig

Anónimo dijo...

Siempre me dijeron que lección dormida, era lección aprendida.

Muy bueno.

Saludos

Anónimo dijo...

La de muchos ojos ven mas que dos que verdad es, la de veces de estar revisando un codigo o un fichero de configuracion, y al de tiempo decirle a un colega, oye mira esto que no se que esta mal y en segundos decirte, "has puesto dos puntos en vez de un punto y coma aqui".

Y otro consejo que no has puesto pero que a mi me ha resultado muchas veces util, es aprender a manejar las herramientas de traceo o debug de que dispones, aunque muchas veces sale demasiada informacion siempre se suele encontrar alguna pista.

jlprat dijo...

La que más veces he aplicado de todas ellas es la de: Si no lo solucionas, mañana será otro día, a menudo la solución aparecía al llegar a casa, antes de cenar...

Bonito post, por cierto.

Anónimo dijo...

Me gustaría añadir que si aparece la variable "usuario" hay que usar el método House y suponer que es mentira todo lo que dice.
Ejemplo: Llamada de un usuario de una aplicación diciendo "Aquí no funciona nada a nadie y no hemos tocado nada." El 99.9999999% de las veces significa "A mi no me funciona nada y el cable de red esta desconectado o he instalado un programa o he borrado unas carpetas que no sabia que eran."

Anónimo dijo...

Muy bueno, totalmente de acuerdo excepto con la 5, aunque es cierto y aveces lo único práctico, no es lo mejor, y en muchas ocasiones es el origen de nuevos y peores problemas. Es importante encontrar el origen del problema, que siempre existe, no para solucionarlo, eso es verdad, si no para aprender, garantizar la confianza y estabilidad futura del sistema. Saludos.

John Ortiz dijo...

Gracias Manuel por esta información. Es la primera vez que leo este blog y sinceramente el artículo deja mucho bueno qué pensar. Nosotros, los informáticos somos individuos, por lo general, bastante pacientes frente a los problemas, casos, &c, que se presentan en el día a día, y estas sugerencias/consejos no están demás a la hora de resolver problemas (que es nuestra profesión, por así decirlo).

Hasta pronto!

Alexander Moreno Delgado dijo...

Excelente información muy concisa y directa.

Ialza dijo...

Que bien está el post Manuel, gracias por la recopilación, el hombre es el único animal que cae, no dos, sino varias veces... Pues me uno al carro de simplificar, me guardo la entrada para eventos futuros y me quedo con el anónimo de "House", que razón tiene ;-)

Sl2 a todos

Samuel Zarza dijo...

Hola:
Me ha gustado mucho tu entrada y, desde luego, hay que leerla dos veces para darse cuenta que, en efecto, damos con las soluciones a través de algunos de esos consejos que enumeras. Recuerdo que yo redacté una similar, pero más específica para JEE (http://balteus.blogspot.com/2009/07/banco-de-experiencias-iii-errores.html). La tuya es genérica, tecno-agnóstica y atemporal. Enhorabuena.

Anónimo dijo...

Suscribo todo lo que dices, pero yo daría otro consejo más: De mano nunca hagas caso de la gente que diagnostica el error con un "... eso va a ser un virus" (Desconfía mucho de quién te diga esto. No tiene ni idea de lo que pasa)

Creo que la probabilida de acertar con lo del virus es más o menos la misma que con la ya mencionada "... eso va a ser algún problema del hardware"

Anónimo dijo...

Muy bueno, buenisimo... Me he visto en casi todas...

Anónimo dijo...

Por lo que has puesto deduzco que tocas parte de sistemas y parte de desarrollo. Por que si te dedicas solo a una de las partes el problema siempre es de la otra :).
Algun dia sistemas y desarrollo trabajaran juntos para encontrar un problema, en vez de tratar de dejar la pelota en el tejado del otro.

Anónimo dijo...

Espero que esta entrada la lea mucha gente, muchísima, porque mi campo es la administración de sistemas, y estoy hasta $½@#!?/&# de que me vengan los equipos de desarrollo, a echarme la bronca porque su aplicación funciona en su entorno local y en el servidor no... y al final siempre estamos en la misma:

- ah que la ruta en el servidor no existe...
- Ah que las variables de entorno de mi usuario no son las adecuadas!
- ah que no dijimos que se necesitaba tener instalado la JDK 1.6
- ponga aquí su excusa favorita...

Anónimo dijo...

Mal de muchos, consuelo de tontos,ésto último para mí que tengo mucho que aprender-Muchas gracias

Aelfwald dijo...

A mi me gustaría comentar otra posible manera de solucionar los problemas, aunque sé que puede parecer absurda.

A veces, tomarse una cerveza o dos antes de volverse a enfrentar al problema hace que estemos más desinhibidos y que por lo tanto aceptemos propuestas que descartaríamos en condiciones normales. Muchas veces estas ideas "absurdas" tienen mucho más sentido del que parece y funcionan. Conste que lo digo con toda la seriedad!

Además, es una muy buena excusa para tomarse el problema de buen humor. Evidentmente, tampoco se puede abusar de esta solución!

Anónimo dijo...

Solo un detalle sobre la anécdota del '29 de Octubre': El día del cambio de hora depende de la zona del mundo, así que ojo con esto ;)

Manuel Pereira dijo...

Vaya, Parece que está gustando el post! Gracias a los que habéis comentado, tanto aquí como en barrapunto o meneame.
El consejo que más debate está generando es el 5, cosa que ya intuía cuando lo escribí porque es el más "anti-técnico" y "anti-método-cientifico", va un poco contra el innato instinto curioso que todos tenemos (y más si cabe los técnicos).
Por supuesto soy partidario de dar con la causa de los problemas, con eso se aprende mucho y se evita que se produzcan en el futuro. Sin embargo, como comento en el consejo, creo que hay ocasiones en las que cuando no damos con la causa tenemos que buscar una solución (lamentablemente, y a pesar de ir contra nuestro instinto curioso) y dejar el problema en la lista de "Expedientes X".
Que conste que yo soy el primero que no me quedo tranquilo... pero en ocasiones toca.

Anónimo dijo...

El ejemplo del dia 20 es un error sin nombre. ¿Que tal el hechode utilizar qela cadena tiene unpatron muy marcado por los separadores ( espacios en blanco y preposición 'de').

Anónimo dijo...

Completamente de acuerdo con el punto 7. Las academias deberian incluir cursos de Google. Los ejemplos que pones se centran en la resolución de problemas técnicos pero son aplicables a problemas de cualquier ámbito. Especialmente útil el "divide y venceras".

Anónimo dijo...

Yo añadiria un punto más: "Lee el error". Muchas veces el mensaje de error nos da la suficiente información para localizar la fuente del problema. Trabajo en soporte informático y tambien doy clases de programación, así que me identifico plenamente en el post, y creo que más de la mitad de las veces resuelvo los problemas que otros no resuelven porque leo el mensaje de error :-)

Manuel Pereira dijo...

La verdad es que lo del 20 fue un error de principiante. Normalmente utilizo Expresiones Regulares para esto, pero el proyecto booletín se realizó durante un concurso de un sólo fin de semana, por lo que íbamos contra reloj y tiré por la vía del medio (la incorrecta jejeje).

Javier dijo...

La 9 me ha encantado mas que nada por que se resume en una frase de la que yo hago apología siempre que puedo:

"A veces hace falta alguien de fuera para que se de cuenta de lo evidente"

Y es increible la de veces que se cumple con cosas como "ese cuadro está torcido" lleva meses (años) evidentemente inclinado pero nunca te percataste hasta que viene alguien de fuera a darse cuenta de lo obvio

Gabriel Smetana dijo...

Hola Pere,

Está genial tu post, me encanta el caso 9, y encima te han publicado en barrapunto que grande, enhorabuena :-)

Por cierto, no sabía que tenía un blog, ale, para mi rss jeje

Ciao

Beñat Bustamante dijo...

Muy buenos consejos. La verdad es que me ha sorprendido darme cuenta que yo mismo sigo todos esos pasos instintivamente. Sobre todo lo del descanso, cuando no puedo irme a dormir (por que estoy en el curro y quedaría feo) salgo al baño, me doy una vuelta al piso o, incluso, me voy al bar de alado a tomarme algo (no alcohólico, claro).

José Miguel Prefasi dijo...

Gracias a Microsiervos he llegado a esta entrada, que me parece magnífica.

Ya tengo una edad y he pasado por "casi" todo en esto de la informática.

Y me gustan especialmente los puntos 9 y 10.

Un saludo.

Anónimo dijo...

Muy buen análisis. La única pega la tengo con el consejo 5 (a veces es más fácil hallar la solución que la causa). Dices que no hay que abusar, pero luego en los ejemplos da la sensación de que se toma esta vía un poco a la ligera.
En mi opinión, dejar la "solución" encontrada, sin haber hallado o entendido la causa, debería ser el último (ultimísimo, más bien) recurso. Si no sabemos por qué ha fallado, no podemos estar seguro de que la "solución" que hemos encontrado sea buena, o de que no se reproduzca el problema en el futuro.

Anónimo dijo...

Buenos consejos pero demasiado evidentes, creo que si sabes programar sabes eso como mínimo.

Anónimo dijo...

Genial. La verdad más verdadera es el 7. La raza de gurus se extinguió hace tiempo. Google lo sabe todo. Tu problema le ha pasado a antes alguien. Seguro. Si no lo encuentras, es porque buscas mal.

Anónimo dijo...

Sensacional.
Es la primera vez que leo algo tuyo.
Mi enhorabuena

Anónimo dijo...

Muy bueno...gracias :)
Un buen amigo mio de profesión me contó otro truco que me hizo mucha gracia...Se basa en el hecho de que muchas veces explicando el problema a un compañero, profesor, etc. en definitiva, verbalizando y exponiendo toda la secuencia de hechos de forma ordenada...nos damos cuenta de la solución!
Pues bien, el truco es tan sencillo como...cómprate un patito de goma y ponlo en es escritorio, junto a la pantalla. Cuando estes ante un problema de estos inexplicables...cuentáselo todo a él. De esta forma encontrarás la solución :)

D.CIALDELLA dijo...

Muy bueno !!! ya está impreso en la pared del curro. Es muy bueno y sencillo. Hasta los directores lo pueden entender...

Jose A H S dijo...

Al punto 10 yo lo llamo la "Ley de la Serpiente de Kekulé", que es un nombre muy majo y bastante ilustrativo.
Para quien no sepan de que trata la cosa, léanse esto:

http://elcronosferio.blogspot.com/2008/06/los-hidrocarburos-nos-resultan.html

:)

ollupacre dijo...

El ultimo consejo es el que mas veces me funciona. Cuando has tocado y retocado toda la configuracion, cuando ya crees haberlo hecho todo, dejalo vete a cenar o si es la hora, vete a dormir. La mayor (no exagero) parte de las veces he dado con la solucion al retomar el problema al dia siguiente, con la mente fresca y vacia de todo lo hecho y pensado.

Francisco Redondo dijo...

Que razón la décima!! A mi me pasó una vez justo lo que cuentas. Acostarme a las tantas de la noche con un problema que no sabía resolver y nada mas abrir los ojos saber la solución, es increible!! :-) Un saludo y un fabuloso post!!

Anónimo dijo...

Un nuevo seguidor se apunta.

Excelentes consejos.

Desde mi perspectiva extendería un poco mas el punto de aislar los problemas, tal vez renombrándolo a un divide y vencerás.

Una de las cosas que he ido aprendiendo de la experiencia (y de desarrolladores con mas experiencia que un servidor) es que hay que tratar de acotar lo mas posible el problema.

Un anécdota:
Hace unos años debía de hacer un sistema de transacciones financieras, tras varios días de desvelo buscando la causa de que una transacción no funcionara, finalmente se metió el CEO para echarnos una mano.
Hicimos un checklist de las cosas a verificar. Después de hacer las pruebas propuestas, nos comenta, que hagamos una ejecucion lo mas controlada posible (y viendo logs) para identificar el problema.

Finalmente concluímos que el problema radicaba en una función
strcpy(), donde si la cadena a copiar estaba vacía en la libreria que estábamos usando, corrompía la memoria.
una validacion del tipo :
if (cStr != NULL)
Nos resolvió el problema.

Paucazorla dijo...

No soy técnico ni trabajo en nada relacionado con informática, pero debo darte mi enhorabuena por el post, magnífico de principio a fin, ejemplos incluidos. Es aplicable a otros muchos ámbitos de la vida :)

Mauro dijo...

Si existen cursos de uso de buscadores, aunque no son tan comunes.

Muy buenos los consejos ;) son cosas que se saben pero a lo mejor en el momento del problema te olvidas :P

dgillanas dijo...

Enorabuena por el post, es muy bueno y me he sentido muy identificado, sobre todo con el tema del 29 de Octubre con el cambio de hora, que también me pasó, y además no sólo con ese dia, si no con el año (2008) que por ser bisiesto me fastidiaba los cálculos en febrero, jejeje.

De hecho, tras haber estado varios días frustado, intentando resolver el problema, me levanté una noche a las tantas, gritando: ¡¡ joder, que este año... es bisiesto!!

Desde entonces he aprendido a usar muy bien la clase "Calendar" de java y ya no he vuelto a cometer ese tipo de errores...

Tinotin dijo...

Has comentado, que te gusta el ajedrez. Pues gracias a el. En concreto como se analiza en ajedrez. He resuelto tanto problemas tanto problemas de programacion como de sistemas.
Tanto en ajedrez, como en programacion y sistemas, utilizo la tecnica de desconexion temporal del problema, para retomarlo mas tarde. Bien sea para tomarse un cafe, un paseo y dormir (muy importante). Por arte de magia, vienen ideas nuevas que antes estabas ofuscado.
No falla.

Oropher dijo...

Muy buen post, definitivamente tu blog va a los favoritos =)

Taquion dijo...

Que buen post, he puesto une referencia en el mío, para que más gente se entere.

me he hecho uno de tus fans!

Compi de tu compi dijo...

¡Muy buena entrada!. Tras varios años trabajando con Oracle, mi experiencia confirma lo útil de muchos de tus consejos, especialmente el quinto (que yo llamo "no trates de aprender, si ya funciona ponte con otra cosa") y con el noveno (a veces solo con tratar de explicarle el problema a otra persona, aunque sea la señora de la limpieza, tú mismo te das cuenta de la solución, y si no, seguramente un compañero al que le pille nuevas se dará cuenta de lo que se te pasa por alto). Los consejos que no conocía seguro que me serán muy útiles. Gracias.

foxi dijo...

Felicidades por el Blog...

. Como apunte al Consejo 9: Pregunta a la gente que te pueda ayudar: Aunque hay algunas veces que tú mismo puedes llegar a una solución a un problema simplemente planteando la pregunta a otra persona; hay algunas otras veces, más habituales, en que si preguntas a una persona incorrecta te pueden llegar a 'marear' con posibilidades de soluciones aparentemente correctas.

· Como apunte al Consejo 10: Diría que no siempre es necesario irse a la cama... Hasta que por fin me decidí a dejar de fumar, ése fue un buen resurso para despejar la mente y solucionar problemas. (Desde entonces, tomo muchos cafés).

· Como consejo añadido para usuarios: Si tienes un manual, no molestéis al personal de soporte sin haberlo leído. Muchas veces sólo molestaréis.

Manuel Pereira dijo...

Parece que el Consejo 10 (vete a dormir / tomar café) es el favorito de muchos.
Jose A.H.S, me ha gustado la anécdota de la "Ley de la Serpiente de Kekulé", buen post.
Respecto a la anécdota del cambio de hora como bien comentas dgillanas fué usando la clase Calendar de Java, que hace el cambio de hora (y los bisiestos) ella solita...
Javier, muy buena la frase del resumen del Consejo 9: "A veces hace falta alguien de fuera para que se de cuenta de lo evidente"
Bienvenido Gabi, me alegro de leerte por aquí!.

Jose Antonio dijo...

"Pregúntale (bien) a Google"

Anecdota: Una vez estaba buscando información sobre un fallo muy extraño que tenía con una aplicación. Buscaba en Google, pero con las palabras que usaba no conseguia encontrar lo que buscaba. Hasta que de una vez, teniendo en cuenta que el error era francamente extraño, decidí añadir la palabra "weird" .. y allí apareción la respuesta a mi problema entre los primeros resultados de la búsqueda ;)

Lo de echar la culpa al compilador/runtime es típico cuando ya no sabe uno a qué se puede deber. Aunque he de reconocer que una vez en mi vida SÍ era culpa del compilador/interprete (VBA en Microstation), y A y NOT(A) evaluaban ambos a false (A era un booleano). Deduje que sería un problema de integración de alguna librería que usaba: que los booleanos de esa plataforma por debajo estuviesen implementados con integers, not hiciese un xor, y alguna libreria que no hubiese devolvido 0 o -1, sinó otro valor. Y lo solucioné aplicando precisamente el consejo 5: haciendo B = A (B booleano), y despues usando B en vez de A. Curiosamente,eso solucionaba el problema (supongo que el runtime en la asignacion, como efecto colateral, normalizaba el booleano).

Anónimo dijo...

Pues yo tampoco conocía el blog y me ha encantado la entrada. Volveré...
No sé que tiene el JDK 1.3, pero también tuve problemas con el mismo. Para acceder a la intranet de un cliente, los requisitos indicaban "JDK versión 1.3". Probé con la que tenía instalada durante una semana, hasta percatarme de que faltaba la coletilla " o superior".
Coincido también en el punto 5. Muchas veces el problema se debe a causas tan interconectadas que no merece la pena el esfuerzo de investigarlas, si ya se tiene una solución. Aunque más vale documentarlo correctamente, no sea que alguien herede el sistema y se pregunte porqué está deshabilitado este servicio o, peor, se hagan cambios que lo requieran.
Saludos

Anónimo dijo...

Seré comciso:

1.- n! = n * (n-1)!

2.- Extreme Testing.

3.- Principio de sencillez y simplicidad.

4.- Paja en ojo ajeno.

5.- Primero resuelve, y después, si quieres, investiga.

6.- Se evita con test unitarios automáticos y completos.

7.- De acuerdo. En Java/J2EE casi todo está ya hecho, sólo hay que saber buscar (Google Hacks?).

8.- Normalmente las cosas son lo que parecen. La Navaja de Okham.

9.- Elemental. Extreme Programming -> Pair Programming (si fue hace muchos años no fue en Java, o no fueron tantos...).

10.- Si al final del día no funciona, no integra, tíralo a la basura y hazlo mañana desde cero.

XMen.- Yo tenía (y aún concervo) un Dragon 32 con micro-procesador motorola 68000. ¿Soy viejuno?

Mi granito de arena.- NO dupliquense los entes sin necesidad (Santo Tomás de Aquino 1224-1274).

Buen post! Salu2. trkham1966.

Anónimo dijo...

Tengo Mac, todo esto me lo ahorro! Windows es la peor basura inventada, una tomadura de pelo autentica, y mira que dura

Guillermo dijo...

Gracias, gracias! Que interesante. Yo soy de los que matan moscas a cañonazos... Esto es un auténtico meme. Enhorabuena por tu blog

mallop dijo...

Hola Manuel,

Es la primera vez que te leo, he llegado a tu blog por una recomendación de un compañero al que sigo en el Reader.
Me ha encantado la entrada, aunque bastantes puntos ya los intento aplicar, tú los has plasmado todos muy bien y aún me han quedado más claro.

A partir de hoy tienes un seguidor más de tu blog.

Saludos

Miguel Ángel

Anónimo dijo...

Muy buena tu publicacion Manuel. Yo empece a trabajar en desarrollo web hace unos 3 meses, y realmente sirve mucho que alguien con experiencia comparta estos datos.
Saludos desde La Plata, Argentina.

Jorge dijo...

Menuda sorpresa me he llevado cuando ayer en el trabajo mi jefe nos envió ésta entrada como recomendación y al abrir la fuente para ver quién era el autor descubro que es mi profesor de prácticas de Programación Funcional del año pasado!

Que sepas que con la paciencia que tuviste explicándonos LISP, con éste artículo y con la conferencia que nos diste en 1º de carrera en la que nos explicaste los pilares del mundo en el que nos estábamos metiendo has conseguido que éste alumno te esté especialmente agradecido.

Un saludo!

Manuel Pereira dijo...

Hola Jorge!
Gracias por comentar, me alegro de que te hayan servido tanto el artículo como las clases y la conferencia (ya hace años eh!).
En la vida intento hacer lo que me gusta, y creo que divertirte con lo que haces es la clave para que salga bien (al menos algunas veces).
Espero que te vaya bien en la vida y en el trabajo, si necesitas cualquier cosa, tienes mi correo.
Un saludo!

Victoria Bucio dijo...

P A C I E N C I A

zz_miguel dijo...

Muy interesante, muchas gracias :-)

Yo he preparado una lista de 14 recomendaciones, las cuento en clase el primer día. Están basadas en las tuyas, espero que el crédito que te doy te parezca bien.

http://gsyc.es/~mortuno/lagsr/00-resolucion_problemas.pdf

Manuel Pereira dijo...

Genial Miguel, yo también suelo hacer una introducción distendida el primer día de clase, seguro que a tus alumnos les gusta.
Me ha gustado lo de "ñapa" (en castizo) ;-)
Un saludo.