Adopción de Tecnología

Ayer escribía sobre el Ruby Meetup de Buenos Aires, y describí que había gente de la comunidad a la que no le gustaba Rails, el framework y herramientas de desarrollo de sitios web más popular de Ruby. En la lista RubySur, ayer se disparó el hilo

Rails, sucks?

donde apareció, ante la pregunta: que es más popular? rails, cuba o sinatra ? la respuesta: “Rails. Las masas siguen a las masas. Las masas no son muy inteligentes tampoco.” Escribí en ese lista, en dos emails, que discrepo con esa respuesta. Pueden leer todo el contexto y posiciones alternativas en ese hilo. Acá, en este post, quisiera pasar en limpio algo que muchas veces comento pero veo que no escribí en detalle y como tema principal.

Primero, el tema me interesa, porque he visto aparecer, desde hace dos décadas, argumentos como ése: la tecnología X se adopta sin pensar, sin conocimiento, y para usar la expresión de arriba, “siendo masa”. Me refiero acá a tecnología de programación (desde lenguajes, IDEs, sistemas operativos de soporte, frameworks, herramientas, editores, etc…) y podría extenderlo a TI en general. Pero acoto por ahora, a temas de desarrollo de software. He visto aparecer argumentos y explicaciones similares a la de “la masa” en otras listas, por ejemplo, en listas de Smalltalk o de COBOL o de Linux. Sigo sin ver que sea ése el caso. Salgo de mi cubil, me fijo, y sigo sin ver que sea así. Insisto: me refiero a decisiones de desarrolladores y aledaños.

He estado repasando más de treinta años en mi vida de ser desarrollador, y no he podido encontrar el caso de “masa (de desarrolladores) elige tecnología X”. Porque no he visto, encontrado, el caso “masa”. Siempre lo que veo, son individuos que eligen. Veo a Juan estudiante, viendo qué lenguaje de programación más le gusta o interesa. Veo a José viendo cuáles son las tecnologías que tienen más salida laboral, porque su profesión es el desarrollo, y eligiendo entonces. Veo a Ana, gerente de una compañía, decidiendo si importa o no la tecnología a usar en el próximo desarrollo de la intranet de la empresa, sopesando disponibilidad de gente con conocimiento en las tecnologías, costo de implementación (en tiempo y dinero), costo de mantenimiento, y posibilidades de expansión en nuevas versiones. Veo a Diego y María eligiendo qué usar para su próximo emprendimiento de “social media” + “semantic web”.

Aun en los tiempos pre-web (y con escasa Internet en Argentina), la gente tenía varias opciones para elegir, y decidía de forma individual, no como “masa”. Por supuesto que las empresas que producen tecnología (y más en los ochenta, donde esa producción estaba más concentrada) ejecutaba todas las acciones de mercadeo y promoción, pero nunca ví que la elección de herramientas y tecnologías se volviera algo como el ámbito de la música, donde podemos discutir si “la masa sigue a la masa”. Realmente no lo ví y no lo veo.

Es claro que las decisiones se toman en un contexto (“tengo que trabajar y lo que piden es Java”), y se toman con conocimiento parcial (“adopto Rails, veo que tiene una comunidad activa pero no sabía que había otros frameworks”). Pero ese conocimiento parcial se aplica individualmente, no por actuar como “masa”. Si hay conocimiento parcial, y hay poco conocimiento de la tecnología Y, y pensamos que esa tecnología es interesante, debemos difundirla. Casi de cada cosa que encuentro interesante, termino escribiendo un post, o por lo menos, dando una lista de enlaces en mi delicious o enviando enlace en mi twitter. Pero veo, por ejemplo en el ámbito Smalltalk, que los que no lo adoptan y “dicen programar en objetos” en otras tecnologías, son parte de “la gilada” (no sé si se entiende, “gil” en Argentina sería algo así como “tonto” en español “neutro”). Esa actitud no corresponde con la realidad (no veo que alguien que no use Smalltalk y use .NET o Java, sea “tontos” o no hayan aplicado su inteligencia para haberlos elegido). Y adoptarla, disminuye la posibilidad de entender cómo cambiar la realidad: cualquier fracaso en la adopción de Smalltalk se refugiará en ese argumento, “ves, la gilada no lo entiende”.

El tema que discuto, no es tanto el uso de conocimiento parcial, intuición y demás, que se entienda o no algo, sino el modelo propuesto de “la masa sigue a la masa”. No veo “masa” en la historia del desarrollo de software.

Entonces, ¿cuál es el modelo que podemos proponer, para explicar la adopción de tecnología X? Bueno, no hay un modelo simple (otro argumento en contra de “masa sigue a la masa”). Cada individuo elige en su contexto, intereses y capacidades. Pero puedo proponer el modelo de varios individuos, digamos Pedro tiene que elegir tecnología:

- No tiene todo el tiempo para analizar y elegir la mejor opción

- Tambien puede ser lo bastante inteligente para decir: "Aunque analice, mi conclusion no es segura"

- Decide que es mejor seguir un camino donde hay una comunidad activa

- Con eso cumple con el time to market

- Elige X, que tiene una comunidad activa, con paquetes (gemas, módulos, etc…) y mucha gente que la conoce

- Claro, X técnicamente no es perfecto, hay otras opciones, pero no las elige

- Cuando crece, tiene muchos desarrolladores que conocen X

- Y con eso se forma una empresa y se compra una casa en un barrio privado :-)

Luego, otros tendrán otros modelos. Por ejemplo, alguien en ese hilo de RubySur, explicó que su consultora programaba muchas veces en Rails para que el cliente final tuviera un producto que muchos desarrolladores de la comunidad Rails pudieran mantener y extender. El cliente final así elige en contexto: para él, lo importante no es la excelencia técnica del producto final (“mirá, tal otro framework es más desacoplado, aplica MVP de forma más pura, etc… “), sino que cumpla con su función y pueda ser soportado en el futuro sin tener que contratar gente de la NASA. ¿Es parte de “la gilada”? No, es parte de su trabajo ese tipo de elecciones.

Un ejemplo que ví hace unos años: un sistema en Smalltalk, con Gemstone, hermosamente armado, muy dúctil. Pero cuando el tiempo pasó, y se le pidió más funcionalidad, prácticamente no había gente suficiente a un costo adecuado para extenderlo a tiempo. Y tampoco se podía consumir fácilmente sus datos desde otras tecnologías. Al lado de ese sistema, en tecnologías más difundidas, había otros que fueron creciendo y pasaron a ser el “core” de soporte de decisiones de la empresa.

Otro modelo es el de Francisco, gerente de TI:

- Tiene que elegir tecnología para resolver problema A

- Tiene opciones X, Y (y tal vez desconozca otras, como Z, W que son técnicamente mejores)

- Y le parece buena, y hasta mejor que X

- Pero tiene como proveedores a 20 consultoras que conocen X, en la última reunión de CIOs se comentó que el proveedor principal de Y no cumple con los tiempos, hay un grupo de usuarios activo de X

- Elige X

¿Es parte de “la gilada”? El sentarse con otros CIOs y compartir experiencias, ¿lo hace parte de la masa? No lo veo.

Y así puedo seguir enumerando modelos, cada uno servirá de explicación aproximada a la forma de adopción de X por el conjunto de individuos {A}. Lo que no veo es un conjunto “gilada” o conjunto “masa”.

Veamos, para ir cerrando, un modelo propuesto de adopción de tecnología (ahora paso a tecnología en sentido amplio, más allá de programación). Lo encontré hace más de 15 años en el libro Crossing the Chasm de Geoffrey Moore, modelo que se puede discutir, pero es interesante para sumarlo a esta exposición. Ahí se propone que hay:

the technology adoption lifecycle where five main segments are recognized; innovators, early adopters, early majority, late majority and laggards. According to Moore, the marketer should focus on one group of customers at a time, using each group as a base for marketing to the next group. The most difficult step is making the transition between visionaries (early adopters) and pragmatists (early majority). This is the chasm that he refers to. If a successful firm can create a bandwagon effect in which enough momentum builds, then the product becomes a de facto standard.

Vean que en los tiempos de Moore, ni se pensaba que podría haber tecnología creada fuera de una empresa (como Hibernate o Linux por ejemplo). Lo que ha traído la Web (antes también Internet, pero hay que reconocer que la Web fue disparador) es la formación de comunidades que soportan tecnologías. Hay innovators, como Rick Hickey con Clojure, o Ryan Dahl con Node.js; hay early adopters, que los acompañan en los primeros tiempos, y luego, hay un “cruzar el abismo”, donde se ve si la tecnología llega a formar parte del “mainstream” de opciones. Vean que Moore menciona “pragmatists (early majority)”. Por más “cool” que se vean Clojure, Node.js, Rails, Agile, Hadoop o tecnología X, sólo “explotan” cuando terminan dando resultados a gente pragmática, que con ellos puede conseguir objetivos: desarrollar un sistema real en uso, armar un emprendimiento, construir un nuevo producto.

Vean un tema nuevo que aparece en estos años: la formación de comunidad. Una tecnología X puede no ser la mejor solución, pero puede tener una comunidad activa, que produce ejemplos, documentación, herramientas. Notablemente, en tecnologías X que pueden extenderse por partes de terceros. Eso le da una vuelta de tuerca al concepto de comunidad: son las gems de Ruby, los módulos de Node.js, y los paquetes de NuGet. Mucha gente adopta tecnología X porque soluciona sus problemas. Y en esa decisión pesa mucho el tener una comunidad a la que recurrir, en casos de trabarse en algo. Y vean cómo ha influido Internet/Web en la formación de comunidades, tal vez en detrimento de grupos de usuarios locales y localizados.

Bueno, espero que lo que quise explicar haya quedado clarito como huevo de tero. Por supuesto, acepto otras posiciones, pero van a tener que convencerme. Por ahora, dejo este post como evidencia de mi postura.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 3463. Bookmark the permalink.

One Response to Adopción de Tecnología

  1. Bueno, discusiones sobre que lenguaje es mejor ha habido siempre. Que Pascal es para estudiantes, que Visual Basic sigue siendo Basic, que si no programás de cero en ASM no sos programador, ets, etc, etc.
    Como en todo, definir cual es la mejor herramienta es algo muy subjetivo. Lo mejor es lo que mas beneficio nos de respecto de sus costos (tiempo de aprendizaje, facilidad para encontrar programadores, costo de componentes, etc) en un determinado momento. Ni siquiera es una decisión inmutable.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>