martes, febrero 26, 2008

Arquitectos, desarrolladores y escoger la tecnología adecuada

martes, febrero 26, 2008 por Martín


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

comments

2 Respuestas a "Arquitectos, desarrolladores y escoger la tecnología adecuada"
Phillip Calçado dijo...
11:29

If you read my blog post you will see that actually what I promote is taking developers (and the de team as a whole) in account, and not basing the whole decision -taken by the architect, team lead or whoever- on them. I agree with your comment and don't see how it contradicts what I said.

Sorry about commenting in English. I can sort of understand Spanish since I'm a native Portuguese speaker (I'm Brazilian) tough I'm not sure that Portuguese would be understandable at all (Portuguese is an exception-driven language, you know...).


Martín dijo...
13:51

Hi Phillip.

Thanks for your comment (portuguese would be ok for me but probably not for many readers).

I think your post can be misunderstood. If that was the case, sorry about that, but the title and examples you use can lead to confusion then.

The point I make is basically that if you have a bunch of developers behind the times, that does not mean that your new projects must be. So sometimes an Architect either must make the sole decision of adopting a brand-new technology knowing that his developers won't be comfortable with it, or just simply drop the project and accept that he does not have the appropriate people for it. I would never start a project in an inappropriate technology just because that is the only thing my team would be comfortable with.

So, I completely agree with your point that people is important, but just accepting the fact that there are sometimes that you have to make difficult decisions.