¿Qué es la depuración con el pato de goma?
Cultura de ingeniería y práctica de software
La depuración con el pato de goma es una forma de encontrar un error explicando el código o el problema, paso a paso, a un pato de goma, a otro objeto o a un borrador de mensaje. El pato no necesita saber nada. El valor reside en convertir una intuición vaga en lenguaje claro. Esa explicación lenta y literal suele exponer suposiciones que faltan, lógica confusa, casos límite olvidados o el punto exacto donde se detiene la comprensión.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
Un número sorprendente de errores sobrevive porque la idea que tiene el programador del código es más fluida que el código en sí. En la mente, todo tiene más o menos sentido. En el momento en que se intenta explicar cada línea en orden, aparecen las asperezas. Uno se da cuenta de que una variable no es lo que creía, de que una rama es imposible o de que un paso depende de algo que nunca existió.
El pato no es más que un accesorio. Puede ser un juguete, un cuaderno, una ventana de chat vacía, una pizarra o un colega muy paciente que casi no dice nada. Lo que importa no es el pato en sí. Lo que importa es obligar al pensamiento a convertirse en palabras que otra mente, aunque sea imaginaria, pueda seguir.
Por eso el término ha perdurado. Suena a broma, pero la práctica es profundamente útil. Es uno de esos fragmentos del folclore de la ingeniería que se mantienen porque siguen ganándose su lugar.
Por qué importa
La depuración con el pato de goma importa porque hace visible el pensamiento oculto antes de que el equipo pierda más tiempo. Un desarrollador que puede explicar el error con claridad tiene muchas más probabilidades de encontrarlo rápido, reproducirlo de forma fiable y pedir ayuda de una manera que los demás puedan aprovechar. Eso reduce las interrupciones, disminuye el intercambio de tickets vagos y mejora la calidad de la depuración en todo el equipo.
También importa más allá de los especialistas en software. Los responsables de producto, los equipos de soporte, los analistas y los líderes técnicos trabajan a menudo con problemas de ingeniería sin escribir código ellos mismos. El hábito del pato es, en realidad, un hábito de comunicación: decir qué debería ocurrir, qué ocurrió realmente, qué cambió y dónde termina la certeza. Eso convierte una queja difusa en algo verificable.
También hay un beneficio cultural. Los equipos que valoran la explicación clara tienden a depender menos de los héroes individuales y más de la comprensión compartida. El pato es un pequeño símbolo de una idea más grande: si no se puede explicar el trabajo con claridad, probablemente aún no se entiende lo suficiente.
Cómo funciona
El origen del término
La expresión fue popularizada por The Pragmatic Programmer, que describe a un programador que lleva consigo un pato de goma y le explica el código línea por línea. Desde entonces, la imagen del pato se ha extendido mucho más allá de esa anécdota original. Las universidades la enseñan, los ingenieros sénior la recomiendan y equipos enteros han inventado variantes locales con osos, plantas, mascotas y plantillas de incidencias vacías.
El objeto literal rara vez es la parte importante. El pato simplemente le da al cerebro una razón para ir más despacio y realizar la explicación como si hubiera un público presente.
Por qué suele funcionar
Los seres humanos son muy buenos saltándose los vacíos en su propio razonamiento. Reconocemos formas rápidamente y completamos los detalles que faltan sin darnos cuenta. Eso es útil en la vida cotidiana, pero desastroso para la depuración. Al código no le importa lo que se pretendía. Solo hace lo que está escrito.
La depuración con el pato de goma interrumpe ese atajo. Para explicar una función, hay que nombrar las entradas, el estado esperado, el estado real y el propósito de cada paso. En el instante en que no se puede hacer eso, se ha encontrado una fricción útil. Muchos errores viven exactamente en esa fricción: un error de uno en uno, una suposición obsoleta, una comprobación de nulo que falta, un desajuste de zona horaria, una rama "obvia" que no lo es en absoluto.
Por eso escribir una publicación de soporte o una solicitud de ayuda interna produce tan a menudo un momento de "ah, no importa, ya lo encontré". El acto de redactar el mensaje fue el que hizo el trabajo.
Cómo aparece en el trabajo real
En la práctica, el uso del pato suele ser informal. Un desarrollador murmura mientras revisa una prueba fallida. Alguien abre un documento de borrador y narra el flujo en lenguaje claro. Un compañero dice: "Explícamelo desde el principio", y sobre todo escucha. Un ingeniero de soporte reescribe un ticket hasta que la variable que falta se vuelve obvia. Un fundador que prepara un informe de error descubre el error mientras lo describe.
El trabajo remoto ha ampliado los formatos. Algunas personas graban un breve vídeo de pantalla para sí mismas antes de compartirlo. Otras escriben un borrador de mensaje y nunca lo envían. Las herramientas de IA también pueden actuar a veces como una especie de pato parlante, pero hay una diferencia que conviene tener en cuenta. El uso puro del pato consiste en aclarar el propio modelo antes de que los consejos externos empiecen a llevar en nuevas direcciones.
Bien utilizado, el método no tiene nada de místico. Es autoexplicación estructurada, con una alegre cara de goma adjunta.
Ejemplos
Un equipo está investigando pagos duplicados en un servicio de comercio electrónico. Localmente, el flujo de pago parece correcto. Mientras explica el flujo al pato, el desarrollador dice: "El trabajador de reintentos comprueba si el cargo ya existe antes de enviar una segunda solicitud". Entonces se detiene. No lo comprueba. Asume que el proveedor externo rechazará los duplicados. El error real es la falta de manejo de idempotencia, no algún comportamiento misterioso de la cola.
Una analista de datos intenta entender por qué el total de un panel cambia a medianoche. La consulta SQL parece inofensiva. Durante una explicación línea por línea, se da cuenta de que la aplicación almacena las marcas de tiempo en Tiempo Universal Coordinado, pero el informe las agrupa por fecha de calendario local. El gráfico no está equivocado de forma aleatoria. Está usando fielmente dos relojes distintos.
Un ingeniero de plataforma redacta un mensaje que comienza: "El despliegue falla solo en staging después del paso de migración". En el tercer párrafo se da cuenta de que su prueba local usaba una rama antigua con el esquema de ayer, mientras que staging había descargado la cadena de migración actual. El informe de error nunca se envía porque la propia explicación descubre el desajuste.
Malentendidos frecuentes
Un malentendido es que la depuración con el pato de goma es un truco infantil. Parece lúdica, pero el hábito subyacente es riguroso. Explicar algo con claridad es difícil. Por eso funciona.
Otro es que hay que tener un pato de verdad. No es así. El pato es solo un sustituto del público. Un borrador de texto, una nota de voz, un documento en blanco o un colega que deja hablar sin interrumpir pueden hacer el mismo trabajo.
Un tercer malentendido es que el uso del pato reemplaza las herramientas de depuración adecuadas. No es así. Siguen siendo necesarios las pruebas, los registros, los depuradores, los rastreos y una buena instrumentación. El pato ayuda a decidir hacia dónde apuntar esas herramientas y qué pregunta se está intentando responder realmente.
También se suele asumir que es solo para principiantes. En realidad, los ingenieros con experiencia lo usan constantemente, a menudo sin nombrarlo. Cuanto más complejo es el sistema, más valioso resulta forzar el propio razonamiento a salir a la luz.
Por último, algunas personas confunden el uso del pato con la programación en pareja. Se solapan, pero no son lo mismo. La programación en pareja es un estilo de trabajo compartido. El pato es una técnica de explicación que puede ocurrir en solitario o con alguien escuchando en silencio.
Riesgos y límites
La depuración con el pato de goma tiene límites. Es un primer paso, no un remedio para todos los errores difíciles. Si el problema requiere datos de producción, un rastreo profundo del perfilador o una segunda opinión experta, el pato no evitará ese trabajo. Solo ayudará a llegar a él con una descripción más clara.
También puede usarse mal. Algunos equipos convierten "¿has intentado explicárselo al pato?" en una forma educada de esquivar el problema. Esa es la versión mala. La versión buena es de apoyo: aclarar lo que se sabe y luego pedir ayuda rápidamente si se sigue atascado.
También hay una trampa con las herramientas más interactivas. Si un asistente de IA o un colega hablador empieza a sugerir soluciones demasiado pronto, se puede perder el beneficio de la explicación pura y acabar en el camino equivocado. Primero hay que hacer legible el error. Luego, pedir consejo.
En resumen, el pato es excelente para exponer la propia confusión. No es un permiso para evitar la colaboración, la evidencia o las pruebas disciplinadas.
Qué hacer a continuación
Si se reconoce este patrón en el equipo, conviene normalizarlo sin dramatismo. Animar a las personas a anotar cuatro cosas antes de escalar un error: qué debería ocurrir, qué ocurrió realmente, qué cambió recientemente y dónde termina la certeza. Esa plantilla es el pato con traje de negocios.
Hay que dar a las personas espacio para hacerlo bien. La interrupción constante destruye el tipo de explicación concentrada que este hábito necesita. Unos pocos minutos de tranquilidad pueden ahorrar una hora de intercambios posteriores.
También se pueden diseñar rituales de equipo en torno a esto sin que resulten forzados. Mantener una plantilla de depuración compartida. Pedir una reproducción mínima antes de una sesión en grupo. Tratar los informes de error claros como una habilidad valiosa, no como una carga administrativa.
Lo más importante es no convertir el pato en un obstáculo. Nadie debería sentir que debe realizar una pequeña ceremonia antes de que se le permita pedir ayuda. El objetivo es mejorar la calidad de la ayuda, no racionarla.
¿Tiene alguna pregunta o sugerencia, o quiere saber cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Necesito un pato de goma de verdad?
No. Cualquier objeto o formato que invite a una explicación cuidadosa sirve. Las personas usan cuadernos, pizarras, borradores de mensajes, notas de voz o un colega que acepta escuchar sin intervenir demasiado pronto.
¿Por qué ayuda hablar en voz alta?
Porque el habla impone una secuencia. Hay que pasar de un paso al siguiente y nombrar las suposiciones. Eso hace que los vacíos, las contradicciones y el pensamiento ilusorio sean mucho más difíciles de ocultarse a uno mismo.
¿Escribir un informe de error es una forma de depuración con el pato de goma?
Muy a menudo, sí. Redactar un informe de error claro puede actuar exactamente como el pato, sobre todo si se incluyen el comportamiento esperado, el comportamiento real, los pasos de reproducción y los cambios recientes.
¿Esto solo es útil para la programación?
No. También ayuda con decisiones de producto, investigaciones de soporte, trabajo de análisis e incidentes operativos. Siempre que un problema esté atascado en la mente como algo borroso, la explicación puede afinarlo.
¿Cuándo debo dejar de usar el pato y pedir ayuda?
Hay que parar cuando la explicación deja de producir información nueva. Si ya se puede describir el error con claridad pero aún no se puede avanzar, ese es el momento perfecto para involucrar a otra persona.
¿Puede un asistente de IA reemplazar al pato?
Puede ayudar, pero no es lo mismo. Un pato no orienta. Un asistente de IA puede introducir suposiciones de forma temprana. El mejor uso suele ser explicar el problema con claridad primero y luego pedir ayuda específica.
Fuentes
Lecture 4 - CS50x (CS50, Harvard University). Clear teaching definition of rubber duck debugging and evidence of its adoption in computer science education.