Rompiendo el hábito

Este año ha sido muy movido y lleno de decisiones para mí, sobre todo en el tema de viajar. Aunque me gusta mucho, siempre hay mucha logística detrás de la planificación de un viaje y si eres como yo que prefieres tener el mejor precio y conseguir la mayor cantidad de beneficios disponibles, puedes terminar en un ciclo de decisiones infinito que te lleve a perderte muy buenas oportunidades.

Esta semana me enfrenté con un reto de programación que es el ejemplo perfecto de los malos hábitos al tomar decisiones que pueden llevar a impactar en el tiempo de desarrollo de un proyecto.

Recibí código para implementar gráficos de D3 (una librería para hacer gráficos interactivos impresionantes https://github.com/d3/d3/wiki/Gallery ). El problema es que había un set de gráficos en la versión 3 y otros en la versión 4, todos en un mismo documento HTML (página web) y esto causaba que no se pudieran visualizar correctamente.

Mi primera reacción fue intentar investigar cómo cambiar de versión los gráficos, pero al conocer tan poco de la librería D3 mis primeros intentos demostraron ser infructuosos y ahí fue donde tomé la primera mala decisión basada en mi parálisis de análisis.

Conté al equipo mi situación y que por el momento para no detener el proyecto dejaría los gráficos en la versión 3 que eran la mayoría y seguiría investigando cómo tener 2 versiones dentro del proyecto.

La búsqueda de cómo tener ambas versiones en un mismo documento da pocos resultados en Google, lo cual debería haberme dado una pista de que estaba tomando una mala decisión basada en mi “zona de confort” a lo desconocido de D3. Utilicé el método descrito en el siguiente comentario de Stackoverflow que resultó en una implementación no tan complicada:

https://stackoverflow.com/questions/16156445/multiple-versions-of-a-script-on-the-same-page-d3-js

Todos los gráficos se veían bien y concluí que había llegado a la solución correcta.

Días después comenzaron a aparecer problemas en los gráficos, algunos se mostraban incompletos. Tuve que regresar a revisar la implementación, solicité consejo a mi mentor favorito que tampoco es experto en D3 y juntos comenzamos a sobre analizar las posibilidades para mantener las 2 versiones con ideas como utilizar namespaces o de frames independientes (un documento HTML embebido en otro).

Antes de volver a caer en otro análisis parálisis decidí consultar con mi equipo las diferentes soluciones para el uso de las 2 versiones. Ninguna parecía ser adecuada y todos llegamos a la conclusión de que lo óptimo sería actualizar el código de los gráficos a la versión 4.

La mejor solución, aún siendo la primera que pasó por mi mente, no pudo llegar a mi después de sobre analizar el problema debido a otro hábito que es muy común pero poco conocido, el Efecto Einstellung que consiste en que tus experiencias pasadas afectan la manera en cómo solucionas los problemas. Yo había intentado cambiar las versiones por mi cuenta pero no había tenido éxito así que descarte esa posibilidad y no volví a ella, pero cuando la reflexión del problema fue grupal, la conclusión fue diferente porque mi equipo no tenía la predisposición de intentos anteriores para resolver la situación.

Finalmente, con ayuda de una persona que conoce más sobre D3 conseguí actualizar las gráficas y ahora tenemos una implementación que no requiere de “hacks” para funcionar.

Espero que mí historia sea útil para sus futuras toma de decisiones. A mí me encantaría conocer algunas anécdotas por parte de nuestros lectores, los invito a compartir aquí en el blog de TechWo.

Les dejo diferentes referencias sobre estos hábitos y algunas sobre otros más. Recomiendo mucho el podcast sobre el Efecto Einstellung con algunas ideas de cómo evitarlo.

Referencias:

https://es.wikipedia.org/wiki/Par%C3%A1lisis_del_an%C3%A1lisis

https://es.wikipedia.org/wiki/Zona_de_confort

https://en.wikipedia.org/wiki/Overengineering

https://developertea.simplecast.fm/episodes/59037-the-einstellung-effect

https://techbeacon.com/35-bad-programming-habits-make-your-code-smell