2013-01-23

Profundizando sobre la idea de fábrica en software

software-factory_0Tiempo atrás escribí sobre El concepto de fábrica aplicado a servicios. Allí mencionaba algunas contradicciones en su uso. Aquí pretendo profundizar, un poco más, usando como eje el software [1].

Primero debo decir que estoy de acuerdo que la metáfora de fábrica sirve para discutir ciertos conceptos relacionados con la construcción de software. No obstante, creo que en muchos casos se la fuerza demasiado.

Fábrica física

Simplificando en extremo, el eje de la revolución industrial fue la mecanización de una serie de tareas que hasta ese momento se hacían en forma manual. Esto permitía mayor producción con menor nivel de error y mediante mano de obra más barata. 

La idea de fábrica además siempre ha involucrado dos conceptos fundamentales: la producción en serie (es decir el mismo producto fabricado una y otra vez) y la producción en cadena (la idea de fabricar el producto en etapas y enfocar a los trabajadores en una etapa con el objetivo de lograr la máxima eficiencia posible).

En software (o servicios)

Cuando hablamos de software la cosa se complica pues se hace difícil aplicar los 3 conceptos antes mencionados: mecanización de tareas manuales, producción en serie y trabajo en cadena. Veamos:

  • Mecanizar tareas manuales. El software, en muchos sentidos, sigue siendo una tarea manual y artesanal. Knuth así lo pensaba (The art of computer programming) y Brooks también (No silver bullets). Hay diferencias de productividad, hay diferentes enfoques para lograr el mismo software, hay distintos niveles de calidad con los que se puede producir una pieza de software, ...
  • Algo parecido pasa con la idea de producción en serie. En las fábricas de software no se produce el mismo software una y otra vez. En todo caso se mantiene el mismo software una y otra vez. Es como si el producto nunca estuviera terminado y siempre necesitara cambios. Sí, es cierto que la actividad del programador es siempre la misma: programar. Pero esa simplificación es tan peligrosa como decir que las actividades de un obrero textil y uno automotriz son iguales porque ambos "construyen" o "fabrican". Un programador que trabaja sobre el mismo programa, del mismo módulo y del mismo software, una y otra vez no necesariamente repite las acciones. Más bien todo lo contrario.
  • Por último, lo que sí es posible extrapolar de las fábricas físicas es la idea de trabajo en cadena. Uno de los pilares conceptuales alrededor de las fábricas de software es metodología estándar [2], división en etapas y next operation as a customer. Esto sí puede ser extrapolado y es, en definitiva, lo que se busca explotar: repetir el mismo proceso nos permite hacer las tareas más eficientemente y especializar a algunos miembros del equipo en determinadas tareas.

¿Qué otras similitudes o diferencias encuentran a la hora de aplicar el concepto de fábrica al software? Y si generalizamos a servicios, ¿qué opinarían?

Seguimos pensando..

[1] Creo que las ideas del post pueden generalizarse a servicios también sin mayores dificultades.

[2] Antes de que algún "extremista ágil" lo pregunte, estoy incluyendo dentro de metodología estándar el uso de metodologías ágiles :-o

2 comentarios:

  1. Personalmente veo una diferencia que me parece sustancial y es la siguiente:

    Cuando hablamos de fábrica como referencia para este tema, pensamos en operarios en una línea de montaje operando sobre un componente del producto a manufacturar, sobre el cual agregan otras partes (fabricadas previamente), o realizan acciones, pero en ambos casos normalmente son situaciones muy atómicas (sin gran variación posible entre una y otra).

    En el caso del software, si se establece la equivalencia en cuestión, el operario sería el desarrollador, pero a diferencia del caso anterior, cualquier acción que este deba realizar, provendrá de su intelecto. Dos desarrolladores escribirán muy probablemente distinto código para resolver la misma situación, y -si se quiere- es la parte expresiva de la profesión, su momento de creatividad y de arte.
    Más aún, el *mismo* desarrollador difícilmente escriba la *misma* línea de código en dos "manufacturas" distintas.

    Esa variabilidad, por más que se reutilice código, siempre será mucho mayor que en el caso de una fábrica física (multipliquemos por LOCs "nuevas" de un desarrollo), y por tanto hace mucho más impredecible (e irrepetible) el resultado que en una línea de montaje.

    ResponderEliminar
    Respuestas
    1. Gracias por el comentario Ariel.

      Comparto lo que decís, es un poco lo que mencionaba en el primer punto. Al ser tareas manuales dependemos "del arte" de quien las hace y como no hay suficiente estructura y todo depende del "operario", ahí tenemos un problema.

      Saludos,

      Eliminar

Muchas gracias por comentar. Por favor deja tu nombre y/o email, los comentarios son mucho más valiosos cuando se sabe quien los hace.