Reutilización de código como máxima de un ISV
Al hilo de los excelentes comentarios que Rodrigo hace en su blog, hoy me he acordado de algunas de las cosas que he vivido, meditado, sufrido y discutido en no pocas ocasiones, todas ellas, referente al mundo de la informática y desarrollo de Software, y en concreto con la reutilización de código en los ISV (Independent Software Vendor).
Hace ya un tiempo, se me ocurrió recopilar mis porciones de código y las típicas respuestas que se daban en foros de discusión para reutilizar rutinas de código en diferentes situaciones. Eran pequeñitas porciones o ideas de código que ayudaban en tareas muy repetitivas. Eso es justamente lo que hace Visual Studio 2005 con su code snippets o recortes de código. Pero aquí, quiero comentar algo más. Darle un giro de tuerca más a la situación.
Cito como ejemplo, que observando el día a día de una de las empresas en las que trabajé, me fijaba que una y otra vez se hacían tareas repetitivas a la hora de desarrollar Software, y en concreto, diferentes equipos trabajando en diferentes proyectos, escribían sus propias rutinas que muchas veces hacían lo mismo o prácticamente lo mismo. El resumen de esto es que en dos proyectos (Proyecto A y Proyecto B) independientes de Software dentro de una misma empresa, la conexión entre proyectos independientes es casi siempre inexistente. De hecho, cuando un jefe de proyecto se ponía en contacto con otro jefe de proyecto y hablaban sobre sus respectivos proyectos, muchas veces salía la frase o comentario del tipo "nosotros hacemos algo similar" o "eso mismo lo hice yo en otro proyecto hace unos meses". En resumidas cuentas, si los dos equipos pudieran de alguna manera trabajar juntos o compartir recursos, experiencias, necesidades y buscar sinergias, sería posible encontrar una productividad muy alta, acortar los tiempos de desarrollo, los riesgos y los costes. A esto le llamo yo flujo interno de la información del desarrollo del Software. El flujo de la información desde mi punto de vista, debe ser constante (reuniones de seguimiento), fluida (buscando mecanismos para que eso se lleve a cabo de una forma rápida y sencilla) y asíncrona (la información debería fluir en las dos direcciones).
Bien, esta explicación generalista, nos lleva a su vez a pensar que en cada proyecto, cada equipo puede y suele trabajar con cierta anarquía a la hora de escribir código. Es decir, cada uno puede escribir la documentación, variables, rutinas, etc., con una nomenclatura y formato determinado. Evidentemente, trabajando todos con los mismos patrones, el hecho de compartir código y rutinas aporta que el equipo de trabajo en el Proyecto A escriba su documentación, código, etc., en una nomenclatura y formato, que el equipo del Proyecto B entienda a la perfección porque están habituados a trabajar de esa manera también. Es más, si en cualquier momento, una persona de un proyecto, entrara en otro por cualquier motivo, el tiempo de aclimatación es mínimo, y si esa persona fuera nueva en el departamento o empresa, cualquier persona de los equipos de desarrollo, podría aleccionarla respecto a la forma y modo de trabajar, por lo que su rendimiento sería el máximo en el menor tiempo posible.
Es decir, ya estoy poniendo sobre la mesa dos características. La primera tiene que ver con la información general y el hecho de compartir código, documentación entre proyectos. La segunda tiene que ver con la nomenclatura y forma de escribir y elaborar todo.
Ahora bien, entrando en el detalle de lo que tiene que ver con el código, y sabiendo que indirectamente la información siempre está por encima de todo y se toca inevitablemente, ¿cómo compartir el código entre proyectos?. Porque claro, la complejidad aquí es indicar cómo se puede reutilizar el código.
Evidentemente, la empresa tiene que sacrificar uno o más recursos encargados de abrir los canales de comunicación entre proyectos, aglutinar esa información, y generar un Framework propio con las aportaciones de los equipos y que sirva para todos los equipos de trabajo. Ese código debe pasar los controles de calidad de la empresa y finalmente elaborar la documentación y versiones correspondientes de sus librerías. Ahora bien, a mi modo de ver, esto que parece sencillo, debe realizarlo una persona que se dedique en la empresa a este trabajo pero de forma exclusiva. Inicialmente la carga de trabajo será grande y posteriormente, será menor a priori, aunque es inevitable que el Framework siga creciendo, manteniéndose y modificándose, para lo cuál necesita que la persona o personas designadas a ello lo sean en exclusiva. Esto desde el punto de vista de costes, puede estar no justificado en un primer momento, pero para mí esta idea se acerca más a la idea de I+D que a la propia idea de Framework, y como sabemos, los costes en I+D cuesta mucho justificarlos porque inicialmente no recoge resultados, y en el caso de mi país, España, el I+D está casi mal visto y considerado una pérdida de tiempo. Otro error de concepto tal y como yo lo veo.
Lo mejor de crear un Framework interno para una empresa ISV, es que por un lado se puede vender el Framework externamente recogiendo frutos o beneficios de los costes y tiempo dedicados a ello, o bien, pueden reutilizar estas librerías con nuevos proyectos reduciendo los tiempos y costes de desarrollo y haciendo que la diferencia entre coste y beneficio sea mayor, es decir, que la empresa gane dinero.
¿Comentarios?.
One Responseso far
Sin duda comparto tu visión de que es necesario establecer canales de comunicación que eviten la repetición y dispersen el conocimiento.
Lo que no creo es que haya que establecer formalmente estos canales, sino crear el entorno que favorezca la existencia de ‘electrónes libres’, como les llaman en Peopleware, este tipo de desarrolladores que además de hacer su trabajo son capaces de colaborar en otros proyectos compartiendo ideas. Desarrolladores que conocen otros proyectos además del ‘suyo’ y que por tanto favorecen la reutilización. Desarroladores que son capaces de compartir sus conocimientos, que colaboran en foros internos o externos, que escriben blogs.
Lo del Framework es sobre el papel una gran idea, pero suele ser dificil hacerlo sin acotar mucho el dominio de la aplicaciones desarrollables con el y aun así es dificil acertar a la primera y no reinventar la rueda. Gernelmente los Framework muy especificos de un dominio tienen escaso valor para terceras empresas y los que son generalistas, aportan poco sobre el propio Framework.
Otro cantar son las herramientas DSL que pueden añadir valor para dominios expecificos o amplios sin abandonar un framework común, el propio Framework general de la tecnología.