Cómo afectan los sesgos cognitivos al desarrollo de software

Existen diversas variables que pueden influir en nuestro trabajo como desarrolladores. Estas pueden ser de aspecto técnico, que serían aquellas relacionadas con los conocimientos sobre determinadas tecnologías, arquitecturas o patrones de software, y que podemos mejorar mediante formación en materias concretas que nos interesen. Pero, además, existen otros factores que pueden influir en la calidad de nuestro código y que, en este caso, estarían relacionados con asuntos psicológicos y cognitivos. Y, más concretamente, interfieren en detalles del ámbito personal como el razonamiento, la memoria o el estado de ánimo. Y es en esto último en lo que apenas existe información concreta con relación a cómo nos afecta a la hora de desarrollar software. 

Para aportar más información, en el artículo queremos mostrar que existen una serie de sesgos que influyen en nuestra percepción, razonamiento y toma de decisiones, y que pueden alterar el resultado de nuestra aplicación, evitando el objetivo final común de todo el equipo: entregar software de calidad lo antes posible. 

¿Qué son los sesgos cognitivos? 

Un sesgo cognitivo es un efecto psicológico. Dicho efecto causa un desvío en nuestro proceso mental cuando tenemos que asimilar una serie de datos, que resulta en que podamos distorsionar, emitir un juicio inexacto, o interpretar de forma ilógica la información que recibimos. 

En el caso que nos ocupa, los sesgos cognitivos nos influyen en el desarrollo de software afectando a la forma en que percibimos el problema a solucionar (corregir un bug, diseñar una nueva app, crear una nueva feature…) y, en consecuencia, el resultado que entregamos en forma de código. 

Sesgos cognitivos que nos influyen en el desarrollo de software 

Podemos diferenciar dos tipos de sesgos: los que están relacionados con cómo tomamos las decisiones para comportarnos de determinada forma, y los que intervienen en nuestras creencias de cara a un futuro. 

Sesgos en la toma de decisiones y predisposiciones conductuales 

Aversión a la pérdida 

Este primer efecto trata de la prioridad que le damos a evitar pérdidas en lugar de intentar conseguir ganancias. 

Una frase muy extendida en el sector tecnológico durante muchos años ha sido: “Si funciona, no lo toques”.  Pero esto supone un obstáculo enorme para desarrollar nuevo software, donde la creatividad y la innovación han supuesto importantes hitos en la historia. ¿Cómo sería nuestra sociedad si no se hubiera innovado en tecnología, aun con el riesgo de perder? Sin duda, sería una sociedad muy distinta si no contáramos con Internet, los negocios digitales o los e-commerce. 

Efecto de arrastre 

Este efecto es muy conocido y está extendido en muchos ámbitos. Se refiere a la tendencia de hacer o creer algo por el simple hecho de que haya una cantidad importante de personas que hagan o crean lo mismo.  

En un momento donde cada vez disponemos de más contenido audiovisual que nos mantiene al día de la tecnología (blogs, foros, plataformas de streaming o redes sociales), este efecto se incrementa. Esto debería hacernos reflexionar sobre tendencias en el uso de tecnologías como inteligencia artificial, Docker, Kubernetes, arquitectura hexagonal, monolitos, o la elección de determinado framework de Javascript. Siempre debemos tomar la decisión basándonos en los requisitos del proyecto, procurando evitar el mencionado efecto de arrastre. 

Efecto de anclaje 

El sesgo de anclaje se evidencia cuando se muestra una tendencia a juzgar una situación teniendo en cuenta principalmente la información más reciente que tenemos sobre ella. Esto es especialmente relevante en el momento de la toma de decisión ya que, si no disponemos de demasiada información, tenderemos a darle más peso a las últimas noticias con las que contamos.  

Podemos poner dos ejemplos más concretos de cómo nos puede afectar en el desarrollo de software. 

El primero sería a la hora de elegir una librería para nuestro proyecto. Si no disponemos de mucha información, le daremos mayor valor a la recomendación de alguna persona que sea relevante para nosotros. 

El segundo podría ser en el momento de adquirir una herramienta que, en el momento de revisarla, vemos con un descuento… ¡del 50%! Si la decisión se debe tomar rápido, el hecho de que valga la mitad en ese momento tendrá un valor importante, porque no disponemos de más información. 

Efecto de espectador 

Este efecto se produce en situaciones en las que alguien necesita ayuda, y expone que es menos probable que una persona se ofrezca a ayudar cuanta más gente haya presente; o, a la inversa, cuantas menos personas haya en una situación, es más probable que se ayude a quien lo necesite.  

Esta sería una de las causas por las que varios equipos pequeños y autónomos (como fomenta el desarrollo agile) suelen obtener mejores resultados que un equipo más grande que tenga en total el mismo número de desarrolladores. 

Sesgo de confirmación 

Este es un sesgo que seguramente todos hemos vivido, pero del que no somos conscientes hasta que nos lo explican. Ocurre cuando le damos más relevancia a la información que confirma nuestras preconcepciones o la opinión previa que tenemos de algo, prestando menos atención o credibilidad a los argumentos que refutan nuestra creencia.  

Es fácil que te hayas encontrado en la situación de evaluar el uso de una arquitectura o una herramienta. Pues bien, cuando buscamos información sobre ello, tendemos a darle mucha importancia a la información que confirma nuestros gustos o preferencias en lugar de buscar toda la información relevante antes de inclinarnos por alguna. 

Sesgo de punto ciego 

En este caso, se refiere a la tendencia de no darnos cuenta de los prejuicios cognitivos que tenemos o, dicho de otra forma, la tendencia a vernos menos sesgados que los demás. 

Históricamente han existido diferencias de opiniones notables entre departamentos de Desarrollo y QA, o entre Desarrollo y Sistemas, muchas veces debido al aislamiento y falta de empatía, mientras que el objetivo siempre ha sido el mismo: que los usuarios disfruten de nuestras aplicaciones. 

Es por ello que las empresas deben comprender cómo aplicar DevOps, que elimine los silos entre equipos o departamentos, en favor de comunicaciones más fluidas y ejecuciones de proyectos más ágiles. 

Sesgo retrospectivo 

Este sesgo supone recordar las decisiones que hemos tomado como mejores de lo que en realidad fueron. Puede llevarnos a pensar que, gracias a cómo hemos diseñado cierta feature, hemos evitado una gran cantidad de problemas, aunque fueran detalles menores que apenas afectaron la aplicación o tuvieran relevancia, y se podían haber resuelto en mucho menos tiempo con un enfoque más simple. 

Sesgo de falso consenso 

Hablamos de un sesgo que nos lleva a pensar que nuestros propios hábitos, valores y/o creencias están más extendidos de lo que realmente están. Es decir, de alguna forma, tendemos a sobrestimar lo que nosotros hacemos o pensamos, creyendo que los demás están de acuerdo o coinciden con nosotros. 

Es cierto que se ve influenciado por el anteriormente mencionado efecto de arrastre (tendemos a pensar y hacer lo mismo que la mayoría), y por eso es fácil pensar también que los demás estaban realmente de acuerdo. El inconveniente de este sesgo en el desarrollo de software es que se puede dar por hecho que el patrón de diseño que hemos planteado para corregir una vulnerabilidad es el correcto, y los demás lo ven igual. Pero, afortunadamente, el pair programming puede ayudarnos con una visión distinta e identificar los posibles errores de planteamiento. 

Sesgos en la probabilidad y las creencias 

Efecto de ambigüedad 

Este efecto se produce cuando rechazamos directamente algo por falta de información, ya que nos lleva a pensar que es improbable. 

He escuchado en demasiadas ocasiones argumentos en contra de las pruebas unitarias o de interfaz o, al menos, motivos para no poder implementarlas porque se veía poco probable que mejorara la calidad de una aplicación o se redujera la probabilidad de error. Obstáculos que, tras comprobar que su solución no era difícil, escondían simplemente un desconocimiento de cómo llevarlas a cabo por falta de formación. 

Prejuicio de retrospectiva o recapitulación 

Este prejuicio nos conduce a ver los hechos que ya han ocurrido como fenómenos predecibles. Es decir, nos aventuramos a predecir el éxito o el error de un planteamiento por el resultado que tuvo en un pasado.  

Eventos pasados no pueden asegurar que vaya a ocurrir lo mismo. Es fácil probarlo ya que, si se analiza con detalle, los factores y variables que estaban relacionados con la situación pasada han cambiado y, por lo tanto, ya no estaríamos hablando “de la misma situación”. 

Si buscamos cómo nos puede influir para programar software de calidad, podemos encontrarnos con que no debería tomarse como único motivo para elegir una arquitectura de una aplicación el hecho de que en un proyecto anterior no fuera tan bien como se esperaba… Incluso, si se revisan los errores pasados, se pueden detectar nuevos aspectos que nos harían darnos cuenta que el problema no fue la arquitectura, y podrían haber sido otros factores: el equipo de desarrollo, la formación necesaria, el detalle de los requisitos, etc. 

Efecto de primacía o primera impresión 

En este caso, el efecto de primacía tiende a otorgar mayor valor a los eventos iniciales que a los posteriores. Sería el motivo por el que también se extendió aquella frase de: “La primera impresión es la que cuenta”.

Esta situación, como desarrolladores, es habitual haberla vivido con proyectos heredados, los cuales usualmente tienen código en mal estado y difícilmente de mantener. Y es que, debido al efecto de primacía, es difícil que, aun con el paso del tiempo, reconozcamos que la aplicación está en buen estado. 

Conclusión 

Los sesgos cognitivos son efectos que, de una forma u otra, van a afectar al código que escribamos y, por consiguiente, a la calidad de nuestras aplicaciones. 

En algunos casos será más fácil evitarlos que en otros; lo importante es conocerlos y tenerlos presentes para ayudarnos a ser lo más objetivos posibles con el fin de entregar el mejor software que podamos trabajar. 

Así que, la próxima decisión relevante que debas tomar en tu proyecto, pregúntate si puede estar influenciada por algunos de estos sesgos o creencias. Como en otras muchas facetas del desarrollo de software, el apoyo en otros compañeros es clave para obtener una visión objetiva y ponderada de tu proyecto. 

¿Te animas a introducirte en el fascinante mundo de DevOps? En hiberus contamos con un equipo completo de especialistas DevOps que están deseando trabajar contigo y con tu empresa para ayudarte a dar el salto a la transformación digital.