¿Hablar con un patito de goma mejora el rendimiento del programador durante la depuración?

En ingeniería de software (especialmente XP) existe la creencia común de que hablar con un patito de goma mejorará el rendimiento al depurar código problemático.

Se hace referencia a esta técnica en varios lugares de blogs muy respetados como Coding Horror (¡en una publicación sobre cómo mejorar la calidad de las preguntas formuladas en esta red, nada menos!), así como múltiples preguntas y respuestas tanto en Workplace como en Software Engineering stackexchange. redes

También encontré una referencia en un libro muy respetado 'El programador pragmático' (aunque el libro parece recomendar el uso de un ser humano que asiente con la cabeza en lugar de un pato de goma, lo que probablemente refleja la ausencia relativa de patos en un entorno de oficina estándar):

pato de goma

Una técnica muy simple pero particularmente útil para encontrar la causa de un problema es simplemente explicárselo a otra persona. La otra persona debe mirar por encima de su hombro a la pantalla y asentir con la cabeza constantemente (como un patito de goma que se balancea arriba y abajo en una bañera). No necesitan decir una palabra; el simple acto de explicar, paso a paso, lo que se supone que debe hacer el código a menudo hace que el problema salte de la pantalla y se anuncie.

¿Por qué "pato de goma"? Mientras estudiaba en el Imperial College de Londres, Dave trabajó mucho con un asistente de investigación llamado Greg Pugh, uno de los mejores desarrolladores que Dave ha conocido. Durante varios meses, Greg llevó consigo un patito de goma amarillo, que colocaba en su terminal mientras codificaba. Pasó un tiempo antes de que Dave tuviera el coraje de preguntar....

Múltiples fuentes sugieren un mecanismo de acción plausible para el efecto de explicar el código a un pato. Aquí está 'El programador pragmático' de nuevo:

Suena simple, pero al explicar el problema a otra persona, debe indicar explícitamente las cosas que puede dar por sentadas al revisar el código usted mismo. Al tener que verbalizar algunas de estas suposiciones, de repente puede obtener una nueva perspectiva del problema.

y también encontré una publicación de blog sobre la psicología subyacente de la técnica .

No he podido encontrar ningún estudio académico o de la industria que demuestre la eficacia de hablar con un patito de goma.

No creo que sea irrazonable esperar que se hayan llevado a cabo estudios sobre esto porque existen estudios similares, altamente referenciados (enlace pdf) que muestran que el emparejamiento entre humanos reales (es decir, no de goma) mejora el rendimiento del programador.

En resumen, esta parece ser una creencia generalizada defendida por varias voces fuertes en la comunidad, y aunque existe una base racional para el mecanismo de acción y parece haber mucha evidencia anecdótica, no parece haber cualquier estudio empírico que demuestre que este efecto es real.

Mis preguntas:

  1. ¿Existe alguna evidencia empírica que demuestre que hablar con un patito de goma mejora el rendimiento del programador durante la depuración?
  2. ¿Qué tan grande, si lo hay, es el efecto? ¿Es comparable a la programación en pareja con un humano?

Editar: creo que mi pregunta es diferente a esta pregunta sobre péndulos porque mi pregunta no es sobre charlatanería. También porque:

  1. La respuesta a la pregunta del péndulo es principalmente explicar un mecanismo de acción plausible, pero en mi pregunta no niego que haya un mecanismo de acción plausible para el pato. Específicamente estoy buscando respuestas con evidencia empírica sobre el uso de patos en el dominio del desarrollo de software. Quiero saber qué tan grande es el efecto de consultar a un pato. (He actualizado la lista de preguntas anterior para reflejar esto). Si bien hay estudios académicos a los que se hace referencia en la respuesta del péndulo, se relacionan con la ideometría (el mecanismo de acción propuesto del péndulo, pero no del pato), por lo que no constituyen una respuesta a mi pregunta.
  2. La respuesta a la pregunta del péndulo limita cuidadosamente el alcance a las preguntas que el péndulo puede responder a las preguntas que el autor de la pregunta ya sabe. La respuesta dice preguntas como "¿Me pedirá que me case con él?" están fuera del alcance de un péndulo, pero preguntas similares pueden ser útiles en un escenario de depuración o programación en pareja al hacer que el programador haga preguntas para las que no tiene la respuesta, probar esa posibilidad y ayudarlo a descubrir nueva información. (Por ejemplo, "Y entonces, Sra. Pato, esta variable debe establecerse en verdadero cuando ingresamos este método... Lo probaré rápidamente para verificar... ¡Ajá, es falso!").

En caso de que alguien no tuviera un pato de goma disponible, pero consulté un loro de peluche, que se puede ver fotografiado a continuación (izquierda), antes de publicar esta pregunta, pero lamentablemente no estaban familiarizados con la literatura sobre este tema.El loro (izquierda) que fue consultado.

¿Posible duplicado? skeptics.stackexchange.com/questions/19220/… Al menos la respuesta.
Puedo confirmar por experiencia personal que explicar mi problema en el cuadro "Hacer una pregunta" en stackoverflow.com muy a menudo me permite ver un error tonto que cometí y que me había eludido durante horas... Supongo que explicárselo a un ¡el patito de goma podría tener un efecto similar!
@JasonR Las preguntas no son ni remotamente similares. Si cree que la técnica del "pato de goma" es fundamentalmente la misma que la técnica del "péndulo", explique por qué (con evidencia) en una respuesta, que luego vincula / cita de esa otra respuesta. De lo contrario, su razonamiento está oculto e inexplicable en el mecanismo de votación cerrada.
Aparentemente, Ballmer Peek también se estudia, lo que parece mucho más difícil de vender a un comité de subvenciones.
Para aquellos que quieran responder, Rubber Ducking es en realidad un catalizador para algo llamado Efecto Eureka .
"mi pregunta no es sobre charlatanería " -- Veo lo que hiciste ahí...
Quitaré la bandera. "Mordí" la parte de la respuesta donde hablan de la técnica del patito de goma como una metodología análoga. Por cierto, aquí está el enlace del patito de goma: blog.codinghorror.com/rubber-duck-problem-solution
Si encuentra alguno, ¡me encantaría ver cómo los académicos definen la eficiencia de la programación! ¡Soy más escéptico de una buena definición universal de eficiencia de programación que del patito de goma!
No se trata del patito de goma. Se trata de verse obligado a explicar las cosas muy claramente. Si miras el código, tienes suposiciones implícitas en tu cabeza. Si se lo explicas a otra persona (o pretendes explicárselo a otra persona), debes explicar todas estas suposiciones y ser preciso sobre lo que crees que hace el código. Esto a menudo revela que en realidad no sabe lo que hace algún código o que sus suposiciones son incorrectas y, por lo tanto, le permite encontrar el error mucho más fácilmente. Preguntar en SO es el mismo proceso y, a menudo, formular la pregunta deja en claro dónde está el problema. Por lo que es cierto
Oh, espera, ¿alguien ha desarrollado una forma de medir la productividad del software? ¡Impresionante!
@Mindwin Todavía podrías hacer una prueba de comparación, probablemente. Tome una gran empresa de programación y sus tickets internos de errores, divídala en dos, mida el tiempo necesario para resolver el problema con y sin esta técnica. No digo que sea fácil de hacer, pero diablos, ¡todas las cosas fáciles ya se han hecho!
@Polygnome: puede tratarse del pato. Si la interacción es como si el Pato estuviera respondiendo, es mejor revisar los protocolos de tiradores activos en el lugar de trabajo... pero sí, entiendo el punto que en realidad estabas diciendo.
@PoloHoleSet Sin embargo, si el pato comienza a responderle a sus desarrolladores, debe verificar lo que realmente están bebiendo en sus tazas de café.

Respuestas (1)

No encontrará estudios que hagan algo como comparar la efectividad de un patito de goma frente a un loro de peluche específicamente para programadores que trabajan en tareas de depuración, ni podemos realmente medir el tamaño del efecto, pero su pregunta principal puede responderse si lo abordamos en un nivel ligeramente más alto: ¿hablar en voz alta sobre un problema ayuda a resolverlo?

A lo que la respuesta es claramente .

Mejore la metacognición y la resolución de problemas hablando en voz alta consigo mismo

En una investigación reciente sobre TAPPS, informada en la publicación Research Foundations de la Universidad de Arkansas, primavera de 2011, el autor señaló que la mayor velocidad y eficacia de la resolución de problemas en pareja tiene poco que ver con el monitor y mucho que ver con el propio comportamiento del solucionador de problemas. ; pensando en voz alta o TA. La verbalización constante de sus pensamientos en voz alta alentó a los solucionadores de problemas a corregir continuamente los pasos lógicos defectuosos . El mecanismo causal del éxito fue la metacognición del solucionador de problemas.

TAPPS es "Resolución de problemas en pareja hablando en voz alta", donde uno de los socios es el socio "activo", pensando en voz alta sobre un problema, el otro es simplemente un "monitor" o un "oyente", desempeñando un papel solo un poco más interactivo que pato de goma de nuestro programador.

Hay mucha investigación académica sobre TAPPS .

Otro artículo que resume un estudio de investigación diferente: Pensar en voz alta ayuda a resolver problemas

El profesor José Luis Villegas Castellanos, de la Universidad de los Andes, Venezuela, dijo que discutir problemas era una forma inteligente de aprender.

“Aquellos alumnos que piensan en voz alta mientras resuelven un problema matemático pueden resolverlo más rápido y tienen más posibilidades de encontrar la solución adecuada que aquellos que no lo hacen”, dijo.

El estudio, dirigido por la Universidad de Granada, España, se centró en estudiantes universitarios de último año de matemáticas, a quienes se grabó mientras intentaban resolver problemas matemáticos complejos.

Aquellos que detallaron su proceso de pensamiento en voz alta tenían más posibilidades de responder correctamente la misma pregunta que aquellos que no hablaron sobre su plan de resolución de problemas, encontraron los investigadores.