Estamos creando proyectos frankenstein

La informática ha evolucionado mucho en los últimos años, pasando de ser un hobby de unas pocas personas, a un sector profesional cada día más importante en los países desarrollados. Sin embargo, ¿estamos haciendo mejor software ahora que antes?, este debate es el que os propongo hoy, entorno a los proyectos frankenstein.

El origen de este artículo

Leyendo el interesante blog de Javi Santana y su artículo que os recomiendo especialmente: Algunos consejos para diseñar un API leí una frase que me marcó muchísimo y no era capaz de quitarme de la cabeza:

“Recuerda que ahora la gente no programa, busca el ejemplo más cercano a lo que necesitan y los modifican.”

Esta frase creo que resume de manera bastante adecuada el flujo de trabajo de la mayoría de los desarrollos actuales. Lo que nos lleva al software frankenstein.

Inicios del desarrollo y el código spaguetti

Como los más antiguos recordarán y otros conoceremos por libros y buenas series como Halt and Catch Fire, al principio los conocimientos de desarrollo se compartían por las siguientes vías:

• Revistas de desarrollo, tecnología o computación.
• Grupos de amigos que se juntaban
• Eventos y conferencias

Como se puede apreciar, según avanzó la informática, estas vías no eran escalables, cada vez había más que comunicar y los soportes eran limitados. Además, estos soportes solían tener cierto coste, que no todo el mundo se podía permitir.

En esta época, al programador de turno no le quedaba otra que leerse el manual de su magnífico equipo, los últimos artículos de las revistas de rigor y ponerse manos a la obra, a diseñar y crear software. El resultado medio, es el que todos conocemos como código spaguetti.

Si no conoces el concepto de código spaguetti, este hace referencia a un tipo de código donde todo está muy mezclado y es muy complejo seguir el hilo de ejecución del programa. Esto básicamente ocurría/ocurre porque no se separa las responsabilidades de los métodos, se abusa de condicionales, visibilidades compartidas y la utilización del malogrado goto.

Sin embargo, en esta primera época de la informática hacer cualquier cosa era complicado, ni tenían las herramientas que tenemos ahora, ni el conocimiento y la experiencia actual. Así que hay que reconocer que en aquella primera edad había gente con un nivel espectacular, que sentaron las bases de todo lo posterior.

Desarrollo actual y proyectos frankenstein

En contraposición a la primera etapa, actualmente sí contamos con buenas herramientas, equipos, experiencia, lenguajes para distintos propósitos y comunidades para compartir conocimiento como GitHub o StackOverflow. Aunque, paradójicamente, el código actual no parece que sea varios órdenes de magnitud mejor que el que se hacía en la primera época.

¿Qué es un proyecto frankenstein?

Como decía Javi Santana, sería aquél proyecto que se ha creado copiando y pegando código de distintos sitios, adaptándolo para cumplir los requisitos de la empresa y añadiendo algo de código pegamento, para que todo se mantenga. Estas son algunas maneras de detectarlo:

• El código no tiene una arquitectura o sigue múltiples al mismo tiempo
• No es posible ver dónde acaba una lógica y empieza otra
• Mucho código comentado, lo que suele demostrar que no usan bien un repositorio de código
• Está bien poblado de magic numbers, y otro tipo de valores hardcodeados
• Posee multitud de métodos, funciones, clases o bibliotecas de utilidades, que hacen de pegamento para adaptar el software
• No hay documentación, ni nadie sabe por qué se tomó una decisión

¿Por qué hay tantos proyectos frankenstein?

Viendo las características anteriores, seguramente te vengan a la mente multitud de proyectos que conoces que podrían ser catalogados como proyectos frankenstein. Esto lleva a preguntarnos, ¿por qué hay tantos?. La respuesta como siempre, es compleja y se debe más a una suma de factores que a una cuestión concreta, yo he identificado los siguientes:

• Crecimiento exponencial de las necesidad de desarrollo, lo que implica menos tiempo para cada proyecto, cargas de trabajo altas y menor oferta que demanda
• Personal responsable, cargos altos e intermedios, sin los conocimientos para liderar un proyecto
• Escasa preocupación por la calidad, aún sabiendo que los costes de mantenimiento son mucho mayores a los de desarrollo
• Aplicación de los principios: “Si funciona, no lo toques” o “…pero funciona”
• Falta de experiencia y profesionalidad en el equipo de desarrollo. Con una demanda tan alta de desarrolladores, al final no queda otra que contratar a perfiles con poca experiencia y un bagaje poco técnico, lo cuál no es malo, si no se les delega la toma de decisiones y no se les mentoriza adecuadamente.
• Equipos de trabajo que no funcionan

¿Cómo evitar una empresa de proyectos frankenstein?

Una de las formas más sencillas para detectar estos tipos de proyectos y huir de ellos, es ver cómo funciona la empresa y su equipo de desarrolladores. Para medirlo, una de las formas más comunes es utilizar el test de Joel, uno de los creadores de StackOverflow, que evalúa lo bien que trabaja un equipo. Para ello atiende a distintos factores como las herramientas que usan, la manera de afrontar los errores o las condiciones de trabajo.

Para cerrar este artículo, que espero cree debate, me gustaría recordar la cita con la comienza el famoso libro Clean Code:

“Writing clean code is what you must do in order to call yourself a profesional. There is no reasonable excuse for doing anything less than your best”

Un saludo.