El problema del martillo de oro.

Un martillo es una cosa maravillosa, es fácil de manejar, ergonómico, y transportable, maximiza mi eficiencia y minimiza mi esfuerzo. ¡No debiera tener problemas en cambiar esta rueda pinchada a martillazo!

Es frecuente que tengamos herramientas, tecnologías o lenguajes de programación, que parecen idóneos para resolver las necesidades de construcción de un software, a veces parecen incluso idóneos para resolver cualquier problema. Pero sin darnos cuenta habitualmente moldeamos nuestros requerimientos para que se ajusten a nuestra herramienta, y no estamos buscando herramientas que se ajustes a nuestros requerimientos, lo cual limita el alcance y las posibilidades de nuestra solución. Es necesario usar la herramienta adecuada, para resolver cada problema, no podemos quitar un tornillo a martillazos.

El ciclo de vida de estos "martillos" es generalmente el siguiente:

1. Se propone usar el martillo, ya sea por una orden gerencial, estratégica, porque ya se compro o por decisión del programador.
2. El algún momento se ensalza tanto el martillo, que se convierte en un estándar, y en la herramienta que todo el equipo (o la empresa), debe usar para resolver sus problemas.
3. El "martillo" causa "desastres", como errores, mal código (o código poco comprensible), retrasos, y diversas frustraciones en el equipo (junto con horas extras y desencanto en los proyectos).
4. Se desecha el martillo, bajándolo de su pedestal y se busca un nuevo martillo.

En todo este ciclo, posiblemente se desaprovecho una buena herramienta, usándola en circunstancia en donde no era idónea. Con lo que al final de su "ciclo", se explotaron todas sus desventajas y ninguna de sus ventajas.

Algunos martillos tradicionales son:

• Todo debe estar en un procedimiento almacenado: Los procedimientos almacenados se convierte prácticamente en todo el sistema, y ellos tiene toda la lógica de nuestro negocio. Usando este martillo, tendremos un sistema difícil de mantener, cuyo diseño se base prácticamente en cómo se almacenan los datos (y no en lo que esos datos representan), y con limitaciones, como falta de programación orientada a objetos, que generalmente no ofrecen los gestores de base de datos, finalmente a ser la base de datos un elemento centralizado, se complica la implementación de un sistema por equipos, incluyendo el uso de herramientas de control de versiones.
• Todo debe estar en un servicio: Se crea todo un sistema como una serie de llamadas a un servicio (puede ser un servicio web). Básicamente todas las funciones de nuestro sistema están imprentadas como métodos de un servicio, Se pierde el diseño de un software orientado a objetos, y generalmente se construye un software lento.
• Todo debe ser accesible por un ORM: Toda las consultas a base de datos son a través de un ORM, no importa qué tipo de consulta, ni cuales sean las necesidades, generalmente caemos en este caso en software lento.
• Construir el software en C (o C++) porque es rápido: Aquí habría que plantearse, primero, si es cierto eso sea tan rápido, y si dicha rapidez compensa en el uso de dichos lenguajes, cuya curva de aprendiza en mayor, y no cuidan mucho que no hagamos locuras al momento de usarlos (como por ejemplo Java y C#, donde se nos protege de usos indebidos de la memoria).
• Programar en el blog de notas (o similares): Esto es querer hacerlo todo a mano perdiendo la cantidad de posibilidades que nos facilita IDE, como depuración, sintaxis coloreada, o IntelliSense.

La idea final es usar la herramienta adecuada en cada momento y necesidad, no casarnos con una sola tecnología, metodología o lenguaje de programación y poder de extraer lo mejor de cada una.