"Esos muchachos eran terribles"

Algo de código

tl; dr la ciencia cognitiva puede ayudar a darnos información acerca de nuestras propias limitaciones en comprender por qué otros escriben código malo.

¡ Este código es horrible! Hemos todo hecho - comenzó a trabajar en algún lugar y visto algunos deficiente código escrito por alguien ya no en el proyecto. Realizar una búsqueda en twitter para que [1] y verás tantos desarrolladores de software enojado quejándose de la calidad del código en los proyectos que han heredado que te preguntarás cómo nada nunca funciona. Es una realidad que en la mayoría de los proveedores software proyectos va a cambiar. Proyectos se externalizan, compraron casa, cambian los miembros del personal, organizaciones se reestructuraron, planes de negocio son decisivas. Cambian de proveedores, y cuando lo hacen invariablemente a escuchar el estribillo "esos muchachos eran terribles, mira cómo has aplicado x, y, z" de los nuevos titulares.

Ahora, sin duda hay código por ahí que es 'malo', en el sentido de que es defectuoso y no funciona como está previsto. Igualmente hay personas que hablar basura el trabajo de anteriores equipos de entrega para hacerse mirada heroica como solucionar los 'problemas'. Pero fuera de estos extremos, qué sucede si muchas de las críticas que escuchamos de la tendencia perfectamente normal, si es irracional, que los psicólogos conductuales llaman el "Error Fundamental de atribución". ¿[2]? Suena loco, verdad?

Resulta que el Error Fundamental de atribución es un sesgo cognitivo bien establecido y es algo inherente en todos nosotros. En pocas palabras, significa que todos tenemos la tendencia a atributo deficiencias en el comportamiento de otros a su personalidad y limitaciones (su disposición) y deficiencias de atributo en nuestro propio comportamiento a la circunstancia (la situación). Por ejemplo, se podría pensar que el equipo anterior era pobre o inexperto porque no refactorizar código duplicado, y dado un mundo perfecto usted sería probablemente correcto. Pero qué pudo haber pasado es que lejos de ser pobres, las circunstancias de la entrega habían sido comprometidas de alguna manera; por ejemplo, cambia el requisito de último minuto, enfermedad o dificultades técnicas combinadas con un plazo muy apretado significado código de refactorización que no agregado ningún valor para el negocio adicional no era un uso eficiente del tiempo del equipo de entrega. Bien podría haber sido que en las circunstancias, que nunca tendrán acceso a o ser capaces de revivir, que código era lo mejor que pudieron entregar.

El problema se agrava a menudo por los equipos de desarrollo de ingenuo que normalmente toman un enfoque martillo de oro [3] a los problemas. Ver este código 'malo' o 'pobre' que se centrarán en fijar que - a menudo ciego al hecho de que el código mal realmente está sentado allí en entornos de producción entrega valor al negocio. Por preferir gastar miles de dólares del dinero de clientes a solucionar un problema que no resultará en un aumento correspondiente en los ingresos, tienen el doble efecto de reducir la confianza del cliente en su tecnología solicitada mientras que realmente sus clientes a perder dinero.

Como una ilusión óptica, no podemos evitar que nos caiga para la ilusión cognitiva del Error Fundamental de atribución - después de millones de años de evolución, nuestro subconsciente es sólo por pensar de esta manera (y hacerlo cientos de veces por semana, si estamos viendo las noticias, viajar en el tren o salir a tomar algo con amigos.) Afortunadamente a través de desarrollos en la ciencia cognitiva en los últimos 40 años, somos ahora conscientes del Error Fundamental de atribución y puede por lo menos trate de identificar el momento en podríamos han caído en esta trampa cognoscitiva. ¿Sabiendo esto, cuando a continuación mira algunos código 'malo' que ha heredado, quizá podría decir más sobre el contexto en el que fue escrito, y menos sobre la calidad de la anterior entrega del equipo, que nos gustaría admitir? Tal vez reconocer esto es un signo de un buen desarrollador?

[1] https://twitter.com/search?q= "este + código + es + terrible"

[2] http://www.amazon.co.uk/Thinking-Fast-Slow-Daniel-Kahneman/dp/0141033576 y http://www.amazon.co.uk/Predictably-Irrational-Hidden-Forces-Decisions

[3] https://en.wikipedia.org/wiki/Law_of_the_instrument

Artículo originalmente publicado en https://www.linkedin.com/pulse/those-guys-were-terrible-andrew-larcombe