No respondas a la primera pregunta
(lalitm.com)- En las herramientas de depuración de rendimiento, cuando llega una solicitud extraña conviene preguntar primero por el contexto en vez de responder de inmediato; así salen a la luz tanto el problema real del usuario como los vacíos de la herramienta.
- Esto va un paso más allá de simplemente manejar un problema XY: toma como punto de partida la confusión misma que llevó a una mala pregunta, y mejora la comprensión tanto del usuario como del producto.
- En Perfetto, usar traces para calcular todas las métricas puede ser posible, pero es ineficiente; un sistema dedicado de recolección de métricas puede ser más adecuado.
- Cuando la respuesta aparente y la necesidad real no coinciden, como en solicitudes para dividir traces, una función existente como periodic trace snapshots puede ser un mejor camino.
- Conviene decidir cambios de producto solo después de que una necesidad repetida se haga suficientemente evidente; agregar funciones apresuradamente puede terminar en una gran deuda técnica.
Por qué no responder de inmediato a la primera pregunta
- En una herramienta de depuración de rendimiento como Perfetto, si un usuario hace una pregunta que suena extraña, como “¿cómo divido un trace de Perfetto en varios archivos?”, antes de mostrar el procedimiento conviene preguntar primero “¿por qué terminaste recolectando un trace tan grande?”.
- Este enfoque va un paso más allá de resolver simplemente un problema XY.
- No se trata solo de reinterpretar la pregunta del usuario como su “intención real”, responder eso y dar el tema por cerrado, sino de tomar como punto de partida de la conversación la confusión misma que produjo la mala pregunta.
- El usuario obtiene un mejor modelo mental de la herramienta, y quienes la construyen pueden ver con más claridad en qué partes el producto genera confusión.
- A veces la conversación incluso lleva a la conclusión de que el producto en sí debería cambiar.
- Es una forma de trabajo especialmente aplicable para quienes crean herramientas para ingenieros.
- Puede trasladarse de manera menos directa a productos de consumo o servicios B2B, pero el enfoque de base sigue siendo útil.
Cómo diagnosticar una solicitud
- No todas las preguntas requieren una conversación profunda.
- Las preguntas simples y repetitivas que se resuelven apuntando a la documentación no son el foco aquí.
- Los casos interesantes son aquellos en los que la primera solicitud no trae suficiente contexto y la pregunta en sí se ve distinta a lo habitual.
- En una pregunta extraña, hay que buscar en qué punto se desvía según criterios como estos:
- Revisar si es una pregunta ya vista; si no lo es, tratarla como una solicitud poco común y bajar la velocidad.
- Ver si parece razonable comparada con otras preguntas; si no, buscar si debajo hay una pregunta más general.
- Confirmar si la solicitud encaja con la estructura de la herramienta, o si el usuario está peleando con la arquitectura sin darse cuenta.
- Una vez detectado el desajuste, hay que hacer preguntas para que aparezca el contexto que falta.
- La respuesta inmediata podría ser X, pero como por la razón Y la solicitud se ve bastante extraña, conviene iniciar la conversación pidiendo que explique el problema más amplio.
- A partir de ahí, el ritmo depende de qué tan bien el usuario pueda transmitir lo que está pensando.
- La conversación normalmente termina en una de tres conclusiones:
- El usuario no está captando la filosofía de la herramienta.
- La ruta correcta existe dentro del producto, pero no se ve bien.
- El producto en sí necesita cambiar.
Cuando se pierde de vista la filosofía de la herramienta
- Muchas veces los usuarios llegan a una herramienta sin tener del todo claro qué quieren o qué problema intentan resolver.
- Eso no pretende criticar al usuario.
- Los equipos intentan resolver problemas con tiempo y recursos limitados, y cuando dejan de avanzar buscan una nueva herramienta de depuración.
- Incluso si la herramienta ofrece buena parte de la funcionalidad deseada, si no coincide con el modelo mental del usuario sobre “cómo debería funcionar”, eso termina convirtiéndose en una solicitud de función.
- Un ejemplo común en Perfetto es ver el trace como una solución universal para calcular cualquier métrica.
- Un trace de Perfetto registra con muchísimo detalle lo que hizo el dispositivo durante un intervalo de tiempo específico.
- Como desde un trace se pueden calcular métricas, los usuarios intentan también calcular desde ahí valores como el frame rate o el uso de memoria de la app.
- En principio, cualquier métrica puede calcularse a partir de un trace.
- Pero usar traces para calcular todas las métricas es ineficiente.
- Recolectar y procesar traces tiene un costo alto.
- Incluso si solo se necesita un número, termina recolectándose información de todo el sistema.
- Un sistema dedicado de recolección de métricas puede hacer lo mismo de manera mucho más eficiente.
- Las herramientas tienen una filosofía de diseño, y es fácil que los usuarios la pierdan de vista por concentrarse en el problema inmediato.
- No basta con enseñar a usar Perfetto; también importa enseñar cómo abordar la ingeniería de rendimiento en sí.
- Hay que mostrar cómo pensar y trabajar temas como tiempo de arranque, pérdida de frames, memoria y consumo de energía.
- También hay que ayudar a entender qué herramientas usar, tanto en situaciones normales como cuando aparece un problema.
Cuando la ruta correcta está escondida
- A veces el usuario sí entiende el problema, pero no sabe cómo combinar las herramientas existentes.
- La herramienta fue diseñada para ser deliberadamente poderosa, y no se puede asumir que otros equipos comprendan todo su alcance funcional.
- Cuando se identifica lo que realmente se quiere lograr, con frecuencia una función creada para otro propósito termina cubriendo la necesidad.
- La solicitud de dividir traces es un ejemplo representativo.
- El usuario dice que dentro de un trace largo hay un intervalo que le interesa y quiere recortarlo.
- La razón es facilitar el rendimiento y la visualización.
- Pero en ese caso podría ser más adecuado evitar desde el principio recolectar un trace tan largo.
- Perfetto ya tiene periodic trace snapshots.
- Es una función que guarda repetidamente registros cortos en lugar de un único registro largo.
- Elimina la necesidad misma de recolectar primero un trace largo y luego dividirlo.
- La respuesta que el usuario pidió y la respuesta que realmente necesita pueden ser distintas.
- Una reacción como “eso era exactamente lo que necesitaba” es señal de que no se respondió a la solicitud imaginada por el usuario, sino que se encontró la necesidad real.
Cuando el producto tiene que cambiar
- Algunas respuestas revelan necesidades nuevas que pueden llevar a cambios importantes en el producto.
- Estos casos son delicados.
- Aunque la solicitud sea nueva, quien la hace puede no ser capaz de expresar con claridad qué necesita realmente.
- El costo de tomar una mala decisión en software de base es alto.
- Por eso se prefiere no construir algo hasta que la falta de eso duela de verdad.
- Cuando varios equipos empiezan a expresar la misma necesidad, suele hacerse visible el núcleo que realmente vale la pena construir.
- Como es muy difícil encontrar ese núcleo a partir de una sola solicitud, esperar puede ser una estrategia muy poderosa.
- La personalización ad hoc de la UI en Perfetto es un ejemplo de una mala decisión.
- La gente quería hackear la UI para ajustarla a su flujo de trabajo y se quejaba constantemente de que eso fuera difícil.
- En cuanto se permitió, apareció una enorme deuda técnica.
- Cada nueva función tenía que interactuar con todas las funciones existentes, y toda la estructura rápidamente dejó de escalar.
- Tomó cerca de un año diseñar una plugin API adecuada para salir de ese problema.
- La necesidad real era “una forma de personalizar la UI según el equipo o el caso de uso, sin afectar a todos los usuarios”.
- Esa necesidad no se expresó con claridad desde el principio.
- La responsabilidad de detectarla a tiempo dentro del flujo de solicitudes recaía en quienes construían el producto.
- La función para poder hacer “merge” de traces de Perfetto es un ejemplo de un caso bien manejado.
- La gente la pidió repetidamente, pero no se construyó de inmediato.
- Se optó por mostrar soluciones alternativas y seguir observando.
- Se sabía que implementarla bien requería mucho trabajo y que era fácil hacerla mal.
- Después de entender suficientemente el espacio del problema, el año pasado se implementó de una manera mantenible.
Lección principal
- La primera pregunta muchas veces no es la pregunta real.
- Antes de responder, hay que preguntar por qué se está haciendo esa pregunta.
- En algunos casos, el usuario termina aprendiendo cómo debe usar la herramienta.
- En otros, sale a la luz que la ruta correcta dentro del producto estaba oculta.
- En otros más, se llega a la conclusión de que todavía no hay nada que valga la pena construir.
- Y a veces eso prepara el terreno para construir correctamente la próxima gran función de una sola vez, en lugar de tener que rehacerla.
- Es una técnica simple, pero fácil de saltarse.
- La presión por responder rápido siempre está presente.
- Dar respuestas rápidas casi siempre se siente productivo.
- Aun así, cuando se da un paso atrás, casi siempre ambas partes terminan ganando más de lo que tenían al inicio.
1 comentarios
Comentarios en Lobste.rs
El autor dice que esto va mucho más allá del problema XY, pero a mí más bien me parece un texto que explica en detalle cómo abordar el problema XY con observaciones interesantes
Si encuadras la pregunta como un problema XY, es muy probable que vuelvas a caer en las heurísticas contraproducentes que la gente usa al responder preguntas que parecen un problema XY.
He perdido la cuenta de cuántas veces, al pedir consejo, la gente a mi alrededor dio por hecho que yo estaba lidiando con un problema XY, y tuve que seguir aclarando lo que quería decir hasta llegar a alguien que realmente leyera lo que escribí. Siento que la forma en que la cultura de programación responde al problema XY está mal calibrada, y este texto se lee como una refutación de esa sobrecorrección.
Incluso si sientes que quien pregunta sabe mucho menos que tú, es importante bajar la velocidad y no hacer pattern matching. Para empezar, la posibilidad de que realmente sea un problema XY no es abrumadoramente alta, e incluso si lo fuera, puede ser mejor tratarlo como si no lo fuera
Fue un buen texto. Me hizo pensar en la otra cara de la misma moneda: hay que cuidarse de reformular lo que te preguntan en una pregunta más simple y responder esa en su lugar.
Por ejemplo, si alguien pregunta “¿Qué distancia hay entre Ámsterdam y San Francisco?” y le respondes “En avión son 12 horas”.
La pregunta era sobre la distancia, pero como saber la distancia es más difícil y el tiempo de vuelo es algo que viene más fácilmente a la mente, quien responde termina contestando una pregunta más fácil en lugar de la original.
Esto pasa bastante seguido, y parece ser todavía más común cuando hay distancia de poder entre quien pregunta y quien responde
Por varias razones, durante una modernización del sistema agregamos una página 404 al router de ingress y eso causó problemas. Un desarrollador pidió que se restaurara el comportamiento anterior del 404, porque la página vieja tenía barra de navegación y menú.
Al indagar más, salió a la luz que en algunas configuraciones de clientes siempre aparecía un 404 al iniciar sesión, y que los clientes realmente usaban la vieja página 404 para llegar a donde sí necesitaban ir.
Para momentos como este se inventó lolcry 🤣😭
@lalitm, este problema es más viejo que internet y ya tiene nombre: análisis de requisitos.
Ed Yourdon y otros distinguían entre el proceso, que es el resultado que el usuario quiere obtener, y el procedimiento, que es cómo se logra ese resultado. Por ejemplo, avisar a un cliente que su pedido fue enviado es el proceso; mandar esa información por email es el procedimiento.
Los usuarios de un sistema tienden a pensar en la solución como si fuera una función del sistema. Los programadores no son la excepción, y por eso hay tantas variantes de “resolver Y en X”. El trabajo del analista es extraer los requisitos desde una forma concreta de implementación, y luego, como ingenieros, implementar la solución a partir de ahí.
Hace poco participé en una discusión sobre hacer el logging más rápido porque syslog(3) se atrasaba y a veces los eventos desaparecían del log. Pero el problema real no era tener logging más rápido. Los usuarios no quieren logging más rápido; quieren resolver el problema. Proveer la información necesaria es el proceso, y escribir todo en el log es solo una de las maneras de hacerlo.
Yourdon fue uno de quienes defendieron las herramientas CASE. Tal vez habría funcionado si la gerencia hubiera podido medir calidad y productividad, pero esa es una queja para otro día
Se dice que “la misma confusión que produce una pregunta equivocada es una oportunidad”, pero salvo que seas la máxima autoridad en ese dominio, es bastante difícil decidir desde el principio que una pregunta está equivocada
En realidad sí hay que responderla.
A menos que estés haciendo de guardián de valiosos recursos mentales, conviene ir con una táctica tipo improvisación: “sí, y además...”. Claro, también puedes añadir que podría haber otras maneras de llegar al resultado deseado.
En vez de usar una sola estrategia para destrabar la situación, es mejor usar todas las estrategias posibles