Arquitectos, desarrolladores y escoger la tecnología adecuada

Repasando los artículos que tenía pendientes de leer en InfoQ, me he encontrado con este: Ideal Architecture is not always about Ideal Technology or Techniques. En el, se referencia a un post de Phillip Calçado en el que reclama que los arquitectos no deben ser tan egoistas y han de tener en cuenta las habilidades del equipo de desarrollo a la hora de escoger la tecnología para una aplicación.

Pone un caso como ejemplo:

Imagine you join a team of long time VB6 programmers to develop a new website. No one has experience with Ruby on Rails although you know that is exactly the best tool for the job. The website must be delivered in a short time frame, no time for training. Would you go for the best technical choice?

El problema del artículo y de lo que ponen en InfoQ, en mi humilde opinión, es que la cuestión no es tan fácil. No es algo tan sencillo como se pinta en esta historia en la que el punto central son los desarrolladores. Hay muchos otros factores como el coste de desarrollo, el coste operacional, la disponibilidad de herramientas, todos los requisitos no funcionales del proyecto (léase escalabilidad, extensibilidad, fiabilidad, tolerancia a fallos, etc.), la disponibilidad de soporte comercial, la facilidad para obtener documentación y soluciones a problemas, o la esperanza de vida de la tecnología por citar algunos. No es algo tan sencillo como coger a tus desarrolladores y decirles: "Bueno chicos, necesitamos consenso. ¿Vosotros en qué queréis programar?"

Por poner un ejemplo muy sencillo, en el hilo de lo que propone, si tengo unos desarrolladores que dominan la tecnología X, de poco me va a valer esto, si dicha tecnología entra en End Of Life el año que viene. Si tengo escoger entre una tecnología X (e.g. VB6) que todos mis desarrolladores dominan, y una tecnología Y (e.g. Rails) que sé que aporta muchísimas más ventajas en cuanto a requisitos no funcionales, que promete un desarrollo mucho más rápido una vez superada la curva de aprendizaje, que tiene una comunidad vibrante, que hay montón de documentación que afronta problemas actuales, etc. Pues lo siento, yo escojo Y.

Por otra parte, la elección de una tecnología no debe ser algo que se base únicamente en los gustos del arquitecto de turno. Efectivamente, el equipo de desarrollo se debe tener muy en cuenta también en la elección. Las skills disponibles son muy importantes, y más importante aún es el saber aprovecharlas al máximo. Por eso una de las cosas importantes al contratar gente es conseguir crear un equipo multidisciplinar. A mi de nada me sirve tener a 10 expertos en VB6. Prefiero tener 2 expertos en VB6, 2 en bases de datos, 2 en Java, 2 en Python, y 2 en aplicaciones web. Pero como he comentado anteriormente, en mi opinión esto es uno de los factores de la ecuación.

Un equipo de desarrollo multidisciplinar es mucho más moldeable a los cambios. Y para bien o para mal (yo creo que para bien), nuestra profesión está condenada al cambio constante. Es nuestro sino. Las tecnologías aparecen y desaparecen cada vez más rápido y de nada sirve el decir, "no es que todos mis desarrolladores sólo dominan esta tecnología de hace diez años y entonces sólo podemos desarrollar en esto", porque eso es seguir un muy mal camino.

Pero por esto es importante el rodearse de un gran equipo. Si por el contrario de lo que disponemos es de un puñado de personas a las que no les interesa la tecnología si no más bien el marcharse a casa cada tarde a ver la televisión, o que simplemente quieren seguir trabajando en lo que han hecho siempre porque no les interesa aprender nada nuevo. Bien, fair enough, como se dice por aquí; pues en este caso habrá que ser realistas y probablemente un proyecto actual no se ajuste a las posibilidades de este equipo de desarrollo en concreto.

En lo que estoy de acuerdo completamente con él es en que no hay que escoger una tecnología simplemente porque sea nueva, o porque sea lo más cool del momento. Estas tecnologías, tienen su espacio dentro de una empresa también, pero yo siempre las dejaría para pruebas de concepto, que de ser exitosas podrían materializarse en proyectos reales.

Photo: rutty@flickr