Una de las cosas a las que más atención presto cuando tengo que diseñar la arquitectura de una aplicación o plantear la industrialización de un desarrollo es el gestionar la capacidad de la gente. No todo el mundo tiene la misma capacidad de «coco», pero si que hay una cosa cierta, nadie la tiene infinita. Así que hay que pensar muy bien con que cosas quieres llenarla.
Normalmente, independientemente de la capacidad natural de cada persona, con el tiempo esa capacidad se va aumentando, porque ya vamos teniendo cimientos sobre los que asentar los nuevos conocimientos.
Como he comentado en alguna otra entrada, llevo en el mundillo del desarrollo de webs con Java, de cuando eran webs y no aplicaciones lo que se hacían. Así que he visto como se ha ido complicando todo. Todavía recuerdo en uno de los primeros proyectos de envergadura en los que participé como un compañero me decía, que para que me preocupaba tanto por el código, si no lo mira nadie. Hoy día casi todo el mundo tiene controles da calidad en el código.
Alguna vez comentando con compañeros de trabajo sobre estos temas, ponía de relieve que a los programadores se les empezaba a exigir saber de Java, JavaScript, Html, Bases de datos, etc y encima con auditoria de código, normas de base de datos, normas de usabilidad, etc, pero luego se les daba nada de tiempo para que hiciesen el mantenimiento en cuestión.
Así que siempre intento dejar las arquitecturas de las aplicaciones o las metodologías de trabajo lo más sencillas posibles. Recuerdo una presentación que vi en Internet de la arquitectura de Pinterest, en la que recomendaban justo esto mismo. Decían que mejor dejar la arquitectura lo más sencilla posible, porque siempre acabará fallando y cuando más sencilla sea más fácil será de arreglar. Explicaban la arquitectura que habían ido siguiendo ellos y como tuvieron que simplificarla.
Me ha sorprendido lo simple que es la arquitectura de desarrollo que se propone en el Google App Engine. No hay capas y más capas de servicios. Es todo mucho más plano.
Me he dado cuenta también de la cantidad de cosas que hacemos sin reflexionar, dejándonos llevar por lo que se hace en el mercado, sin ser un poco críticos con ello. Montamos arquitecturas aplicando mil patrones para dotarnos de una flexibilidad que luego en la mayor parte de las veces no usamos. Pero lo que si que encarecemos es la creación de las aplicaciones.
Recuerdo en una de las empresas en las que trabajé que se tenia una arquitectura de hacer las aplicaciones en las que se tardaba unos 5 días por mantenimiento, hasta que se marchó la persona que definía esas cosas y le pudimos meter mano. Aligeramos la arquitectura y se dejó cada mantenimiento en 4 días. Habíamos bajado un 25 % el tiempo de desarrollo en cada mantenimiento. Simplemente quitando flexibilidad que no servia para nada.