Beneficios del libre albedrío en la construcción de software

Tengo varios colegas que trabajan (o trabajaron) en alguna que otra empresa de tecnología, donde una de las tantas “reglas” que hay es la utilización de un único lenguaje de programación para desarrollar software. Claro que existen ciertos escenarios donde no tenemos mucha elección; por ejemplo, cuando se debe agregar valor sobre un producto enlatado. Esa idea me llevó a pensar varias cosas que siento que son buenas para compartir.

Breve aclaración

Lejos estoy de decir que la existencia de dicha regla esté mal. Entonces, para empezar, voy a señalar algunos beneficios que considero que pueden llegar a existir:

• Homogeneidad: Todos trabajan con el mismo lenguaje, por lo tanto, cualquiera (seguramente) está capacitado para ayudar a otro.
• Expertise: Al trabajar todos sobre lo mismo, es muy fácil lograr un nivel de experiencia/especialización muy alto y conocer a fondo la herramienta.
• Velocidad: El uso de librerías (internas o externas) de uso común para atacar problemas conocidos/repetitivos.
• Startup: Es un contexto en el cual tiene sentido, por un tema de desarrollo de la organización.
• Costos: Al disminuir la cantidad de tecnologías, es más fácil y económico conseguir desarrolladores que tengan conocimientos más acotados.

El trabajo del ingeniero

Algo que siempre me gustó de ser ingeniero (y seguramente muchos compartan este mismo sentimiento, sin serlo o con carrera afín) es la responsabilidad de tener que tomar ciertas decisiones. En particular, la de “cómo resolver el problema”, donde ese “cómo” involucra la selección de la/s herramienta/s más adecuada/s, teniendo en cuenta el contexto; la búsqueda del camino más eficiente.

Es cierto que, de acuerdo con el problema a tratar, la elección entre un lenguaje u otro podría ser algo totalmente irrelevante. Sin embargo, si para el equipo, a la hora de solucionar un problema determinado, existe una herramienta mejor que la que se “debe” utilizar y no se es libre de utilizarla… ¿qué clase de ingenio estaríamos utilizando? Porque no creo que tener que complicar el contexto para implementar una solución sea algo muy inteligente.

El ingenio es, en forma resumida, la aplicación de conocimientos obtenidos. Y el conocimiento lo obtenemos a partir de explotar nuestra curiosidad. Por lo tanto, si pretendemos mejorar, si queremos que la calidad de nuestro código vaya mejorando en el tiempo, si queremos hacer que nuestra última aplicación/programa/solución sea mucho más robusta que la primera; entonces necesitamos de esa curiosidad para poder crecer.

Fomentar el aprendizaje

Si hay algo que nos caracteriza a la mayoría de los que trabajamos en el desarrollo de software, es el desafío de aprender algo nuevo. El hecho de tener el lugar y la posibilidad de aprender un nuevo lenguaje (o tecnología) es, además de una herramienta de motivación, una forma de desarrollarse y expandir los límites. Donde esto no solo quiere decir aprender a programar en dicho lenguaje y nada más, sino también entender sus características, fundamentos, y la utilización de las abstracciones que propone al plantear una solución. Me parece importante resaltar que el aprendizaje queda independientemente de la decisión de si la herramienta debe utilizarse o no. Durante el proceso de investigación, pueden aparecer un montón de variables. Incluso podríamos llegar a encontrar información explícita sobre algo que nunca nos habríamos preguntado sobre herramientas ya conocidas.

Paradigmas y lenguajes

Como docente de 2do año de facultad, enseño tres paradigmas de programación, cada uno en un lenguaje diferente. Es cierto que el lenguaje es una excusa. Es el móvil que nos da el marco necesario para poder transmitir los fundamentos de cada paradigma. Pero también es cierto que sin el lenguaje, sería mucho más difícil lograr que los estudiantes puedan entender y fijar esas ideas.

Durante el final de la materia se cuenta que independientemente del lenguaje que se use, uno puede adoptar y utilizar algunas formas de pensar de un lenguaje en otro, sin importar que tengan como base distinto paradigma (es cierto que existen algunos límites). Claro que esto último es posible una vez que se asimilaron los conceptos… Y para ello es necesario haberse cruzado con el lenguaje que los tiene. Por ejemplo, podemos pensar en un modelo que analiza y toma ciertas decisiones (o informa ciertos datos), a partir del procesamiento de reglas, sin necesidad de estar trabajando en algún lenguaje puro del paradigma lógico. De la misma forma, podríamos tener un mismo wrapper genérico, para poder generar un pipeline transparente a lo largo de las distintas invocaciones que se realizan en nuestro código, y no estar en un lenguaje con características funcionales. Y así, podemos mencionar varios ejemplos más…

Evitar la moda

Existe también un error fácil de cometer, que es la adopción de un lenguaje de programación solo por ser novedad o “moda”. ¡Evitemos el hype!

Construir una pieza de software guiada por estos parámetros puede llevar a varios problemas futuros de mantenimiento, escalabilidad y monitoreo, entre otros.

Por eso, la adopción de un lenguaje nuevo dentro de un equipo de trabajo debe estar bien fundamentada. Debemos ser conscientes de que aprender algo nuevo lleva siempre un costo; una curva de aprendizaje en la cual se debe invertir tiempo y esfuerzo, que podría llevarnos a postergar un proyecto.

Además, no solo se debe ser consciente de las diferentes capacidades de los profesionales que integran el equipo; debemos agregar el impacto en la organización y en un montón de otros equipos que tienen responsabilidades transversales.
Ante estos escenarios recomiendo tener cerca este artículo.

Una última reflexión

Cuando necesitamos guardar información, no siempre usamos una base de datos relacional. ¿Por qué? Porque seleccionamos la base de datos que mejor nos ayude a resolver nuestro problema.

De la misma forma, no está bien (salvando las excepciones) que uno esté limitado a un único lenguaje de programación. Es similar (pero no idéntico) que obliguemos a un carpintero a trabajar con un conjunto reducido de herramientas. El hecho de optar por una nueva herramienta no siempre quiere decir que la anterior no sirva, pero sí que la propuesta sea más adecuada a nuestro escenario actual.

Lo primero que hay que tener en cuenta es que cuando elegimos adoptar una nueva tecnología (y muchas veces cuando no lo hacemos también), debemos ser totalmente conscientes y responsables de la decisión que estamos tomando; queramos o no, generamos un impacto dentro del equipo y organización. El contexto del proyecto a abordar también es relevante:

• ¿Cuán crítico es?
• ¿Tengo el tiempo para adoptar la nueva tecnología?
• ¿Es limitante la tecnología para el proyecto?
• ¿Es viable hacer el MVP en la tecnología conocida y luego pagar el precio de migrar?
• ¿Cuál es el trade-off entre una tecnología y la otra? ¿Cómo impacta en el proyecto?

Estas son algunas de las preguntas que podríamos hacernos para ayudarnos a decidir el mejor camino.

Realizar una selección de la mejor herramienta para un proyecto que está afectado por múltiples factores, no es una tarea sencilla. Pero esa parte no la vamos a abordar por el momento.

Tampoco hay que dejar de lado que aprender está en la naturaleza del ser humano. Tomar un desafío, poder superarse, asumir nuevas responsabilidades, adquirir nuevo conocimiento: todas tienen un valor que excede al económico y que necesitamos; por lo tanto, cumplen el papel de herramientas de motivación para el equipo.