La Reusabilidad en Crisis

 Por  qué cuesta tanto reusar piezas? En su momento le echábamos la culpa a los sistemas monolíticos, que no permitían despegar unidades funcionales en componentes ni capas. Pero hoy ya de esos sistemas, si bien quedan, hay pocos

Digo, hoy estamos casi todos en plataformas modernas, en Java EE y en .NET (como quizás algunos menos estuvieron también en Windows DNA). Hoy dividimos la lógica en objetos, agrupamos -a veces casi por inercia- los objetos en capas (layers) débilmente acopladas. Cada cambio de paradigma, de estilo de arquitectura (desde la perspectiva per solution de las 3 capas a la perspectiva estratégica de la orientación a servicios) vino motivado, entre otras cosas, por una maximización del reuso… como si los cambios anteriores no hubieran sido también por lo mismo

Y sin embargo la reusabilidad no sólo no está garantizada, sino que también es poca. Qué pasa? Será mentira? Será cierta en los papeles, pero incumplible en la práctica? Si descubriésemos que fuese incumplible… sirve de algo que exista si nunca la vamos a poder alcanzar?

Dediqué un tiempo a analizar en detalle, acordándome de los proyectos en los que trabajé, la cultura de las empresas en que participé de esos proyectos, sus equipos de trabajo…

En la siguiente figura vuelco las conclusiones de lo que, en general, veo que ocurre

En términos generales, la reusabilidad parece ir proporcionalmente a contramano de la cantidad de desarrolladores y aplicaciones. Veamos:

  • A nivel estratégico / empresarial, la reusabilidad es muy escasa o directamente nula. Me refiero a que el porcentaje de piezas que participan de más de tres aplicaciones de negocio diferentes están en el orden de un dígito (menos de un 10%, por arriesgar un número, por así decir, optimista)
  • La reusabilidad pasa a un orden medio cuando hablamos de pocas aplicaciones (digamos, alrededor de 2 o 3, máximo 5) y equipos reducidos de personas, con comunicación fluída y frecuente entre ellos -seguramente cuánta mayor la madurez de sus miembros, de su sentido de pertenencia al equipo, mayor consecuentemente la visión a largo plazo, que es imprescindible para "pensar" la reusabilidad como una premisa
  • Los niveles más altos de reusabilidad se dan a un nivel aislado, personal, y generalmente con un impacto acotado a una o dos aplicaciones. No llegan casi a alcanzar masa crítica. El principal beneficiado acá es el desarrollador que hace componentes reusables (reusables por él mismo) porque aumenta su productividad personal. A nivel corporativo eso es más discutible: puede pasar que cinco desarrolladores estén desarrollando -cada uno- una misma pieza, con la intención de reusarla luego. A nivel personal quizás reusaron, pero a nivel corporativo multiplicaron esfuerzos

Y cuáles serán las razones de que la distribución caiga así? Voy a enumerar las que me dan la impresión de aportar más al fracaso colectivo de la reusabilidad

  • Imprevisibilidad. Al momento de crear, o de decidir crear, un componente que esperamos vaya a ser reusado, alguien tiene la bola de cristal para tomar las decisiones de diseño necesarias que lo hagan "compatible con el futuro"? Personalmente me ha ocurrido que perdí, en más de una oportunidad, un tiempo valioso diseñando piezas para la eventualidad que se pudiera presentar… y fracasé doblemente: 1) esa oportunidad no se presentó. 2) en cambio sí se presentó otra algo diferente, que dejó inmediatamente a mi componente hecho una pieza de museo en extinción. Eduardo Mangarelli, mi ex jefe en Microsoft Cono Sur, llamaba a este vicio "genericidad excesiva"
    Una consecuencia indeseada de la Imprevisibilidad se da cuando el autor de la pieza quiere forzar situaciones de reuso. Esto es, empujar a otros a adoptar su componente "porque sí", cayendo en el absurdo de tener que adaptar el problema nuevo a la solución existente
  • Incomunicación. Acá queda en claro por qué el reuso es mayor en contextos acotados: el que va a desarrollar un nuevo componente, sale a anunciarlo a los cuatro vientos? Aún si lo hiciera… no creerá de veras que lo están escuchando, no? Consecuencia: el que necesita una nueva pieza puede esperar a enterarse si ya existe, dónde está, si le sirve tal como es y cómo se usa… o hacerse la suya propia de una y dejarse de joder
  • Documentacion escasa o nula. Desarrollar un componente medianamente complejo me lleva su tiempo. Si encima, quieren que lo haga reusable, me llevará algo más. No pretenderán además que lo documente, no? Ahora, si no se documenta, el que lo tenga que reusar cómo se entera si efectivamente es la pieza que está buscando? Ya sabía lo que ibas a decir: que vaya y mire el código fuente, no? Pierde un turno y vuelve al casillero anterior (Incomunicación)
  • Mecanismos de Búsqueda faltantes. Saber si el componente que necesitamos ya existe, veníamos diciendo que era complicado. Hasta ahora venía enunciando vicios de los equipos de desarrollo, pero tampoco la infraestructura ayuda. También la infraestructura se lleva su parte de la culpa. Alguna vez me comentaron que existía un proyecto de creación de Bases de Datos de Objetos. Es decir, no bases de datos relacionales: bases de datos a las cuales preguntarles "quiero un objeto que tenga un método que haga tal cosa", y la base de datos iba a contestar "sí, cómo no, su objeto se llama TeLoCreistePelandrun y fue creado a las 14 horas 23 minutos por el usuario tal". Claro, uno había estudiado Inteligencia Articificial en la facu, Sistemas Expertos, etc, y sonaba a que esas cosas se podían llegar a lograr. Y quizás alguien lo habrá logrado, el problema es que en tal caso nadie se enteró, como para reusar su solución (hablando de la Facu, te acordás cuando te decían que algún día las CPU iban a hablar Prolog o equivalente en forma nativa? (jojojojojojo…!!)
  • Presiones de Mercado. Si bien la reusabilidad es necesaria porque maximiza el ROI (Return Of Investement, o Retorno de la Inversión, variable que hace a la efectividad del área de TI), también hay otra variable que no se puede descuidar por la salud de la organización: el T2M (Time To Market, o Tiempo para Salir al Mercado). Si no podemos alinear la tecnología al negocio en tiempo y forma, ya lo decía en el post "Un Viejo Antipatrón: Demasiada Arquitectura", alguien más vendrá a hacerse cargo de la demanda del mercado. Esto no quiere decir "no hay que hacer componentes reusables". Simplemente evidencia que habrá que usar la cintura ahí, apostar a la reusabilidad pero, como en las apuestas del casino, saber hasta dónde arriesgar. En cualquier caso, habíamos hablado de vicios de los desarrolladores, después de las carencias de la infraestructura, y acá vemos ahora que el Negocio también dificulta planificar componentes mucho más allá de las necesidades del corto plazo

 

Conclusión

Personalmente creo que la reusabilidad sigue siendo posible, que la batalla por conquistarla continuará (y al respecto yo estoy lejos de bajar los brazos, aviso al que le interese), simplemente que -como tantos otros factores de éxito en TI- la Reusabilidad será un norte al que siempre tenderemos, siempre nos estaremos acercando más, aunque nunca terminemos de llegar completamente. Si te acordás de Análisis I o Álgebra, eso tenía un nombre: Asíntota

Las asíntotas eran funciones que en la medida en que la x tendía a infinito (o menos infinito, según), se iban aproximando a un eje tal que dado un intervalo ε (épsilon) de distancia entre la curva y el eje, existía un x0 tal que a partir de ese x0, la distancia entre f(x) y el eje caía dentro del intervalo (o lo que es lo mismo, la curva se había aproximaba más al eje). Sin embargo, por más que el ε iba a ser más chico cuanto mayor el x0 elegido, ε nunca iba a ser 0 (cero)
En este contexto, el eje de las x es el tiempo, el eje inalcanzable es la Reusabilidad Total, y f(x) la reusabilidad real alcanzada a lo largo del tiempo

En términos del negocio, la reusabilidad desde los componentes de una solución particular hacia el portfolio completo de aplicaciones empresariales es quimérico y, por lo que contábamos, supérfluo. Una estrategia exitosa debería partir en el sentido contrario: desde la arquitectura empresarial hacia las soluciones específicas

Es en ese contexto, donde la exposición de servicios (en oposición a exponer componentes) constituye un esquema más liviano (menos acoplado). Como contrapartida, consumir servicios distribuidos implica mayor latencia de red (probablemente no presente en el esquema de reusabilidad de componentes, donde un ensamblado o .dll se podía copiar en el directorio de más de una aplicación y se cargaba en el mismo proceso de la misma)

Definitivamente, la reusabilidad seguirá siendo posible pero habrá que seguir pagando por ella también  

Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

2 respuestas a La Reusabilidad en Crisis

  1. paulo dijo:

    Sabes Diego cuando te deje el comentario en el post sobre MVC te estaba por preguntar si había alguna estadística o estudio sobre la adopción de prácticas como separación por capas y reutilización de código, lo digo más que nada porque yo la forma más común de reutilización que he visto en muchos lados aplicada es el copy & paste,  al final me puse a hablar de Castle Project y me olvide.
    Yo como desarrollador independiente trato de reutilizar y maximizar en todo lo posible la escritura de código, porque sino el tiempo y los costos no me cierran,  igualmente salvo algunos módulos todo siempre necesita un retoque o porque optimizamos el código con una nueva técnica aprendida, o por que usamos alguna tecnologías más nueva, creo que el primer paso para facilitar la reutilización de código es comenzar a escribir código que pueda ser fácilmente mantenible y que este bien documentado, me ha pasado algunas veces cuando he tenido que trabajar con algo que ya comenzó otro,  que es tan inteligible lo que ha hecho, que al final termine haciendo todo de nuevo o una buena parte.
    Otro aspecto llamativo de tu post es la relación de personas involucras – reutilización de código, creo que es por esta razón que las metodologías agiles, están tomando mucho impulso, por que uno de los pilares de ellas es la comunicación de los miembros del equipo, y una reunión diaria de 15 minutos o anotar algo en una pizarra para que el grupo se entere, parece tonto y hasta muy simple, pero puede hacer la diferencia.

  2. Diego dijo:

    Good points, Paulo – Thnkx😉

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s