¡Saludos visitante! si deseas comentar o hacer una pregunta sobre este post por favor dirígete a la nueva dirección en http://variabletecnica.com.ve. La página que estás leyendo dejará de estar disponible el 15/11/2015. Gracias, y disculpa las molestias 🙂

Generalmente, cuando busco información sobre algún error o como implementar algo para mi trabajo, nuestro amigo Google me envía a alguna post en StackOverflow. Este funciona como un blog interactivo de preguntas y respuestas sobre programación.

Hoy, mientras leía una de las preguntas, noté que el autor no explicaba detalladamente el problema, sino que preguntaba cómo implementar cierta solución, mientras otros programadores le ofrecían respuestas que parecían no funcionar en su caso.

Paso mucho tiempo leyendo artículos en foros y blogs, y sé por experiencia que muchos programadores nóveles preguntan como hacer algo sin mencionar cuales el verdadero problema que quieren resolver. También ocurre al dar soporte técnico por teléfono o por correo, cuando quien pregunta no da toda la información relevante, o incluye información no relacionada al problema. Esto tiene un nombre: XY Problem (Problema XY).

El término se refiere a situaciones en las cuales: Alguien quiere hacer X, y supone que la mejor forma de hacerlo es Y, así que pregunta a sus compañeros o en algún foro como hacer Y, sin mencionar que lo que realmente quiere es resolver X.

¿Y que tiene eso de malo? en principio, quien pregunta probablemente cree que al hacer una pregunta más específica va a obtener una respuesta más directa; pero esto no siempre es cierto: al hacer esto podría perderse información relevante que pueda llevar a una mejor solución.

Creo que no es fácil darse cuenta que has caído en el Problema XY; lo mejor que puedes hacer es evitar caer en él:

• Asegúrate de entender el problema. No sirve de nada preguntar sobre una solución que no resuelva el verdadero problema.
• Al hacer preguntas incluye toda la información relevante. ¿Es una pregunta de programación? menciona el lenguaje, el IDE, el Framework… ¿Es un pregunta de software? indica el SO, mensajes de error, otro software que pueda interferir (firewall, antivirus…), pasos para reproducir el problema… ¿Es una pregunta de hardware? indica marca, modelo, controladores, comportamientos inusuales…
• Describe los síntomas del problema, no la causa.

Creo que debo extenderme un poco más en este último punto. Si sabes la causa del problema ¡perfecto! explica la causa junto con el problema cuando preguntes y obtendrás la respuesta que necesitas, pero debes estar seguro de todo lo que dices, y si es solo una suposición déjalo claro al preguntar. Dar información equivocada es peor que dar poca información.

Veamos un ejemplo: digamos que desarrollaste un programa que debe enviar un correo, y funciona en tu equipo de desarrollo pero no en el servidor, y preguntas lo siguiente en un foro:

Mala Pregunta: ¿Cómo puedo desactivar el firewall de un servidor desde PHP? es que me está bloqueando el envío de correo, y solo tengo acceso al servidor por ftp.

Buena Pregunta: Tengo un formulario de contacto programado en PHP, y puedo enviar correo con él desde el equipo de desarrollo, pero al probarlo desde el servidor me lanza la excepción «Uncaught exception 'Zend_Mail_Transport_Exception'«. Por el seguimiento de pila del error, que les anexo más abajo, creo que es el firewall del servidor, pero no puedo verificarlo (solo tengo acceso por ftp).

La primera pregunta solo sería correcta si tienes «la certeza» de que el problema es el firewall: ¿verificaste que efectivamente es el firewall? ¿el problema ocurre en otro servidor? ¿estás usando el puerto correcto?… Debes mantener tu objetivo claro: Tú no quieres desactivar el firewall, lo que realmente quieres es enviar correos desde el servidor.

La segunda pregunta contiene algo muy importante, especialmente si la pregunta es de programación: el mensaje de error (y mejor aun si incluye en seguimiento de la pila).

¿Y si ves a alguien caer en el problema XY? No es difícil ayudarlo a salir, siempre que esté dispuesto a dejarse ayudar; puedes intentar preguntando amablemente ¿porqué quiere haces eso? al mismo tiempo que tratas de responder lo que esa preguntando, con algo de suerte te dirá cual es el verdadero problema que quiere resolver y estarás en una mejor posición para ayudarlo.

Hace algún tiempo, un amigo en la universidad me preguntó cómo obtener una parte de una cadena (string) en Java, le mostré la sintaxis y luego me preguntó como saber en qué posición de la cadena estaba un carácter (buscaba los «<» y «>»), y también le mostré la sintaxis, pero esta vez le pregunté ¿Estás tratando de cortar una sub cadena entre dos caracteres?, fue una sorpresa descubrir que realmente lo que quería era analizar una cadena XML para obtener algunos valores. Al descubrir el X detrás de su Y pude sugerirle Z: le mostré las librería que puede usar para crear y analizar cadenas XML y extraer valores de ella fácilmente.

Referencias

• Esta es la pregunta donde leí por primera vez sobre El Problema XY (en inglés)
• Interesante artículo de Eric Steven Raymond y Rick Moen How to Ask Questions (en inglés)
• Y si acostumbras usar foros, será mejor que te familiarices con los acrónimos GYYF, STFW y RTFM.

Derecho de uso

Los contenidos generados por el autor de este artículo (explicaciones, código fuente, y archivos adjuntos creados por el autor) están disponibles bajo licencia CC BY-SA 3.0, y pueden ser usados, derivados y compartidos bajo los términos indicados en la misma. Los contenidos no generados por el autor de este artículo son propiedad de sus respectivos dueños y están regidos por las licencias que ellos hayan dispuesto.

Cita del día

A wise man can learn more from a foolish question than a fool can learn from a wise answer.
Bruce Lee

Sometimes the questions are complicated and the answers are simple..
Dr. Seuss