Voy a continuar aquí la serie "Introducción a los conceptos de Software Factory" que comencé en mi blog anterior con las entradas:
Me permito taer aquí un fragmento de un post anterior para definir el concepto:
<cita>
Software Factory Si se le hubiese llamado de otra manera nos habriamos visto forzados a realizar un esfuerzo mental para averiguar y tratar de entender de que se trata este concepto pero desgraciadamente esta palabrita "Factory" nos habilita a pensar cualquier cosa. Las analogías que encontramos por todos lados con fabricas de zapatos, electrodomésticos y autmóviles terminan de confirmar nuestras fantasias mal fundadas. No son pocos los que creen que se trata de hacer software como si de automoviles se tratara, simplemente ensamblando algunas partes hechas en una linea de montaje y automatizando, robots mediantes, los detalles como el color de la pintura y otros. Bueno, no es así. (sic)
Distingamos entre Software Factory como paradigma y como instancia. Como paradigma, es una alternativa a los métodos actuales de construcción que intenta resolver los 5 problemas planteados en el post anterior ([Software Factories] Introducción (Parte 1)) cuando las aplicaciones a construir comparten características comunes. Como instancia (SCSF por ejemplo), un Software Factory es un conjunto de herramientas, procesos tailorizados, frameworks, patrones y modelos (por lo general embebidos en los frameworks y/o herramientas integradas del IDE) y otros contenidos que usan para trabajar sobre una Linea de Productos.
</cita>
En esta entrada intentaré echar un poco de luz sobre software factory como paradigma sin caer en la definición de paradigma. Como paradigma, software factory es una manera distinta de pensar, analizar, diseñar, organizar, construir y gestionar el desarrollo de software con el propósito de sortear las 5 razones del fracaso de los proyectos de software en la actualidad:
- Razón 1 - One-off development
- Razón 2 - Monolithic systems and increasing systems complexity
- Razón 3 - Working at low levels of abstraction
- Razón 4 - Process immaturity
- Razón 5 - Rapidly growing demand for software systems
Desde este punto de vista, SF produce o mejor dicho propone, un cambio radical en la manera hacer las cosas. Que cosas? TODAS!
<opinion>
Puesto que todas las razones, salvo la razón 4 "Process immaturity", se producen en mayor o menor medida por un escazo nivel de reutilización de tangibles y que además se encuentran demasiadas analogías con industrias con foco en la "producción intensiva" y no en el "desarrollo intensivo", sumado a conceptos un poco futuristas como el de "Software Supply Chains" es que se cae en la creencia de que SF es solo reutilización de código en cualquiera de sus formas: fuentes y/o binarios como librerias, componentes, frameworks, application blocks, paquetes, assemblies, funciones traidas con copy/paste, ws o cualquier otra.
</opinion>
En cuanto al aspecto más cercano al código, este paradigma intenta cumplir con lo que la OOP nunca cumplió del todo: la reutilización!. Todavia me acuerdo de "las clases son totalmente reutilizables!!!" si claro, solo que son dependientes del contexto por lo que en realidad es el contexto lo realmente reutilizable por lo que se las agrupó en librerias, componentes, frameworks o llamense como quieran. Además de que solo aquellas que son de un uso muy genérico y muy granulares las que se pueden reutilizar en la actualidad, todavía sigo sin encontrar una clase factura, cliente, orden de pedido, reclamo y tantas otras que necesito para mis desarrollos que pueda reutilizar.
El encapsulamiento, la fina granularidad y muchos tipos de impedancias encontradas entre OOP y otros componentes también son atacados por este paradigma.
En cuanto al análisis, diseño, comunicación con los clientes y generación de código, SF toma lo mejor de MDA mientras que intenta solucionar mediante los reutilizables, DSLs y extensiones de los IDEs las falencias de CASE, acercando el análisis y el diseño a un contexto específico (determinado en gran medida por la linea de productos). No más diagramas genérico a validar por un cliente que no los termina de entender (a veces yo tampoco), ni más código genérico de mala calidad producido por herramientas CASE de terceros, basta de tanta libertad a los desarrolladores, basta de pensar y de hacer (de mil maneras distintas) todo de nuevo, desde los gráficos hasta el código.
En cuanto a la organización de los desarrolladores, o quizás de los conocimientos y habilidades, SF reconoce que no son todos iguales y distingue aquellos con mayor conocimiento técnico y del dominio del problema, quienes construyen los SF, de aquellos quienes lo utilizan y enriquecen con su feedback.
Por último en este artículo, vuelvo sobre las metodologías. Aquí también SF plantea una alternativa y me cito de nuevo:
<cita>
(sic) el tema de las metodologias cuyo problema resumia como "o (son) muy formales o (son) muy ágiles". Greenfield y Short plantean (lo que a muchos nos parece obvio) que existen dos tendencias extremas con sus pros y contras. A diferencia de lo que uno podría esperar, Greenfield y Short no creen que una metodología más formal sea más MADURA, por el contrario, entienden que son inmaduras por extremistas.
(sic)(sic)(sic)...(otros cuantos sic)...(sic)(sic)(sic)
La clave es preservar la agilidad mientras se mantiene la posibilidad de escalar la complejidad introducida por el tamaño y la distribución geográfica de los proyectos. Lo verdaderamente importantes es como esta posibilidad va tomando forma real mediante la implementación del paradigma de Software Factories.
Los autores siguen diciendo que el problema de las metodologias formales es que son demasiado abstractas en el sentido que para poder utilizarse deben ser tailorizadas a cada proyecto o necesidad particular. La idea detrás de esta crítica, que no lo es tal, es tailorizar los procesos a una familia de productos concreta.
Es decir, enfocar los procesos hacia las tareas puntuales de todo el ciclo de vida de una familia de productos (sic). Así, por ejemplo, debería por cada actividad facilitarse los recursos necesarios como wikis, links a documentación importante (sic), información de contactos, guias específicas (instructivos) sobre como realizar tarea, checklists aplicables a la tarea, estilos de codificación, detalles de cual/es es/son el/los próximo/s paso/s en el desarrollo, herramientas, políticas, (sic). Todo esto debería estar integrado al IDE y en lo posible automatizado.
</cita>
continuará.....
Lucas Ontivero
Nunca escribí sobre algo así y seguramente será la última vez que lo haga. Perdón a todos.
Este es un meta anti-patrón(?), el cual consiste en un intento por simplificar la realidad al extremo tratando de reducirla a conceptos matemáticos básicos. Este concepto tomado de la psicología, se presenta en todos los contextos de la vida pero aquí vamos a enfocarlo a las actividades de desarrollo de software. El pensamiento lineal es resultado del afán de tratar cuestiones o problemas complejos analizándolos sobre las bases de modelos sencillos en demasía y por lo tanto desprovistos de aspectos de importancia que en suma resultan determinantes.
Ante un problema complejo, el pensamiento lineal se enfoca en un aspecto determinado del problema, ya que los "detalles" han sido eliminados, probocando un análisis NO sistémico, aislando a la persona de un estudio y reflexión más completa que incluya el contexto en el que toma sus decisiones, haciendo de ellas decisiones aparentemente correctas y lógicas pero que al cabo terminan demostrando su inefectividad.
La dimensión de este problema toma su aspecto más negativo cuando se observa en sistemas sociales en donde el pensamiento lineal intenta homogeneizar a las personas para gestionarlas mediante técnicas de stock (un ejemplo, ver "El 'pool' de programadores" de Rodrigo Corral), valores de mercado, características, métricas, etc.
Citando a Jaime Yanes Guzmán en su artículo "La Trampa del pensamiento lineal":
"La trampa principal del pensamiento local radica en su efectividad operacional en la construcción del hacer, en su dinamismo en el fabricar, en su capacidad del diseño ingenieril. El pensamiento lineal es atractivo porque sólo pone atención a sus tremendas capacidades operacionales concretas, resaltando con ello la racionalidad causal local porque la ve como el único origen de la eficacia y efectividad del quehacer"
Aquí está, este es el contexto de nuestro meta anti-patrón(?). Este tipo de pensamiento, como todo antipatrón, promete resultados de manera sencilla con justificaciones matemáticas también simples lo que le confiere cierta lógica. Los pretextos son siempre los mismo, gestionar; y desde mi punto de vista, gestión facilista.
Citando ahora a Alfonso Cornejo Álvarez en su libro "Complejidad y Caos - Guía Para La Administración Del Siglo XXI"
"El Pensamiento lineal es otra de las variables que afectan a la toma de decisiones cotidiana en la organización. Cada evento o situación problemática es analizado de manera simplista y lineal, estableciendo para cada reacción una acción directa y bien identificable. Este modelo mental se permea a toda la organización y se traduce en análisis de situaciones que afectan a balances financieros, programación de producción, adquisición tecnológica, innovación de productos, evaluación de tendencias de mercado, etc. Desde el más simple hasta el mas complicado de los eventos que le toca vivir a la organización.
El modelo de causa-efecto de relación lineal cobra vida en cada inferencia provocada del análisis de lo cotidiano. Todo tiene su porqué y es plenamente identificable. Aunque este modelo de pensamiento no es atribuible al desarrollo de la burocracia, si ha favorecido el bajo desempeño organizacional y ha provocado efectos secundarios no previstos que maravillosamente se han disfrazado nuevamente de relaciones causales ante la mirada segura de los analistas."
Ahora, trantando de despegarnos un poco del duro trabajo que es "el arte de criticar" y, intentando alejarnos de los análisis mezquinos producto de "nuestro" pensamiento lineal, analicemos la situación concreta de las decisiones administrativas de nuestra industria. El problema: debemos gestionar y obtener resultados beneficiosos para todos. La posible solución es: usar los conceptos de la administración clásica, homogeneizar (abstracción) todo llevandolo a números y gestionarlo entonces por medio de cifras. La solución definitiva: (?)
Edwards Deming en su libro "Calidad, Productividad y Competitividad - La salida de la crisis", que puede verse como un compendio de ejemplos y soluciones a los problemas del pensamiento lineal en la industria en general, lista enfermedades mortales de la industria entre las que señala:
- Búsqueda de beneficios a corto plazo,
- Evaluación del comportamiento, calificación por méritos, o revisión anual. (a alguien le suena esto? porque fue escrito hace más de 25 años) y,
- Dirigir basándose en las cifras.
Luego habla de los obstáculos (cada punto son 100 páginas) y propone sus famosos 14 puntos para la transformación de las empresas los cuales en conjunto forman un sistema increible pero... hoy se ven implementaciones customizadas de sus 14 puntos con la misma lógica infantil del 2+2 y poco ha cambiado o se a transformado en realidad (salvo los ISO 9001 y CMMI ooohhhh somos Deming compliance!!).
Entonces, no es posible escaparle al pensamiento lineal? a lo mejor una persona pueda pero un sistema social no, una organización no puede simplemente porque es resultado de factores educativos/cognitivos que han logrado resultados. Entonces el pensamiento lineal resulta, a falta de opciones, una herramienta impresindible para la administración. Sencillamente, así se administra(?).
Nota: el (?) significa duda. No afirmo que se trate de un antipatrón, solo lo planteo como posible.
Lucas Ontivero
Bueno, esta es una entrada para paresentarme y saludarlos a todos. Mi nombre es Lucas como dice arriba y como la mayoria de ustedes comencé con esta profesión/hobbie/pasión desde muy chico, la semana pasada mi hermanito me preguntó: que hacias con usa porqueria con cassette que se conectaba al tele? y la verdad es que hacía lo mismo que ahora, me divierto.
Quiero también decirles que me siento muy feliz de formar parte de esta comunidad ya que desde hace bastante que sigo a varios miembros como a Rodrigo Corral por sus experiencias, El Bruno (uno de los que más leo aunque un poco rápido) y al que le he robado el formato de los títulos, Rafael Ontivero (no somos parientes) me encanta ese blog, Carlos Zanini, Jorge Serrano, Ezequiel Jadib, Mariano Converti y otros.
Mi blog anterior era http://lucasontivero.spaces.live.com para quienes quieran ver más o menos que es lo que escribo. En este momento estoy de luna de miel, y me pude escapar 10 minutos de mi señora para escribir esta entrada :) , así que voy a estar un ratito más sin escribir.
Ahora sí, un saludo a todos.
Lucas Ontivero