El provocador título de este post no es mio, sino de un artículo aparecido en Java Code Geeks que ha despertado cierto debate en algunos de los blogs que sigo habitualmente.

En mi opinión, lo que expone el artículo origina es un poco exagerado, aunque no le falta parte de razón. Hay gente que se siente inclinada a no pensar, a no profundizar en el porqué de las cosas. Esto se manifiesta especialmente cuando usa un framework que, mágicamente, hace que las cosas funcionen. Además, se produce un efecto muy negativo que es el intentar resolver todo en términos del framework que están utilizando, cuando a veces no es la mejor solución.

¿Esto convierte al desarrollador en más tonto? Yo creo que no. Realmente potencia algo que ya era antes. Cómodo. Descuidado. Superficial. No sé, llámeselo como quiera, pero realmente no es que lo convierta en ello el uso el framework, sino que, como mucho, lo acentúa.

Sin embargo, el uso de frameworks tiene sus ventajas. Por una parte, permite encorsetar al desarrollador menos espabilado dentro de una arquitectura más o menos lógica, lo que puede facilitar la incorporación de gente con distinto nivel de preparación a un mismo proyecto. (Vale, que sea interesante contar con gente de ese perfil es discutible, pero eso lo dejamos para otro post).

Por otro lado, si el framework está mínimamente bien diseñado permite reducir enormemente la cantidad de código que hay que escibir para realizar tareas básicas. Además, si está realmente bien diseñado cuenta con puntos de extensibilidad donde se puede ampliar/personalizar para adecuarlo a nuestras necesidades, o incluso salirnos de él para recurrir a soluciones de bajo nivel. Estoy pensando, por ejemplo, en NHibernate, que permite extender el comportamiento como hemos visto en anteriores posts de este blog y que además permite saltarse todo y acabar accediendo a un IDbConnection para usar ADO.NET a pelo si es necesario.

En cualquier caso, si alguien pretende mejorar como desarrollador necesita no sólo conocer las herramientas que tiene a su alcance (lenguajes, IDEs, frameworks, librerías, etc.), sino que además debe comprenderlas, entendiendo sus puntos fuertes y débiles, con el fin de saber cuándo y hasta qué punto usarlas.

Como dice Davy Brion:

Like it or not, memory management matters. The cost of complex database operations (leaving in the middle whether you’re using an RDBMS or a NoSQL solution) or the frequency of them matters. Bandwidth matters. Remote calls matter.

Te guste o no, la gestión de memoria importa. El coste de operaciones complejas con bases de datos (independientemente de si estás usando una base de datos relacional o una solución NoSQL) y la frecuencia de la mismas importa. El ancho de banda importa. Las llamadas remotas importan.

Aunque las herramientas existentes muchas veces hagan que podamos abstraernos de cosas tan de bajo nivel como las que menciona Davy, eso no quiere decir que podamos olvidarnos por completo de ellas. Una cosa es no tener que manipular los flags de un paquete TCP para establecer una comunicación con un servidor web, y otra muy distinta que tengamos en cuenta el coste de hacer una llamada a un servidor web situado en la otra punta del planeta.

Al final, la clave es lo mismo de siempre. Pensar un poco y aplicar el sentido común. Lástima que eso no sea nada fácil.