Categoría: Arquitectura & DevSecOps

Una vez un jefazo que tuve comentó (no literalmente) en una reunión que un jefe de proyecto debía de gestionar el proyecto desde la atalaya, no pegado al barro de la máquina.

Creo que el arquitecto de software debe tener un planteamiento similar. Por una serie de motivos:

Todologo

Es prácticamente imposible en un proyecto un poco grande el que una única persona conozca al detalle todas las herramientas y tecnologías como para poder ayudar a un programador. De algunas si que podrás ayudar a un programador, porque en tu carrera te hayas tenido que pelear con ella. Pero de otras no.

Un arquitecto tiene que lidiar tanto con el desarrollo puro con todas sus herramientas, que si JSF, que si JPA, que si,…. También con las bases de datos, con la gente de sistemas, para la arquitectura de las máquinas, de las comunicaciones, etc

Como dice la sabiduría popular: «el que mucho abarca, aprieta poco».

Por eso creo que un arquitecto debe tener la siguiente actitud:

Coordinador

Por eso es importante que la persona que lleve la arquitectura sea alguien con un perfil de coordinación. Que tenga un equipo de trabajo con diferentes especialistas.

Si te pegas mucho al barro pierdes la visión de la globalidad del proyecto y acabas corriendo el riesgo de dar soluciones parciales y lo que arreglas en un apartado lo estropeas en otro. O también corres el riesgo de dar soluciones poco elaboradas, que se acaban volviendo en contra del proyecto.

En el libro sobre Expreme Programing se hacia referencia a un cuadro de mandos en el que se ponía todos los mandos al máximo y el sistema era estable, porque una técnica se compensaba con la otra.

Esta es la labor del arquitecto, ver la globalidad y hacerlo estable. Por ejemplo, tengo MySQL y como tiene ciertas carencias lo tengo que diseñar con un sharding y eso me provoca ciertos problemas que puedo solucionar con una caché transversal. Esa visión transversal es la que debe tener un arquitecto. No tanto el ponerse a instalar el caché o a optimizar el JSF.

Sino los de sistemas acaban viendo solo los problemas de sistemas y los de desarrollo solo los de desarrollo y eso no es bueno. Es el planteamiento tradicional que se intenta superar con planteamientos de DevOps.

No caer en las tentaciones

A mi, a pesar de venir de la rama de desarrollo, me gusta el tema de sistemas, más como hobby que profesionalmente. Tengo mi nube casera y cosas similares.

A veces es muy tentador cuando te encuentras con cosas de sistemas, por ejemplo, que no van bien, remangarte y hacerlas tu. Pero ese no es el trabajo del arquitecto. En todo caso si es el hacer que la gente de sistemas haga las cosas bien. Lo mismo pasa con temas de desarrollo. Si por ejemplo un código no pasa la auditoria de código. Es muy tentador el adecuarlo tu.

El problema no es lo que puedas hacer sino lo que dejas de hacer. He conocido a más de un jefe de proyecto que venia de la rama técnica y que ayudaba mucho a los programadores cuando no sabían hacer cosas. El problema es que descuidaban sus verdaderas responsabilidades. Y que un programador no lo haga muy bien, es delicado, pero que no lo haga bien un jefe de proyecto lo es mucho más.

Uno de los proyectos personales que he realizado ha sido ISValidator. Fue a finales del año 2001, así que ha llovido mucho desde entonces.

Mi intención era muy simple. En todas las aplicaciones típicas CRUD lo primero que realizas es coger los datos y validarlos. Así que me propuse hacer una librería para ello. Le dediqué mucho tiempo a pensarla, ha hacer algo modular, etc. No la típica situación «quick and dirty» que suele haber en los proyectos.

No me quedó mal, pero por decirlo de alguna manera me empecé a emocionar y a contemplar más casuísticas. Así que se fue complicando todo, hasta un punto en el que casi yo mismo me perdía en el código.

También es cierto que por aquel entonces era un programador.

Para lo que si me sirvió es para aprender algunas cosas.

• Los componentes tienen que estar muy bien pensados para que sean buenos, y a veces aun a pesar de estar muy pensados no son del todo buenos. Se necesitan personas con muchos conocimientos de diseño.
• Un componente no es un código con muchos parámetros, que es lo que suele pasar cuando se hacen las cosas con prisas.
• Hay que ser humilde y no pretender abarcar mucho, ya que puede que si abarcas demasiado acabes generando un monstruo que no controles.

Recuerdo una empresa en la que trabajé en la que tenían desarrollado un framework para hacer las cosas más rápidas, habían invertido mucho tiempo, pero por ejemplo para hacer un simple combo había que tocar en 7 sitios. ¡7 sitios! . Si era super flexible, flexibilidad que dudo mucho que nunca se llegase a usar, pero lo que si era cierto es que costaba un huevo y parte del otro sacar adelante cualquier mantenimiento.

Llevo bastantes entradas hablando de la industrialización del desarrollo de software, pero en ninguna de ellas he dicho que es para mí, aunque algo ya se habrá ido adivinando, sobre todo cuando lo contrapongo a la artesanía.

Cuando estás en un proyecto pequeño, de una o dos personas, con unos requisitos bajos, normalmente se funciona como un artesano. Es decir, te ocupas de todo y es tu valía personal y tu calidad la que se ve reflejado en el producto que vendes. Esto es así tanto si haces una figurita como si haces un programa.

Cuando los proyectos son más grandes, de decenas de personas, esta forma de trabajar en la que cada uno hace las cosas según su criterio ya no sirve. Básicamente porque tu trabajo es una parte de un todo y el resultado final ya no va a depender tanto de tu valía personal y tu calidad, como cuando trabajas como un artesano, sino que aparte de esto va a depender de lo bien afinado que esté todo el equipo.

He comprobado en mis propias carnes que por muy bueno que tengas a uno en un equipo, si el resto no está a la altura el proyecto no marcha bien. Es como si una maquinaria de un reloj tuvieses una pieza muy buena, pero el resto no. El reloj no marchará bien. Tampoco lo hará si las piezas son buenas, pero no están bien ajustadas. También se suele utilizar el símil de la orquesta.

Por eso habréis podido comprobar que la mayor parte de las entradas referidas a la industrialización del desarrollo del software están dedicadas a las personas. Para mi es lo más importante, el poner más o menos herramientas lo único que hace es facilitar o mecanizar las cosas.

Para mi la industrialización del desarrollo de software es la definición de que es lo que pasa, es decir los procedimientos y herramientas asociadas, desde que una petición llega del cliente hasta que esa petición se pone en producción (o se descarta).

Entran multitud de elementos, desde la captura de requisitos, la asignación de tareas, planificación, desarrollo, verificación, traspaso, etc. Va muy en la línea de lo que serían la ISO 9000 y el CMMI, por citar algunas normativas.

Hay gente que considera la industrialización del desarrollo de software como la aplicación de herramientas estilo MDA (model drive arquitecture). Para mi esto no es industrialización del desarrollo, es automatización del desarrollo. Es decir es tener la super churrera, que te genera, ya no un trozo de programa, sino el programa completo. No digo que la automatización sea algo malo, solo que para mi son conceptos diferentes.

Empece en esto del desarrollo de webs con Java, cuando no había más que los servlets. Luego vino los JSP, los EJB, el Struts, etc.

Es curioso cuando ves que en una comparativa en la que uno de los «frameworks» que más rendimiento tiene son los simples servlets.

Como comenté en otra entrada, quizá debiéramos de plantearnos el simplificar las cosas.

También me ha llamado mucho la atención la simplicidad en el servidor de los planteamiento del GAE