La mente es la principal herramienta del desarrollador de software. Puedes ayudar a que se desempeñe mejor si le das, a su vez, herramientas que te permitan organizar, comprender, combinar y analizar más rápido la información. Estas herramientas además te pueden ayudar a ver cosas claramente que antes eran imposibles de ver, o a llegar más profundo en los análisis.
Estas herramientas son los modelos mentales, que en este artículo explicaremos, pero además daremos algunos ejemplos que te servirán directamente como desarrollador. Estos ejemplos son, a nuestro modo de ver, los modelos esenciales que debes conocer. Empecemos dando una definición clara.
¿Qué son los modelos mentales?
Un modelo mental es una estructura que te permite organizar la información que recibes o que observas, para que puedas ver aspectos particulares de esta, aplicarle proyecciones o simplemente para que puedas entenderla mejor. También se puede pensar en ellos como en lentes que te permiten ver el mundo de una forma particular.
Los desarrolladores de software estamos acostumbrados a usar modelos para representar la realidad. Recuerda que un modelo es una abstracción, una representación simplificada de la realidad que se enfoca en ciertos elementos y deja fuera otros.
Los modelos mentales son esto mismo, pero la diferencia es que tienen aplicación a través de muchas situaciones. Estos modelos mentales te permiten usar la información de manera más eficiente y, a veces, ver la realidad más claramente. Charlie Munger, uno de los principales proponentes de los modelos mentales, dice que para pensar efectivamente, debes tener una malla o red de modelos mentales que puedas usar para pensar mejor. Algo a lo que se pueden parece un poco es a los patrones de diseño, pero aplicados a la vida real.
Nuestro objetivo es ayudarte a construir esta malla de modelos mentales que te permitan ser más efectivo en el desarrollo de software. Empecemos con los más básicos.
La navaja de Ockham
Este es uno de los modelos mentales que más personas conocen. En líneas generales establece que cuando estés buscando explicaciones a algo que hayas observado y estés decidiendo entre varios posibles caminos, el más sencillo es el que tiene la mayor probabilidad de ser la explicación correcta.
¿Cómo se puede aplicar a los problemas que nos enfrentamos comúnmente como desarrolladores? Siempre que estés decidiendo entre diferentes diseños que cumplen con los requerimientos actuales, escoge el más sencillo de los diseños, sin dejarte influir demasiado por que podrías necesitar en el futuro. Esto se conecta con el principio de YAGNI (You aren’t gonna need it), que dice que no debes implementar cosas que no necesitas ahora, porque podrías necesitarlas en el futuro. También se conecta con el principio de buscar la simplicidad al máximo en el desarrollo de software.
También lo puedes aplicar a los procesos que modelas en el software: cuando estés descubriendo el por qué de algo,
El mapa no es el territorio
Los desarrolladores de software trabajamos creando modelos de la realidad que pueden ser representados dentro de una computadora, muchas veces para simular procesos o simplemente capturamos ideas que ya son abstractas para que corran dentro de la computadora.
Un mapa es un modelo de un territorio físico. Pero podemos cometer el error de pensar que el mapa y el territorio son equivalentes, cuando lo cierto es que, al ser un modelo, el mapa es una representación imperfecta y simplificada del territorio real.
Así son todos los modelos y debemos recordarlo, para muchos casos, la mayoría yo diría, no existe un modelo absolutamente correcto y todos dejan algo fuera. Todos son arbitrarios y si alguien de nuestro equipo tiene una visión diferente, deberíamos escucharla, tratar de entenderla y ver cómo podemos integrar ambas visiones en un solo modelo.
Tus representaciones, tus modelos, no son la realidad, por lo que siempre pueden mejorarse. Además de que confiar en un modelo como en una guía perfecta te puede llevar a cometer errores graves. Es por eso que es bueno recordar siempre, que los modelos (los mapas) son representaciones imperfectas de la realidad (el territorio), y que algunos son más convenientes que otros para diferentes acciones o situaciones, además de que no existe EL MODELO correcto para cierta situación.
Si aplicas este modelo mental a los mismos modelos mentales, verás por qué necesitas una variedad de ellos para poder pensar mejor.
El ganador se lo lleva todo
Hay procesos en el mundo, de hecho, muchos, en los que los “premios” (puedes pensar en ellos como las recompensas o beneficios de una actividad) no se distribuyen uniformemente, sino que las ganancias se acumulan en un sólo lugar, para que unos pocos se lleven la mayoría de los beneficios.
En la actualidad, muchos procesos se comportan así, pero además se exacerba con la tecnología digital, en la que los ganadores de procesos como por la creación de contenido. Para aplicar este modelo, debes aprender a ver quién se lleva la mayoría de los beneficios.
Este modelo aplicado al software se puede ver en la puesta en marcha de las aplicaciones, pero de forma inversa. A diferencia de lo que puede pasar en otras industrias, un proyecto a medio terminar provee un valor casi nulo. Yo me atrevería a decir que un proyecto de software que no esté en producción, vale cero. Así que, siempre esfuérzate por entregar el software o ponerlo en manos de tus usuarios lo más pronto posible.
La falacia del costo hundido
Todos hemos enfrentado esta pregunta: ¿sigo invirtiendo tiempo y esfuerzo en este proyecto que no está dando resultados? ¿Hasta cuando debo seguir invirtiendo en este proyecto?
A veces llegamos a la conclusión de que lo mejor sería dejar de invertir en ese proyecto YA MISMO, pero algo nos detiene: el tiempo y esfuerzo que ya hemos invertido. Esto es el costo hundido. Los seres humanos tenemos naturalmente más aversión por perder algo, que deseos de ganar más cosas.
Pensar que lo que ya invertimos lo vamos a perder si dejamos algo que no nos ha dado resultados (y no tiene pinta de que los vaya a dar) nos detiene de tomar decisiones que son muy claras: si no hubiéramos invertido ese tiempo y esfuerzo, no tendríamos razones para seguir invirtiendo en este proyecto o aunque sea para mantenerlo. O sea que una inversión pasada, en vez de producirnos beneficios, nos está produciendo pérdidas, por el puro temor a perderla.
Este modelo mental se puede aplicar a los proyectos de desarrollo de software que después de cambiar de estrategia muchas veces no han dado rendimientos. Además como desarrolladores a veces estamos orgullosos de la arquitectura o los logros técnicos de cierto sistema o cierta parte del código, pero ha llegado el momento de reemplazarla por algo que se adecúe mejor a las necesidades actuales.
Recuerda que el esfuerzo o tiempo que ya invertiste nunca es una razón suficiente para mantener algo, sobre todo si hay razones para tomar otro camino.
Rendimientos decrecientes
Hay muchos procesos en la vida cotidiana en los que observamos que “mientras más, mejor”. Como máquinas de generalización que somos, tendemos a extender este pensamiento a todas las cosas en la vida, pero muchas cosas, no se comportan así.
De eso trata la ley de rendimientos decrecientes, te hace entender que no siempre más es mejor. De hecho, en la mayoría de los procesos naturales se cumple una ley:
Por cada unidad añadida, el rendimiento de la siguiente unidad va a disminuir.
Así es: hay muchas cosas en la naturaleza que mientras más tienes de ellas, cada cosa que añades te va a dar menos beneficios que la cosa anterior que añadiste. Algunos ejemplos empíricos:
-
Hacer ejercicio es muy bueno, si haces por lo menos 1 hora 4 veces a la semana ejercicio de cierto tipo te vas a sentir muy bien (claro combinado con otros factores como la buena alimentación). Pero si haces el doble de ejercicio, no te vas a sentir el doble de bien, de hecho si llegas a cierto punto, como hacer 3 horas diarias te vas a sentir excesivamente cansado y puede que con el tiempo tu cuerpo muestre señales de fatiga.
-
Si estás en un restaurante y pides un postre, el primero te va a saber muy bien, pero si pides otro, el segundo no te va a saber tan bien como el primero, y si pides otro, puede que te enfermes y termines odiando ese postre específico.
-
Cuando riegas una planta, echarle agua es bueno hasta cierto punto, si le echas demasiada, la planta se va a ahogar y se va a morir.
-
Salir al sol está bien, es bueno para nuestra salud si lo haces a la hora correcta y cuidas la cantidad de sol a la que te expones. Pero si te expones demasiado, te vas a quemar y vas a tener problemas de salud.
-
El dinero: tener dinero es bueno hasta cierto punto, pero a partir de cierta cantidad (que a mi parecer depende de el lugar en el que vivas), que si la superas 1) no te va a hacer más feliz, 2) te meterá en problemas que no tenías antes. La siguiente gráfica muestra la relación entre estos bienes y la felicidad:
En estos ejemplos hablamos de cosas buenas que primero te van dando cada vez menos beneficios, y luego se pueden volver perjudiciales. Para aplicarlo al desarrollo de software piensa en los siguientes ejemplos:
-
Equipos: Un equipo bien balanceado es necesario para hacer proyectos serios, pero eso no significa que mientras más grande el equipo, mejor. Cada persona agregada al proyecto va agregando menos valor que la anterior y muy rápido se llega al punto en el que una persona más añadida daña la productividad del equipo.
-
Horas de trabajo: A (casi) todos nos gusta nuestro trabajo y para lograr nuestros objetivos, en general, debemos de ponerle bastantes horas. Sin embargo, si trabajamos demasiado en un corto espacio de tiempo van a pasar dos cosas progresivamente: 1) Cada hora de trabajo sin que te distraigas va a rendir menos y 2) si sigues trabajando a pesar de esto, vas a cometer errores que después te puede costar mucho tiempo arreglar, o incluso cometer errores que no puedas arreglar, catastróficos (por ejemplo: un DELETE sin WHERE).
-
Abstracción: En el desarrollo de software, la abstracción es una herramienta esencial y siempre se necesita de ella para crear buen software. Pero si abstraes demasiado, tu código se vuelve inmantenible y muy difícil de entender. Igual que con otras cosas, el punto de retornos negativos de la abstracción es muy fácil de alcanzar.
-
Pruebas unitarias: Las pruebas unitarias son una gran herramienta tanto para asegurar la calidad del software como para ayudar en su diseño. Sin embargo, hay una tendencia a querer buscar que todo tu código esté cubierto por pruebas unitarias: tener 100% de cobertura. Este es un caso muy característico de rendimientos decrecientes: mientras más pruebas unitarias tengas, cada prueba unitaria que agregues va a darte menos beneficios que la anterior, pero se pone peor. Intentar tener 100% de pruebas te lleva a hacer código que mucho más complejo y difícil de mantener.
Para mi, este es uno de los modelos mentales más útiles, debido a que estamos en un mundo en el que ser eficiente en recursos te puede dar una gran ventaja competitiva.
Recursos para seguir aprendiendo sobre modelos mentales
Los siguientes libros y blogs(todos en inglés) te pueden enseñar mucho más de modelos mentales y su aplicación:
- Farnam Street: Blog y sus libros sobre modelos mentales.
- Super Thinking: The Big Book of Mental Models
- The Model Thinker: What You Need to Know to Make Data Work for You
- Un medio más reciente es el canal de Vicky Zhao en YouTube que además de hablar de modelos mentales, también habla de cómo usarlos para comunicarte claramente.
Conclusión
Los modelos mentales son herramientas para organizar la información que son muy útiles para personas que trabajan principalmente pensando y analizando el mundo real. Los desarrolladores de software pertenecemos a ese grupo, así que aprender a modelar la realidad de forma más efectiva puede darnos una gran ventaja para resolver problemas y así avanzar más rápido en nuestra carrera.
Seguiremos creando más artículos hablando de esto, para darte herramientas que te permitan ser un mejor desarrollador de software y mejor profesional.
Comentar