Tostón Legal
(Por si te interesa, ni usamos ni comemos galletas 🍪)
WYSIATI en el Desarrollo de Software
Este sesgo cognitivo lo describe Daniel Kahneman, el premio nobel que dice que a veces programas rápido y otras despacio.
Miguel A. Gómez · Seguir2 min read · 14 Ago 2023
Según dicen estas palabras las pronunció el capitán de un famoso barco:
“En toda mi experiencia profesional, nunca me he encontrado en un accidente que sea digno de mención.
En todos mis años en el mar sólo he visto un barco en una situación difícil.
Nunca vi ningún naufragio.
Ni jamás me he encontrado en una situación que amenazara con acabar en algún tipo de desastre.”
E.J. Smith, 1907, capitán del RMS Titanic.
Todos sabemos lo que sucedió 5 años después.
Menuda perla de sabiduría que nos ha dejado este hombre.
Este es un gran ejemplo de lo que se conoce como:
El sesgo de “lo que vemos es todo lo que hay” o WYSIATI (por sus siglas en inglés, what you see is all there is)
Este sesgo cognitivo lo describe Daniel Kahneman, el premio nobel que dice que a veces programas rápido y otras despacio.
WYSIATI se refiere a la simplificación que realiza nuestro cerebro cuando incluimos unos pocos datos conocidos como si fueran “todo lo que hay”.
Dejando de lado lo que sabemos que no sabemos…
… y lo que no sabemos que no sabemos, también.
Cuando programamos, WYSIATI nos ocurre constantemente, desconocemos tantas cosas que vamos acumulando deuda técnica sin darnos cuenta.
A veces porque no nos preocupamos de pensar si la manera en la que estamos desarrollando una funcionalidad es la más simple.
O quizás sea por las prisas y la sensación de urgencia constante.
Otras, ni siquiera somos conscientes de que estamos arruinando el código, simplemente ocurre por desconocimiento o falta de entrenamiento.
Desconocimiento unas veces de las necesidades reales del negocio y otras veces de la propia técnica.
Sea como fuere, la realidad es que nadie escribe código idóneo a la primera.
Por más cuidado que pongas cometerás errores de diseño que solamente se pueden subsanar mediante refactorización permanente, para lo cual es fundamental tener tests.
La refactorización no es algo que se hace una vez al año durante dos semanas seguidas, sino unos cuantos minutos cada día.
Las pruebas son nuestra red de seguridad a la hora de hacer refactoring.
Por esta y otras razones, sin buenos tests no puede haber calidad en el código.
Quizás te interese
La newsletter, por Miguel A. Gómez
