Todo desarrollador de software sabe que hay que ser pragmático a la hora de llevar a cabo su tarea, no hay que desaprovechar tiempo ni recursos en solucionar el problema que está encima de la mesa. La cuestión viene en definir qué es ser pragmático, ya que el término está, por desgracia, totalmente desvirtuado.
¿Qué es el pragmatismo?
Según Wikipedia, el pragmatismo es una corriente de pensamiento que se basa en que sólo es verdadero aquello que funciona. Esta definición es muy genérica, y cuando aplicamos este concepto al software es donde empiezan las interpretaciones. ¿Si yo solamente he trabajado con una tecnología de hace 10 años, y sé que ésta da resultados, estoy siendo pragmático? NO. El pragmatismo no dice que no haya que renovarse, sino todo lo contrario. Dice que hay que utilizar aquella técnica que está probado con hechos que funciona. Aquí es donde la falta de historia en el desarrollo de software puede causar confusión, ya que no hay un procedimiento a seguir en el que para el problema A tengamos que aplicar la solución B y, para complicarlo más, continuamente aparecen nuevas tecnologías y procesos de desarrollo que hacen obsoletos los anteriores.
Volviendo al ejemplo de la tecnología de hace 10 años ¿Y porque no utilizar esa tecnología que me funciona? Porque como hemos dicho, yo sólo conozco esa tecnología. Esto significa que no sé si el resto aportan mejores soluciones a mi problema y no puedo contrastar si con ellas podría ahorrar tiempo de desarrollo, recursos, o mejorar la experiencia del usuario. En este caso como mucho podemos considerar que estamos siendo prácticos, o peor aún, cómodos.
El entorno. Los matices de lo pragmático
Está claro que la consideración de lo pragmático es influenciada por el entorno en el que el software es desarrollado. Dependiendo del tiempo y recursos disponibles hacer chapuzas puede llegar a considerarse ser pragmático. Pero nada más lejos de la realidad. Con el tiempo, todos los desarrolladores de software ven que la etapa que más coste tiene en cualquier proyecto es el mantenimiento. Es cierto que si el proyecto tiene un elevado riesgo, el coste y tiempo de desarrollo no deben ser elevados para el inversor. Pero eso no es excusa para ser profesional a la hora de implementar el producto.
En éste y cualquier otro caso ser pragmático es poner sobre una balanza todas estas variables y encontrar el buen camino para llevar el proyecto adelante. Por poner un ejemplo, tenemos una idea nueva que queremos implementar lo más pronto posible. Si de verdad somos pragmáticos, definiremos qué queremos hacer y empezaremos a trabajar al mismo tiempo en el producto. Se utilizarían herramientas y metodologías de programación que facilitaran el cambio a largo plazo (patrones de diseño, despliegue sencillo, librerías de alto nivel, testing, …) y alguna stack tecnológica ligera como PHP, Node.js o Python.
A parte de las necesidades del mercado, la motivación es clave a la hora de evitar lo que podríamos llamar ser prácticos o sacar las cosas mal pero pronto. Si un desarrollador no está motivado, no le va a importar hacer una chapuza para terminar el proyecto para ayer. Y por desgracia a él le va a parecer que está siendo pragmático. Lo que no sabe aquel que ha contratado al desarrollador es que está hipotecando su software, y que será difícil mantener esa falta de profesionalidad, lo que probablemente desemboque en el futuro en un castillo de naipes inmantenible.
Calidad y bajo coste en mantenimiento.
Entonces, ¿es posible lanzar un proyecto con poco coste de lanzamiento y poco coste de mantenimiento? Sí, sólo hace falta ser pragmático, pero de verdad. Y esto probablemente solo se pueda conseguir con la experiencia, la formación y la colaboración del cliente para identificar cuales son las necesidades, sentando las bases para que el proyecto crezca con las necesidades y retos del mercado.
La incorporación de requisitos en forma de historias de usuario y la implicación de los interesados en el proceso serán cruciales para mantener el proyecto vivo. Aquí el uso de patrones de diseño (¿recordáis lo de que sólo es verdadero aquello que funciona?), que no son más que soluciones de diseño de software probadas en distintos ámbitos, cobran vital importancia. Para empaparse de buenas prácticas existen también las consideradas como obras referencia, como el libro sobre patrones Gang of Four, el libro The Pragmatic Programmer u otras obras como Clean Code ofrecen conocimientos de grandes profesionales del sector sobre los cuales construir software sólido de manera pragmática.
Vale, pero esto parece muy complicado.
Puede parecer mucho trabajo y muy complicado, y en cierto modo lo es. Nadie dijo que desarrollar software fuera fácil. Aún así, como primer paso, solamente el hecho de preguntarse en el trabajo a diario, ¿esto que estoy haciendo lo podría hacer mejor?, o mejor aún, ¿podría evitar tener que hacer esto? pueden ejercitar nuestro yo pragmático e ir abriendo nuestra mente hacia una mejor manera de desarrollar software.
Con estos primeros pasos, es más fácil encontrar las fuerzas para documentarse en referencias u aprender nuevas herramientas que nos permitan conseguir productos mejores y más mantenibles. Y con este objetivo, con el fin de ahorrar costes y conseguir productos mejores es porqué hay que ser pragmáticos.