La semana pasada, pasé una cantidad de tiempo decente eliminando el código muerto de nuestra base de código. Me gusta borrar el código. En cuanto a mí, tan pocas cosas traen el mismo placer que poner las cosas en orden en el código. Sí, me encanta tanto que estoy perplejo por los ingenieros que dejan código innecesario en la aplicación. Pero el fin de semana escuché a alguien hablar sobre el experimento de Milgram "Sumisión a la autoridad" (también escribieron sobre eso en el centro), y no pude evitar establecer un paralelismo entre la persona que sorprendió a otro ser humano y el ingeniero que deja errores conocidos y mal código.
Si no está familiarizado con el experimento de Stanley Milgram, entonces consiste en el hecho de que el Experimentador (una persona con autoridad) ordena al Maestro (el objeto de estudio) golpear al Estudiante en una serie de descargas crecientes de corriente, que se encuentra en otra sala. Ilustración de Wikipedia:
E - experimentador, T - maestro, L - aprendiz
La esencia del experimento fue estudiar las reacciones de las personas a las órdenes que entran en conflicto con sus principios morales. Antes del experimento, se creía que la mayoría de los sujetos lo detendrían tan pronto como se dieran cuenta de que estaban lastimando al Estudiante. Sin embargo, durante el experimento resultó que un número sorprendente de sujetos alcanzó una descarga máxima de 450 voltios.
En el primer conjunto de experimentos de Milgram, el 65 por ciento de los participantes (26 de 40 personas) usaron el valor máximo posible de 450 voltios, aunque no fue agradable para ellos hacer esto; en cierto momento, cada participante se detuvo y dudó del experimento; algunos participantes querían parar y devolver el dinero que pagaron por participar. Durante el experimento, los participantes experimentaron diversos grados de emoción y estrés. Sudaban, temblaban, tartamudeaban, se mordían los labios, gemían, se clavaban las uñas en la piel, algunos se reían nerviosamente.
Cuando nos enteramos de tales resultados, queremos creer que nunca haríamos eso. Queremos creer que "simplemente obedecer órdenes" es un defecto humano que no tenemos. Pero experimentos como el experimento de Milgram muestran que tal fe es optimista en el mejor de los casos, y completamente errónea en el peor.
Y ahora que sabemos cómo las personas reaccionan a la autoridad, cuando está en juego el dolor físico, veamos cómo los programadores reaccionan a la autoridad cuando se trata de cosas más abstractas, como la frustración y las molestias. Tomemos el diagrama del experimento de Milham y rediseñémoslo para reflejar el equipo de desarrollo:
Si miramos al equipo de desarrollo como se muestra en la ilustración, no es tan sorprendente por qué los ingenieros dejamos código incorrecto y dejamos errores conocidos. Probablemente en algún momento la persona en el poder dejó en claro que no tenemos tiempo para solucionar los problemas o que estos problemas no tienen prioridad en comparación con otras cosas en la hoja de ruta. O que eliminar el código muerto no aporta valor al usuario. Como resultado, dejamos el código como está y pasamos a la siguiente tarea, aunque esto entra en conflicto con nuestra brújula moral y los conceptos de lo que es bueno y lo que es malo.
En el experimento de Milgram, los sujetos a menudo dudaron y protestaron contra el envío de otra descarga a una persona en otra habitación. En tales casos, el experimentador exigió la continuación de una de las frases predefinidas:
- "Por favor continúe" (Continúe / Continúe);
- "El experimento requiere que continúes";
- "Es absolutamente esencial que continúes" (Es absolutamente esencial que continúes);
- "No tienes otra opción, debes continuar".
Usando solo palabras, el experimentador pudo asegurarse de que el 65 por ciento de los sujetos en contra de su voluntad golpeara a otras personas con descargas de corriente muy dolorosas. Me pregunto qué palabras usamos en el contexto del desarrollo de software.
- Esto no es lo que decidimos, sino el equipo del producto.
- Necesitamos cumplir con la fecha límite
- El equipo de marketing está a punto de lanzar un comunicado de prensa la próxima semana.
- Cerramos muy pocas entradas
- Tiraremos este código de todos modos
- Esta es una solución temporal.
- Necesita mejorar el rendimiento de su equipo
- Esto afectará a un pequeño número de usuarios.
- Esto no es una prioridad para nosotros ahora.
- Lo arreglaremos más tarde
- Esto es lo que la gerencia quiere
- ¿Por qué tanto tiempo?
- Necesito hacerlo más rápido.
No estoy escribiendo sobre esto para sugerir una solución. No lo tengo Escribo para cultivar, antes que nada en mí mismo, simpatía y comprensión . Cuando veo un código que deja una sensación de desconcierto o comportamiento que no entiendo, debo recordar que las acciones no siempre reflejan intenciones. Debo recordar que los ingenieros dejan un código incorrecto no porque no les importe: dejan un código incorrecto porque no tenían la libertad de ponerlo en orden. Y dejan errores no porque no les importen los usuarios, sino porque no tenían la autoridad para desviarse de la hoja de ruta del producto.