El Mítico Hombre-Mes (The Mythical Man-Month) capítulo 4 en español

¡Hola! Ya que muchos me han pedido seguir con la traducción del libro The Mythical Man-Month: Essays on Software Engineering, me he dado el tiempo y he avanzado con la traducción del Capítulo 4. Sin más blah-blah, aquí les va.

NOTA: En este capítulo se habla mucho de implementador, considérenlo en la actualidad como el rol de un desarrollador (.Net, Java, Mobile, PHP, u otro).

The Mythical Man-Month : Essays on Software Engineering.

Capítulo 4: Aristocracia, Democracia y Diseño de Sistemas

Esta gran iglesia es una obra de arte incomparable. No existe confusión ni ambigüedad en los principios que establece.
Es el cenit de un estilo, el trabajo de artistas que entendieron y asimilaron todos los éxitos de sus predecesores, en plena posesión de las técnicas de su tiempo, pero fueron usados sin exhibición indiscreta ni hazañas gratuitas de habilidad.
Jean d'Orbais fue sin duda quien concibió el plan general del edificio, un plan que fue respetado, al menos en sus elementos esenciales, por sus sucesores. Esto es una de las razones de la extrema coherencia y unidad que posee la estructura.

Guía de la Catedral de Reims

Fotografía de Emmanuel Boudot-Lamotte

Integridad conceptual

La mayoría de las catedrales europeas muestran diferencias en el plan o el estilo arquitectónico si hablamos de piezas construidas en diferentes generaciones por diferentes constructores. Los constructores posteriores fueron tentados a "mejorar" los diseños de los primeros, para reflejar tanto los cambios en la moda como las diferencias en su gusto individual. Así, la pacífica arquitectura normanda contradice al estilo gótico, y el resultado proclama tanto la soberbia de los constructores como la gloria de Dios.

Frente a éstos, la unidad arquitectónica de Reims se encuentra en el glorioso contraste. La alegría que despierta al espectador proviene tanto de la integridad del diseño como de cualquier otra excelencia en particular. Como dice la guía, esta integridad se logró con la abnegación de ocho generaciones de constructores, cada uno de los cuales sacrificó algunas de sus ideas para que el conjunto pudiera tener un único diseño. El resultado proclama no sólo la gloria de Dios, sino también SU poder para salvar a los hombres orgullosos.

Ahora si hablamos de los sistemas de programación, a pesar de que no han tardado siglos en construirse, reflejan una desunión conceptual mucho peor que la de las catedrales. Por lo general, esto no surge de una sucesión en serie de diseñadores maestros con "diferente mano", sino de la separación del diseño con las muchas tareas hechas por muchos hombres diferentes.
Afirmaré que la integridad conceptual es la consideración más importante en el diseño de sistemas. Es mejor que un sistema omita ciertas características y mejoras anómalas, con tal que refleje un conjunto de ideas de diseño, a tener una que contenga muchas ideas buenas pero independientes y no coordinadas.

En este capítulo y en los dos siguientes, examinaremos las consecuencias de este tema en la programación de un diseño de sistema:

• ¿Cómo se puede lograr la integridad conceptual?
• ¿No implica esto tener una élite o aristocracia de arquitectos y por otro lado una horda de ejecutores plebeyos cuyos talentos creativos e ideas son suprimidas?
• ¿Cómo se mantiene a los arquitectos a la deriva en el mar de especificaciones imposibles de implementar o que son muy costosas?
• ¿Cómo se asegura que cada detalle insignificante de una especificación de arquitectura se comunique al ejecutor, correctamente entendido por este, y que se incorpore con precisión en el producto final?

Lograr la integridad conceptual

El propósito final de un sistema de programación es hacer que una computadora sea fácil de usar (para el punto de vista del usuario). Para ello, proporciona lenguajes y diversos servicios que en realidad son programas invocados y controlados por características del lenguaje.
Pero estos servicios tienen un precio: las descripciones externas de un sistema de programación es de diez a veinte veces mayor que la descripción externa de ese mismo sistema de computación. El usuario encuentra muy fácil especificar alguna nueva función en particular, pero hay mucho más para elegir, y muchas más opciones y formatos que se deben recordar.
La facilidad de uso se mejora sólo si el tiempo ganado en la especificación funcional es mayor al tiempo perdido en el aprendizaje, en el recordar algo y el uso de manuales. Con los sistemas de programación modernos esta ganancia supera el costo de que el usuario aprenda más, pero en los últimos años parece haber disminuido la proporción entre la ganancia y el costo de aprender por parte del usuario (Nota del traductor: esto hay que verlo desde el punto de vista del año en que se publicó el libro, 1975, ahora sabemos que existen las aplicaciones minimalistas como Google, Facebook o Apps Mobile, donde todo es más simple para el usuario) a medida que se agregan funciones cada vez más complejas. Por ejemplo, me asombra la facilidad de uso de la IBM 650, incluso dejando afuera ensamblador u otro software que posea.

Debido a que la facilidad de uso es el propósito, esta relación entre la función y la complejidad conceptual es la última prueba del diseño del sistema. Ni la función o simplicidad por sí solas, definen un buen diseño.
Este punto es ampliamente mal entendido. El SO/360 es aclamado por sus constructores como el mejor jamás construido, porque indiscutiblemente tiene muchas funciones. La función y no la simplicidad, ha sido la unidad de medida por excelencia de sus creadores. Por otro lado, el Sistema de Compartición del Tiempo del PDP-10 es aclamado por sus creadores como el más fino, debido a su simplicidad y la escasez de sus conceptos. Sin embargo, en cualquier caso, su función no está ni siquiera al nivel de la de OS/360. Si hablamos que la facilidad de uso sea el criterio, cada uno de ellos se ve desequilibrado, alcanzando sólo la mitad de la meta real.

Para un nivel dado de función, sin embargo, ese sistema es el mejor en el cual uno puede especificar las cosas con la mayor sencillez y facilidad que se puede. En todo caso, la simplicidad no es suficiente. El lenguaje TRAC de Mooers y Algol 68 alcanza una sencillez dada por conceptos distintos. Sin embargo, no son sencillos de manejar. La expresión de las cosas que uno quiere hacer a menudo requiere combinaciones no evolucionadas e inesperadas de una función base. No basta con aprender los elementos y las reglas de la combinación, uno debe también aprender el uso idiomático, toda una sabiduría de cómo los elementos se combinan en la práctica. La simplicidad y la franqueza proceden de la integridad conceptual. Cada parte debe reflejar las mismas filosofías y el mismo equilibrio de desiderata. Cada parte debe incluso utilizar las mismas técnicas en sintaxis y nociones de la semántica. La facilidad de uso, entonces, dicta una unidad de diseño, dicta la integridad conceptual.

Aristocracia y democracia

La integridad conceptual a su vez dice que el diseño debe proceder de una mente, o de un número muy pequeño de mentes concordantes.
En el mundo de la programación, sin embargo, dice que la construcción del sistema necesita muchas manos. Hay dos técnicas disponibles para resolver este dilema. La primera es una cuidadosa división del trabajo entre arquitectura e implementación. La segunda es la nueva forma de estructurar los equipos de implementación de programación discutidos en el capítulo anterior. La separación entre el esfuerzo arquitectónico y la implementación es una forma muy poderosa de conseguir integridad conceptual en proyectos muy grandes. Yo mismo he visto que se usó con gran éxito en la computadora Stretch de IBM y en la línea de productos de computadoras System/360. Pero la he visto fallar con las aplicaciones del SO/360.

Por la arquitectura de un sistema, me refiero a la especificación completa y detallada de la interfaz de usuario. Para una computadora este es el manual de programación. Para un compilador es el manual del lenguaje. Para un programa de control son los manuales para el idioma o lenguajes usados para invocar sus funciones. Para todo el sistema es la unión de los manuales que el usuario debe consultar para hacer todo su trabajo. El arquitecto de un sistema, como el arquitecto de un edificio, es el agente del usuario. Su trabajo consiste en llevar el conocimiento profesional y técnico al más puro interés del usuario, en contraposición a los intereses del vendedor, del fabricante, etc. La arquitectura debe ser cuidadosamente diferenciada de la implementación.

Como Gerrit Blaauw dijo: "la arquitectura dice lo que sucede, la implementación dice cómo se hace que suceda". Él da como ejemplo simple un reloj, cuya arquitectura consiste en la cara, la correa y la perilla. Cuando un niño ha aprendido esta arquitectura, puede decir el tiempo tan fácilmente de un reloj de pulsera como de una torre de iglesia. La implementación, sin embargo y su realización, describen lo que sucede en el interior de los muchos mecanismos y controles que el reloj tiene.

En un computador System/360, por ejemplo, una arquitectura de computadora única se implementa de manera muy diferente en cada uno de los nueve modelos. Por el contrario, una única implementación, el flujo de datos del Modelo 30, la memoria y el microcódigo, sirve en diferentes momentos para cuatro arquitecturas diferentes: un System/360, un canal multiplex con hasta 224 subcanales lógicamente independientes, un canal selector y un ordenador 1401.
La misma distinción es igualmente aplicable a los sistemas de programación. Existió un estándar estadounidense para el Fortran IV. Era una arquitectura para muchos compiladores. Dentro de esta arquitectura era posibles muchas implementaciones como text-in-core o compiler-in-core, fast-compile, compilación rápida u optimización, sintaxis directa o ad-hoc. Del mismo modo cualquier lenguaje ensamblador o lenguaje de control admitía muchas implementaciones del ensamblador o scheduler.

Ahora podemos hablar de la cuestión profundamente emocional que es la aristocracia versus la democracia. ¿No son los arquitectos una nueva aristocracia, una élite intelectual, preparada para decir a los pobres ejecutores mudos qué deben hacer?, ¿no ha sido todo el trabajo creativo secuestrado para esta élite, dejando a los implementadores sólo como engranajes en la maquinaria?, ¿no se conseguirá un mejor producto obteniendo las buenas ideas de todo el equipo, siguiendo una filosofía democrática, en lugar de restringir el desarrollo de especificaciones a unos pocos?
En cuanto a la última pregunta, que es la más fácil. Ciertamente no afirmaré que sólo los arquitectos tendrán buenas ideas arquitectónicas. A menudo una idea fresca proviene de un implementador o de un usuario. Sin embargo, estoy convencido según mi experiencia y también lo he intentado demostrar, que la integridad conceptual de un sistema determina su facilidad de uso.

Las características o ideas que no se integren con los conceptos básicos de un sistema es mejor dejarlas de lado. Si aparecen varias ideas importantes pero incompatibles, se desecha todo el sistema y se empieza de nuevo en un sistema integrado, pero con diferentes conceptos básicos.

En cuanto a la carga aristocrática, la respuesta debe ser sí y no.

Sí, en el sentido de que debe haber pocos arquitectos, su producto debe durar más tiempo que el de un ejecutor, y el arquitecto se encuentra en el centro de las fuerzas que debe resolver en última instancia en interés del usuario. Si un sistema debe tener integridad conceptual, alguien debe controlar los conceptos. Es una aristocracia que no necesita disculpas.
No, porque la creación de especificaciones externas no es un trabajo más creativo que el diseñar las implementaciones. Es sólo un trabajo creativo diferente. El diseño de una implementación, dada una arquitectura, requiere y permite tanto la creatividad de diseño, como de ideas nuevas y de brillantez técnica, tanto como el diseño de las especificaciones externas. De hecho, la relación costo-rendimiento del producto dependerá en gran medida del implementador, así como la facilidad de uso depende en gran medida del arquitecto.

Hay muchos ejemplos en otras artes y oficios que indican que la disciplina es buena para el arte. De hecho, el aforismo de un artista afirma: "la forma es liberadora". Los edificios peores son aquellos cuyo presupuesto era demasiado grande para los propósitos que se usarán.
La producción creativa de Bach apenas parece haber sido sofocada por la necesidad de producir una cantata de forma limitada cada semana. Estoy seguro de que la computadora Stretch habría tenido una mejor arquitectura si hubiera sido más restringida; las restricciones impuestas por el presupuesto del System/360 Modelo 30 eran en mi opinión totalmente beneficiosas para la arquitectura del Modelo 75.
Del mismo modo, observo que si la arquitectura la entrega un proveedor externo, esta mejora sin obstáculos el estilo creativo del grupo de implementación. Se centran de inmediato en la parte del problema que nadie ha tratado y las invenciones comienzan a fluir. En un grupo de implementación sin restricciones, la mayor parte del pensamiento y el debate van hacia las decisiones arquitectónicas y la implementación correcta se hace corta.
Este efecto, que he visto muchas veces, es confirmado por R. W. Conway, cuyo grupo en Cornell construyó el compilador PL/C para el lenguaje PL/I. Él dijo: "finalmente decidimos implementar el lenguaje sin cambios y sin mejoras, porque los debates sobre el lenguaje habrían tomado todo nuestro esfuerzo".

¿Qué hace el implementador mientras espera?

Es una experiencia muy humillante el cometer un error multimillonario, pero a la vez es memorable. Recuerdo claro la noche que decidimos cómo organizar la escritura real de especificaciones externas para el OS/360. El gerente de arquitectura, el gerente de implementación y yo estábamos debatiendo el plan, el cronograma y la división de responsabilidades. El director de arquitectura tenía 10 hombres buenos. Afirmó que podrían escribir las especificaciones y hacerlo bien. Tomaría diez meses, tres más que el tiempo comprometido. El gerente de implementación tenía 150 hombres. Afirmó que podría preparar las especificaciones, con la coordinación del equipo de arquitectura; sería bien hecho y de forma práctica, y él podría hacerlo en el los tiempos establecidos. Ahora, si el equipo de arquitectura lo hiciera como dijimos, sus 150 hombres estarían girando en sus asientos durante diez meses.

A esto el director de arquitectura dijo que si yo le daba toda la responsabilidad al equipo de implementación, el resultado no sería de hecho a tiempo, sino que también estaría tres meses atrasado y de calidad mucho menor. Lo hice, y así fue. Tenía razón en ambos aspectos.
Además, la falta de integridad conceptual hizo que el sistema fuera mucho más costoso de construir y cambiar, y yo estimaría un año más al tiempo de depuración.
Muchos factores, por supuesto, entraron en esa decisión equivocada, pero era abrumador el tiempo de no hacer nada con los 150 hombres.
Cuando se propone que un pequeño equipo de arquitectura escriba todas las especificaciones externas para una computadora o un sistema de programación, los implementadores plantean tres objeciones:

• Las especificaciones serán demasiado ricas en función y no reflejarán consideraciones prácticas de costo.
• Los arquitectos tendrán toda la diversión creativa y excluirán la ideas de los ejecutores.
• Los implementadores tendrán que sentarse ociosamente a esperar que las especificaciones vengan desde un embudo estrecho que es el equipo de arquitectura.

El primero de los puntos anteriores es un peligro real y será tratado en el próximo capítulo. Las otras dos son ilusiones, así de simple. Como hemos visto anteriormente, la implementación es también una actividad creativa de primer orden. La oportunidad de ser creativo en la implementación no disminuye significativamente al trabajar cuando se entrega una especificación externa y la creatividad puede incluso ser mejorada por esa disciplina y el producto total seguramente será mejor. La última objeción es una que tiene que ver con tiempos y ajuste de fase. Una respuesta rápida es abstenerse de contratar implementadores hasta que las especificaciones estén completas. Esto es lo que se hace cuando se construye un edificio. En el negocio de sistemas informáticos, sin embargo, el ritmo es más rápido y uno quiere comprimir el calendario tanto como sea posible. ¿Cuánto puede superponerse la especificación y la construcción?

Como señala Blaauw, el esfuerzo creativo total implica tres fases distintas: arquitectura, implementación y realización. Resulta que estos pueden de hecho ser comenzados en paralelo y proceder simultáneamente.

En el diseño de computadoras, por ejemplo, el implementador puede comenzar tan pronto como tenga suposiciones relativamente vagas acerca del manual, ideas algo claras sobre la tecnología y objetivos bien definidos de costo y desempeño. Puede comenzar a diseñar flujos de datos, secuencias de control, conceptos de deploy, etc. El implementador diseña o adapta las herramientas que necesitará, especialmente el sistema de mantenimiento de registros o sistema de automatización.
Mientras tanto, en el nivel de realización (N. del T: en el caso de un nuevo sistema IBM): los circuitos, tarjetas, cables, marcos, fuentes de alimentación y memorias deben ser diseñadas, refinadas y documentadas. Este trabajo se desarrolla en paralelo con la arquitectura y la implementación.

Lo mismo ocurre en la programación del sistema. Mucho antes de que las especificaciones externas estén completas, el implementador tiene mucho que hacer. Con algunas aproximaciones en cuanto a la función del sistema que se incorporará finalmente en las especificaciones, él puede proceder. Debe tener objetivos bien definidos de espacio y tiempo. Debe conocer la configuración del sistema en la que debe funcionar su producto. Luego puede comenzar a diseñar límites de módulos, estructuras de tablas, desgloses de paso o fase, algoritmos y todo tipo de herramientas. Igualmente, a veces debe comunicarse con el arquitecto.

Mientras tanto, a nivel de realización hay mucho que hacer también. La programación también tiene una tecnología. Si la máquina es nueva, se debe hacer mucho trabajo en convenciones de subrutinas, técnicas de supervisión, algoritmos de búsqueda y clasificación.

La integridad conceptual requiere que un sistema refleje una sola filosofía y que la especificación vista por el usuario fluya de unas pocas mentes. Sin embargo, debido a la división real del trabajo en arquitectura, implementación y realización, esto no implica que un sistema lleve más tiempo construir. La experiencia demuestra lo contrario, que el sistema integral va más rápido y toma menos tiempo para probar. En efecto, una amplia división horizontal del trabajo se ha reducido drásticamente al usar una división vertical del trabajo y el resultado es una comunicación radicalmente simplificada y una mejor integridad conceptual.

El Mítico Hombre-Mes (The Mythical Man-Month) capítulo 3 en español

Hola a todos!
He terminado la traducción del Capítulo 3 del libro The Mythical Man-Month: Essays on Software Engineering.
En este capítulo Brooks explica un estilo de organizar un equipo de desarrollo de software en base un equipo quirúrgico (cuya idea inicial fue de Harlan Mills), donde todos tienen roles bien diferenciados.

¿Será aplicable en la actualidad este modelo? Yo creo que sí, adaptado ciertos roles gracias a las nuevas tecnologías existentes hoy.

Como dice Luigi del videojuego, "Here we go!":

The Mythical Man-Month : Essays on Software Engineering.
Capítulo 3: El equipo de cirugía

Figura 3.1.
Estudios revelan grandes diferencias individuales de desempeño, a menudo relacionado por el grado de importancia de lo que se realiza.

SACKMAN, ERIKSON Y GRANT

En los debates o foros de computación se ve muchas veces a jóvenes jefes o líderes de proyectos que dicen estar a favor de un equipo fuerte y reducido, pero de un nivel de primera clase, en vez de tener un equipo con cientos de desarrolladores pero de un nivel medio-bajo. Así lo creen muchos. 

Pero esta ingenua afirmación no resuelve la difícil pregunta: ¿cómo construir grandes sistemas informáticos que tienen una planificación muy larga? Echemos un vistazo más detallado de este problema.

El problema

Los gerentes informáticos o los Jefes de Proyecto (JP) desde hace tiempo han reconocido la diferencia de productividad entre los buenos y malos desarrolladores. Pero si se llega a medir dicha diferencia, el resultado nos sorprendería a todos. En uno de estos estudios, los autores Sackman, Erikson y Grant midieron el desempeño de un grupo de desarrolladores experimentados. En tan sólo este grupo, la relación entre los mejores y peores desempeños fue de 10:1 en una medición de la productividad, ¡y de un increíble 05:01 en velocidad de programación! En resumen los 20,000 dólares / año de un programador experimentado (Nota del traductor: en la época sería algo como 1.2 millones en pesos chilenos mensuales) puede ser hasta 10 veces más productivo que un programador de 10,000 dólares al año. Además, los datos no mostraron correlación alguna entre la experiencia y el rendimiento (dudo que eso es una verdad universal).

He sostenido anteriormente que la coordinación de un gran número de mentes tiene un gran costo en esfuerzo y una parte importante de ese costo es la comunicación, esto a la vez tiene un costo en la corrección de los efectos nocivos por la falta de comunicación (y hay que modificar o depurar algo). Esto también nos lleva a pensar que el sistema debería ser construido por el menor número de mentes posible. Por ejemplo, se tiene la experiencia del desarrollo de algunos grandes sistemas donde se usa una gran fuerza bruta, por lo tanto, son lentos de construir, ineficientes y con subsistemas que no están integrados conceptualmente. Por ejemplo tenemos el OS/360, Exec 8, Alcance 6600, Multics, TSS, SAGE, etc, y la lista sigue y sigue.

Entonces uno podría lanzar ideas: si un proyecto es de 200 hombres y de ellos hay 25 líderes o jefes de proyectos que son los analistas desarrolladores más competentes y experimentados, lo mejor sería despedir al resto, los 175 desarrolladores, y poner sólo a los jefes y líderes desarrollar. Otra idea sería tomando en cuenta lo se dijo al inicio, es decir, de tener sólo un equipo pequeño pero fuerte, que por consenso no excede las 10 personas. 

Si tomamos la idea de tener 200 personas, es tanta gente que tendrá que ser necesario tener dos niveles de administración, y cerca de cinco directores o jefes. Además se necesita el apoyo en finanzas, personal administrativo, espacio, secretarias y operadores. Por otro lado, este equipo de 200 hombres en verdad no es lo suficientemente grande para construir un sistema "muy grande" por el método de fuerza bruta. Considere por ejemplo la posibilidad del desarrollo de un OS/360 (Nota del traductor: Sistema Operativo de IBM hecho entre 1962 y 1972) que en su mejor momento trabajaban más de 1000 personas, entre ellos desarrolladores, escritores, operadores, oficinistas, secretarias, ejecutivos, soporte, etc. De 1963 a 1966 probablemente trabajaron en esta empresa 5000 años/hombre en etapas de diseño, construcción y documentación. ¡Si los hombres y meses fueran uniformes, nuestro equipo de 200 hombres habría tardado 25 años y no 10 en llevar el producto a su presente estado! 

En conclusión, este es el problema con un equipo pequeño pero fuerte: es demasiado lento para desarrollar sistemas grandes. Consideremos de nuevo el caso de OS/360, y veamos la opción de abordarlo con un equipo más pequeño pero muy agudo técnicamente. Para esto consideremos lo que dijimos antes, de dejar como consenso que un equipo pequeño es de 10 hombres. Según las estadísticas, a lo más estos serán 7 veces más productivos que un equipo de desarrolladores de nivel medio-bajo tanto en codificación como en documentación. Supongamos además, que el OS/360 se construye sólo por desarrolladores de nivel promedio (cosa que está "lejos" de ser verdad). Como dato aparte, hay una mejora de la productividad al menos en 7 veces debido a la baja comunicación que se requiere por parte de este equipo reducido.

Ahora supongamos que el mismo único equipo está trabajando todo el tiempo del proyecto, esto sería: 5000 / (10x7x7) = 10 años aproximadamente, entonces el trabajo 5000 años/hombres se hará en 10 años.

La consulta que se genera ahora es: ¿el producto será interesante 10 años después de su diseño inicial? ¿O ha quedado obsoleto debido al rápido desarrollo de nuevas tecnologías de software?

El dilema es algo cruel. Para sistemas medianos o chicos, uno debería preferir pocas pero buenas mentes para obtener una eficiencia y una integridad conceptual. Sin embargo, en sistemas grandes uno requiere saber manejar una considerable mano de obra, para que el producto de software tenga una fecha de finalización acorde. ¿Cómo se pueden conciliar estas dos necesidades?

Propuesta de Mills

Una propuesta de Harlan Mills ofrece una solución fresca y creativa. Mills propone que cada segmento de un gran trabajo debe ser abordado por un equipo, pero que el equipo se organizará como un equipo quirúrgico en lugar de un equipo estilo "matanza de cerdo". Es decir, en lugar de que cada miembro haga cortes sobre el problema, uno sólo hace el corte y los demás le dan todo el soporte posible, lo que mejorará la eficiencia y productividad de toda la actividad.

Este mismo concepto se puede encontrar en el poema Desiderata si lo aplicáramos en el trabajo. Pocas mentes están involucrados en el diseño y la construcción, sin embargo, muchos "meten mano", ¿funcionará? ¿Quiénes son los anestesiólogos y enfermeros en un equipo de desarrollo y cómo se divide el trabajo? Permítanme libremente mezclar metáforas para sugerir cómo un equipo puede funcionar de esta forma aplicando un sistema de soporte o colaboraciones.

El cirujano. Mills le llama programador jefe. Él (el Cirujano), personalmente define las especificaciones funcionales y de desempeño, los diseños del programa, códigos, tests y escribe la documentación. Programa en un lenguaje de programación estructurado como PL/I (Nota del traductor: parecido a Pascal, no quedaba de otra, en la epoca no habían lenguajes como C# o Java que son orientados a objetos), y accede a algún sistema de computación donde ejecuta sus pruebas, pero también almacena las diferentes versiones de sus programas, actualiza sus archivos y documenta. Debe tener un gran talento, de unos diez años de experiencia desarrollando sistemas importantes y con muchos conocimientos de aplicaciones, matemáticas, negocios, etc.

El asistente o copiloto. Él es el alter ego del cirujano, capaz de hacer cualquier parte del trabajo, pero tiene menos experiencia. Su principal función es participar en el diseño con puntos de vista críticos y visión de evaluador. El cirujano discute las ideas con él, pero no está obligado a aceptar sus consejo a ojos cerrados. El asistente a menudo representa a su equipo en los debates sobre la función y la conexión con otros equipos. Lo sabe todo acerco del código. Investiga el diseño de estrategias alternativas. Obviamente, él sirve también como una especie de seguro contra desastres para el cirujano. Incluso puede escribir código, pero la responsabilidad final de las líneas escritas no recae en él.

El administrador. El cirujano es el jefe pero también debe ver todo lo referente al personal, aumentos, manejo de espacio, etc., por lo que no le alcanza el tiempo para estos en estos asuntos. Así que necesita un administrador profesional que maneje el dinero, la gente, el espacio, y las máquinas, pero a la vez, que interactúe con toda el resto de la organización. F. Terry Baker, sugiere que el administrador debe tener un trabajo a tiempo completo solamente si el proyecto es de importancia legal, contractual, de informes o requerimientos financieros debido a una relación productor-comprador. Por otra parte, un administrador puede apoyar a un máximo de dos equipos.

El editor. El cirujano es responsable de generar la documentación para obtener la máxima claridad en el diseño y desarrollo. Este es tanto para los casos de descripciones externas como internas. El editor, sin embargo, toma la documentación generada por el cirujano, la critica, la hace un reworks (retrabajo), le proporciona referencias y bibliografía en la medida de los posible, la agranda por medio de versiones y supervisa la mecánica de la documentación.

Dos secretarios. El administrador y el editor tendrán cada uno, un secretario, estos se encargarán de la correspondencia del proyecto y archivos que no sean el producto mismo. (Nota del traductor: hay que ponerse en contexto de que en el año 1972 cuando se estableció este sistema de manejo de equipos no se usaban los correos electrónicos como hoy en día).

Un recepcionista. Él es responsable de mantener todos la registros técnicos que genere el equipo, en un archivo tipo librería de software. El recepcionista se entrenó como secretario y tiene por lo tanto archivos legibles tanto por un computador como por humanos. Todo lo que sea una entrada al sistema pasa por el recepcionista, quien deja registro de los puntos claves si son necesarios. Los aspectos de salida pasan igual por él para ser archivados y ordenados. En la actualidad, esta información de las ejecuciones y estados se mantienen en un notebook, antes se guardaban en un archivos físicos.

Es absolutamente vital para el concepto de Mills lo que él llama la transformación de la programación de un arte privado a una práctica pública haciendo que el equipo funcione visiblemente para todos los miembros del equipo y la identificación de todos programas y datos sean propiedad de todo el equipo, no una propiedad privada.

La función especial del recepcionista es liberar a los programadores de las tareas administrativas, sistematizar y asegurar un rendimiento adecuado de esas tareas a menudo olvidadas y aumentar el activo más valioso: el producto que se genera. Es evidente que estas tareas se deben realizar de manera secuencial. Cuando se utilizan elementos de interacción, especialmente aquellos que requieren una copia impresa, las funciones del recepcionista no disminuyen, sino que cambian. Él registra todas las copias privadas de cada actualización que tenga algún miembro del equipo y utiliza su propia herramienta para el control de la integridad y la disponibilidad del producto.

El toolsmith (Nota del traductor: es como un experto en herramientas de apoyo). Para que funcione este modelo, debe existir un conjunto de servicios de edición de archivos, textos y de depuración, por lo que un equipo rara vez tendrá que usar su propia máquina para esto. Sin embargo, estos servicios deben estar disponibles con una alta capacidad de respuesta y fiabilidad, y el cirujano debe ser el único que puede de adecuar estos servicios a su disposición. Por lo tanto aquí nace la figura de un toolsmith que trabaja para el cirujano. Este personaje que es responsable de garantizar la idoneidad de estos servicios básicos y que a la vez debe construir, mantener y actualizar sus propias herramientas - sobretodo servicios informáticos interactivos - que necesitará el equipo. Cada equipo tendrá su propio toolsmith, independientemente si hay un servicio común central, su trabajo es tener disponibles las herramientas necesarias o buscadas por su cirujano, por sobre lo que se solicite desde algún otro equipo. Este especialista a menudo debe construir servicios especializados, procedimientos catalogados o macros.

El tester. El cirujano necesita un banco de casos de prueba adecuados para probar tonta piezas particulares que desarrolle como para una prueba completa del sistema o módulo. Por lo tanto, el tester es al mismo tiempo un adversario que elabora los casos de prueba para especificaciones funcionales como también pruebas que sirven para depurar la aplicación en el día a día. También planea secuencias de prueba y establece el andamiaje necesario para pruebas de componentes.

Experto en el lenguaje. En el momento que llegó el lenguaje de programación Algol, la gente comenzó a reconocer que existían ciertas personas que se deleitaban en el dominio de la complejidad de un lenguaje de programación, y estos expertos resultaban ser muy útiles y ampliamente consultados. El talento aquí es bastante diferente al de un cirujano, que es principalmente un diseñador del sistema y que piensa en aspectos funcionales. El experto en el lenguaje conoce varias de manejar el lenguaje de forma ordenada y eficiente para sacar adelante cosas difíciles, oscuras o realizar ciertos trucos. A menudo tendrá que hacer breves investigaciones de buenas prácticas (de dos o tres días). Un experto en lenguaje puede ayudar a un máximo de dos o tres cirujanos. 

Entonces esto responde a la pregunta de cómo las 10 personas podrían contribuir en un sistema de roles bien diferenciado, donde el equipo de programación esté basado en el modelo quirúrgico.

¿Cómo funciona?

El equipo que se acaba de definir coincide con el poema Desiderata en varios puntos. Diez personas, siete de los cuales son profesionales, están trabajando en el problema, pero el sistema es el producto de una mente o dos como mucho pero que actúan como uno animo. (Nota del traductor: no encontré el significado, pero debe ser algo como una "una unidad").

Tenga en cuenta, en particular, las diferencias entre un equipo típico de dos programadores y un equipo del tipo cirujano-copiloto. En primer tipo, en el equipo convencional, los programadores dividen el trabajo y cada uno es responsable del diseño y ejecución de su parte del trabajo. En el equipo quirúrgico, el cirujano y el copiloto son cada uno consciente de todo el diseño y de todo el código. Esto evita problemas tanto logísticos como la asignación de espacios, accesos al disco, etc., como también asegura la integridad conceptual de la obra.

En segundo lugar, en el equipo convencional los programadores son iguales y las inevitables diferencias de juicio deben ser habladas o se verán comprometidas.

Dado que el trabajo y los recursos se dividen, las diferencias en el juicio se limitan a la estrategia global y la interconexión, pero agravadas por las diferencias de intereses, por ejemplo, cuanto buffer se usará en una variable. (Nota del traductor: actualmente sería análogo a definir el largo de una variable en un mapeo de Hibernate o un SP de SQL).

En el equipo quirúrgico, no hay diferencias de intereses, ya que estas diferencias de criterio se resuelven por el cirujano de forma unilateral. Estas dos diferencias: la falta de división del problema y la relación superior-subordinado, hacen que sea posible que el equipo quirúrgico actúe como uno animo.

Sin embargo, la especialización de la función del resto del equipo es la clave de su eficacia, ya que permite un patrón de comunicación radicalmente más simple entre los miembros, que se ve en la figura 3.1.

Fin del capítulo 3.

Bueno, esta fue la traducción, aparte encontré estos interesantes enlaces que apoyan la lectura:

• http://www.seas.gwu.edu/~mlancast/cs254/p106-mantei.pdf Análisis de distintas formas de manejar diversas estructuras de equipos.
• http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5388252&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5388252 Texto completo del libro "Chief Programmer Team Management of Production Programming".
• http://c2.com/cgi/wiki?ChiefProgrammerTeam Review del modelo "Chief Programmer Team" de F. Terry Baker (1972).

El Mítico Hombre-Mes (The Mythical Man-Month) capítulo 2 en español

Hola a todos!
He terminado la traducción del Capítulo 2 del libro The Mythical Man-Month: Essays on Software Engineering.
En este capítulo entrega ciertas fórmulas muy valiosas que todo líder de proyecto o JP debería tener. También se nota que el libro al ser de 1995, explica en base a metodologías de la época como RUP, por lo que los amantes de las nuevas metodologías ágiles deberán asociarla.

Vamos directo al hueso:

The Mythical Man-Month : Essays on Software Engineering.
Capítulo 2 : The Mythical Man-Month

Traducción terminada el 09 de Abril del 2013, por Ing. Hernaldo González Candia (hernaldog@gmail.com)
Todos los créditos son para el autor del libro Frederick Phillips Brooks.

La buena cocina toma su tiempo. Si se demora es para darle un mejor servicio y complacerlo mejor.
MENU DEL RESTAURANT ANTOINE EN NEW ORLEANS

Más proyectos de software han fracasado por falta de tiempo que por cualquier otra causa combinada. ¿Por qué es tan común esta causa?

En primer lugar, nuestras técnicas de estimación están poco desarrolladas. Ya que reflejan una suposición sin voz, totalmente falsa, asumiendo que todo va a salir bien.

En segundo lugar, nuestras técnicas de estimación confunden esfuerzo con progreso, ocultando el supuesto de que los hombres y los meses son intercambiables.

En tercer lugar, porque no estamos seguros de nuestras propias estimaciones, esto sumado a que los líderes del proyecto en general no son "cortésmente tercos" como lo es el chef Antoine.

En cuarto lugar, no se controla bien el progreso de lo planificado. Hay técnicas probadas en otras disciplinas de ingeniería que serían grandes innovaciones en la Ingeniería de Software.

En quinto lugar, cuando se reconoce el atraso, la natural (y tradicional) respuesta es agregar más mano de obra. Esto es lo mismo sofocar un incendio con gasolina, las cosas empeorarán más y quedarán peores. Más fuego requiere más gasolina y así comienza un ciclo que siempre termina en un desastre.

El monitoreo del plan es un tema que da para un ensayo aparte.

Vamos a considerar otros aspectos del problema con más detalle.

Optimismo

Todos los programadores son optimistas. Tal vez este tipo de brujería moderna atrae especialmente a los que creen en los finales felices y las madrinas de las hadas. Tal vez esas cientos de frustraciones desaparecen de la mente de aquellos que sólo se centran en el objetivo final. Tal vez sea simplemente que los computadores son cada vez más nuevos y rápidos, los programadores son cada vez más jóvenes y los jóvenes son siempre optimistas. Pero sin embargo, el proceso siempre funciona igual y el resultado es el mismo: "esta vez es seguro que correr", o "acabo de encontrar el último bug".

Así que la primera suposición falsa que subyace a toda programación o planificación de sistemas que todo va a ir bien, es decir, que cada tarea sólo va a demorar lo que "debería" demorar y no más.

La omnipresencia del optimismo entre los programadores merece más que un análisis a la rápida. Dorothy Sayers, en su excelente libro Mind of the Maker (La Mente del Creador), divide la actividad creativa en tres etapas: la idea, la implementación y la interacción. Un libro, un computador, o un programa llega a existir por primera vez como un ideal a construir, y se construye fuera del tiempo y del espacio, pero está completa en la mente del autor. Luego se realiza dentro del tiempo y el espacio, ya sea por una pluma, tinta y papel, con un hilo, silicio o hierro. La creación sólo se completa cuando alguien lee el libro, utiliza el computador o corre el programa, así interactúan con la mente del creador.

Esta descripción, que la señorita Sayers utiliza en su libro para iluminar no sólo la actividad creativa humana, sino también aspectos cristianos, nos ayudará en nuestra presente tarea. Para los creadores humanos de las cosas, la no completud e inconsistencia de nuestras ideas se ponen en manifiesto sólo durante la implementación. Por esto es que la escritura, la experimentación, la "elaboración" son disciplinas esenciales para aquel que es teórico.

En muchas actividades creativas el medio de ejecución es intratable. Cortar madera, pintar un frontis o terminar un circuito eléctrico. Estas limitaciones físicas del medio pueden restringir las ideas en que estas pueden ser expresadas y que crean dificultades inesperadas en la implementación.

La implementación entonces, toma tiempo y sudor, tanto por los medios físicos como por las insuficiencias de las ideas subyacentes. Tenemos la tendencia a culpar a los medios físicos por la mayor parte de nuestras dificultades de implementación; porque los medios no son "nuestros" en el forma en que lo son las ideas y los colores del orgullo de nuestro juicio.

La programación, sin embargo, se crea con un medio sumamente tratable. El programador construye a partir de puro pensamiento: conceptos y representaciones muy flexibles de los mismos. Debido a que el medio es tratable, se esperan pocas dificultades en la implementación, de ahí nuestro optimismo generalizado. Debido a que nuestras ideas son defectuosas, tenemos errores, por lo que el optimismo está injustificado.

En una simple tarea, la suposición de que todo va a ir bien tiene un efecto probabilístico en la planificación del proyecto. De hecho, podría avanzarse como se está planeado ya que siempre hay atrasos considerados en el plan y que están repartidos o distribuidos dada cierta probabilidad. No es así con los "no atrasos" que tienen una probabilidad finita. Una gran tarea de programación, sin embargo, consiste en muchas sub-tareas algunas asociadas de punta a punta, y en donde la probabilidad de que cada una vaya a ir bien es extremadamente pequeña.

 El Hombre-Mes

El segundo modo de pensamiento falso se expresa en una unidad de esfuerzo empleado bastante en la estimación y programación del plan: el hombre-mes. En efecto, el costo varía según el número de hombres y el número de meses que se tengan. El progreso en cambio, no siempre variará. Por lo tanto el hombre-mes, como unidad para medir el tamaño de un trabajo, es un mito peligroso y engañoso. Esto implica que los hombres y los meses sólo se pueden intercambiar sólo bajo ciertas condiciones.

Fig. 2.1 Tiempo versus el número de trabajadores, esto en una tarea perfectamente particionable.

Los hombres y los meses son productos intercambiables sólo cuando una tarea se puede dividir entre muchos trabajadores sin comunicación entre ellos (Fig. 2.1). Este es el caso, por ejemplo, de cosechar trigo o recoger algodón, pero nunca en la programación de sistemas.

Cuando una tarea no puede ser dividida debido a las limitaciones secuenciales, si se aplica un mayor esfuerzo, no tendrá ningún efecto sobre la programación (Fig. 2.2). El crecimiento de un niño tarda nueve meses, no importa cuántas matronas le asistan. Muchas de las tareas de software tienen esta característica debido a que hay etapas del desarrollo que son secuenciales.

Fig. 2.2 Tiempo versus número de trabajadores, esto en una tarea que no es particionable.

Si las tareas pueden dividirse, requerirán comunicación entre las sub-tareas,  por lo tanto, se debe añadir al trabajo mismo, el esfuerzo de la comunicación. Entonces, lo mejor que podemos alcanzar es algo un poco menos eficiente que el modelo de intercambio de los hombres con los meses (Fig. 2.3).

Fig. 2.3 Tiempo versus número de trabajadores, esto en una tarea particionable pero que requiere comunicación.

Adicionalmente, la comunicación se compone de dos partes, la capacitación (training) y la intercomunicación. Cada trabajador debe recibir capacitación en la tecnología, las metas, la estrategia global y el plan de trabajo. Esta formación no puede ser dividida, por lo que esta parte del esfuerzo que se añadió varía linealmente en relación al número de trabajadores.

La intercomunicación es peor. Si cada parte de la tarea debe ser separadamente coordinada con cada una de las otras partes, el esfuerzo aumenta en la medida de:

N * (N -1) / 2 

Tres trabajadores requieren tres veces más intercomunicación que dos, cuatro requieren seis veces más que dos.
Si por otra parte, es necesario que existan reuniones entre tres, cuatro o más trabajadores para resolver algún problema en conjunto, las cosas empeoran más aún. El esfuerzo agregado de comunicarse plenamente puede contrarrestar la división de la tarea original y nos lleve a la situación de la Figura 2.4.

Fig. 2.4 Tiempo versus número de trabajadores, esto en una tarea que requiere complejas interrelaciones.

Ya que la construcción de software es básicamente un sistema de esfuerzo - lo que incluye un ejercicio de complejas interrelaciones - y que conlleva un gran esfuerzo de comunicación que rápidamente lleva a que se disminuya el tiempo de trabajo individual provocada por la partición de las tareas. Entonces la adición de más hombres hace que se alargue la programación del plan estimado y no se acorte.

Sistemas de Test

No hay partes en el plan programado que se vea tan fuertemente afectado por las restricciones secuenciales como son las faces de depuración y prueba. Además, el tiempo requerido depende del número y la sutileza de los errores encontrados. Teóricamente, este número debería ser cero. A causa del optimismo, por lo general esperan que el número de errores sea menor del que en verdad resulta ser. Por lo tanto, la etapa de testing es la más reprogramada o replanificada de todo el plan.

Desde hace algunos años he estado utilizando con buena tasa de éxito la siguiente regla de oro para la estimación de una tarea de software:

• 1 / 3 planificación
• 1 / 6 codificación
• 1 / 4 testeo o depuración de las componentes y una prueba básica del sistema
• 1 / 4 prueba del sistema y de todos los componentes involucrados

Esto difiere de una estimación convencional en varios aspectos importantes:

1. La fracción dedicada a la planificación es más grande de lo normal. Aun así, es apenas suficiente para producir una especificación detallada y sólida, y no lo suficiente para incluir la investigación o la exploración de nuevas técnicas.
2. Casi la mitad de la estimación está dedicada a la depuración de código lo que es mucho más grande que lo tradicional.
3. La parte fácil de estimar es la codificación, que es la sexta parte de la estimación.

Si examinamos como funciona en general la estimación en proyectos que no son de software, encontramos que son pocos los que estiman la mitad del tiempo para los test. Y que si en efecto, se usaba dicho tiempo para ese propósito, muchos de esos proyectos terminaron en fecha (no atrasados). Esto no sucede en los tests de sistemas de software.

En general no se deja tiempo suficiente para los test de sistemas, y en particular en software esto causa un gran desastre. Dado que el retraso se produce al final de la programación, no se es consciente de los problemas de fechas o estimaciones hasta cuando se acerca la fecha de entrega. Dar esas malas noticias, tarde y sin advertencias previas, es inquietante tanto para los clientes como para los gerentes a cargo.

Por otra parte, un retraso en esta fase tiene inusuales repercusiones financieras y psicológicas. El proyecto está con su capacidad completa de personal y el costo del día a día es alto. Si estamos ante algo más serio, como la construcción de algún software que da soporte a otro negocio (transporte de equipos, habilitación de nuevos módulos, etc.) hace que los costos secundarios producto del atraso sean muy altos. Esto se da casi siempre en software asociado al transporte o envío de productos. De hecho, estos costos secundarios pueden ser muy superiores a todos los demás. Por eso es muy importante que en el plan de estimación original se estime considerando un tiempo suficiente para las pruebas del sistema.

Estimación cobarde

Obsérvese que tanto para el programador como para el jefe de proyecto o líder a cargo, el uso de un patrón pueden determinar una fecha estimada de  finalización en el plan, pero no la fecha real de entrega. Una tortilla puede prometerse servirse en dos minutos cuando se sabe que en ese tiempo hay una baja probabilidad de que no esté lista. Ahora, cuando no está lista en esos dos minutos, el cliente tiene dos opciones: esperar o comérsela cruda. Los clientes de Software tienen las mismas opciones.
El cocinero en cambio tiene otra opción, subir la temperatura. El resultado suele ser una tortilla que está quemada por una parte y cruda en otra.

No creo que los jefes de proyecto o líderes tengan menos coraje y firmeza que  los cocineros, ni que otros administradores de otras área de la ingeniería. Pero desarrollar falsamente para que el término de la programación coincida con la fecha deseada es mucho más común en nuestra disciplina que en otras áreas de la ingeniería. Es muy difícil hacer una defensa vigorosa, plausible o involucrando todos los riesgos que se visualizan, de una estimación que se obtuvo bajo un método no cuantitativo, con pocos datos de apoyo y aprobada principalmente por los presentimientos de los gerentes.

Es evidente que se necesitan soluciones. Tenemos que desarrollar y dar a conocer las cifras de productividad, las cifras de incidencias que se dan, las reglas de estimación, etc. El conjunto sólo se puede beneficiar si se comparten esos datos.
Hasta que la estimación no se vea sólida, los jefes o líderes tendrán que endurecer su columna vertebral y defender sus estimaciones con la seguridad de que sus "corazonadas" determinen una buena estimación.

El desastre de una planificación regenerativa

¿Qué hace uno cuando se ve que un proyecto de software se va a atrasar? Añadir mano de obra naturalmente. Como sugieren las Fig. 2.1 a la 2.4, esto puede o no puede ayudar.

Consideremos un ejemplo. Supongamos que una tarea se estima en 12 meses-hombre y asignados a tres hombres para cuatro meses. Les pondremos a cada bloque, que representa cada uno, un mes, los códigos A, B, C, D y obtenemos una medición (Fig. 2.5). Supongamos ahora que el primer bloque no se logra hasta transcurrido dos meses (Fig. 2.6). ¿Cuáles son las alternativas que se enfrentaría quien está encargado del plan?

Figura 2.5

Figura 2.6

Figura 2.7

1. Asumir que la tarea debe hacerse a tiempo. Supongamos que sólo ese primer bloque fue estimado con optimimismo, tal como se ve en Fig. 2.6. Entonces quedan 9 meses-hombre de esfuerzo restantes, y como hay un bloque de atraso que son 3 meses, será necesario 4 hombres para cubrir ese bloque. Agregamos 2 hombres a los 3 asignados para 2 bloques.

2. Asumir que la tarea debe hacerse a tiempo. Supongamos que la estimación total fue uniformemente baja, tal como muestra la Figura 2.7. El esfuerzo gastado son 3 meses, quedan 9, pero como se asume que es una estimación uniformemente optimista, este sube a 18 meses-hombre, es decir, cada bloque restante de 6 y no 3 meses. Esto hace que se requieran 9 hombres en total, 6 hombres en vez de 3 asignados.

3. Reprogramar. Quiero tomar el consejo dado por P. Fagg, un ingeniero de hardware con experiencia, "no tomar los pedazos". Es decir, que en la nueva estimación haya tiempo suficiente para que el trabajo puede ser realizado cuidadosamente y completamente con tal que de no volver hacer una reprogramación.

4. Acortar la tarea. Esto tiende a suceder de todos modos en la práctica una vez que el equipo observa que los tiempos se están agotando. Cuando los costos secundarios del atraso son muy altos, esta es la única acción factible. La única alternativa del Jefe de Proyecto o Gerente es acortar la tarea formalmente y con cuidado, para volver a estimar dicha parte ya que sino, verá como la tarea se acorta en silencio por el equipo debido a un diseño incompleto y a las pruebas inconclusas.


En los dos primeros casos, insistiendo en que la tarea no debe ser alterada en cuatro meses, es desastroso. Considere los efectos regenerativos, por ejemplo, para la primera variante (Fig. 2.8). Los dos nuevos hombres, aunque sean competentes y se hayan reclutado rápidamente, requerirán entrenamiento en la tarea por alguno de los hombres experimentados. Si esto toma un mes, los tres hombres-meses ya no podrán trabajar sobre la estimación original. Además, la tarea, originalmente particionada en tres bloques, debe ser reparticionada ahora en cinco partes, así que el poco trabajo que se avanzó se perderá y las pruebas del sistema deberán extenderse.

Figura 2.8

Así, al final del tercer mes, faltan más de 7 hombre-mes, y se tiene 5 personas capacitadas y sólo un mes disponible. Como la Fig. 2,8 indica, el producto está tan atrasado como si no se hubiese añadido nada (Fig. 2.6).

Para poder realizarla en cuatro meses, teniendo en cuenta sólo el tiempo de entrenamiento pero dejando afuera tiempos de reparticionamiento y las pruebas del sistema, sería necesario agregar 4 hombres y no 2, al final del segundo mes. Para cubrir efectos del reparticionamiento y las pruebas del sistema habría que agregar aún más hombres. Ahora, sin embargo, se tiene un equipo de 7 hombres y no de 3, por lo que aspectos como la organización del equipo y la división de tareas ahora son de un grado y tipo diferente.

Hay que tener en cuenta que para el final del tercer mes las cosas se ven muy negras. El hito del 1ro. de Marzo no se ha alcanzado a pesar de todo el esfuerzo en gestión. Es muy fuerte la tentación de repetir el ciclo, agregando aún mas mano de obra, lo que sería una locura.

Lo anterior supone que sólo el primer hito fue desestimado. Si el 1 de Marzo se hace una reestimación de que toda la planificación bajo un punto de vista que toda la planificación anterior fue optimista, como muestra la Figura. 2.7, se requiere añadir sólo 6 hombres más a la tarea original. Los cálculos acerca del tiempo de entrenamiento, reparticionamiento y pruebas del sistema, se dejan como ejercicio al lector. Sin lugar a dudas, el desastre regenerativo da por resultado un producto más pobre, atrasado y reprogramado con respecto al plan original de tres hombres.

Si lo simplificamos de forma escandalosa, planteamos la Ley de Brooks:

Agregar más mano de obra a un proyecto de software que está atrasado, lo atrasa más.

Esta es entonces la desmitificación del hombre-mes. El número de meses de un proyecto depende de sus limitaciones secuenciales. El máximo número de hombres que se pueden agregar al proyecto depende del número de sub-tareas independientes. A partir de estas dos factores se puede derivar una planificación utilizando menos hombres y más meses. (El único riesgo sería la obsolescencia del producto.) No se puede, sin embargo, hacer un plan con más hombres y menos meses. Hay que recordar que más proyectos de software han fracasado por quedar cortos de tiempo que por cualquier otra causa combinada.

El Mítico Hombre-Mes (The Mythical Man-Month) capítulo 1 en español

Hola a todos mis friends. El otro día leí un artículo acerca de Los 10 libros míticos que todo desarrollador de Software debe leer y dentro de esa lista estaba el pulentoso libro The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) (algo así como El Mítico Hombre-Mes: Ensayos de Ingeniería de Software), como número 5 de la lista. También aparece dicho libro como número 2 en está página en inglés.

Este libro es algo antiguo aunque no tanto, es de 1995 pero habla de aspectos que son transversales a la época y que se encuentran día a día, como los atrasos chantas de proyectos, meter más gente al proyecto hace que colapse y para nada salga "antes de la fecha", el por qué los desarrolladores son tan optimistas, etc. Cosas muy muy interesantes.

Si quieren bajarlo completo, en Google ponen "The Mythical Man-Month pdf" y aparecerán varios sitios que lo ofrecen gratis. Por ejemplo de aquí http://uploaded.net/file/rlsg7tlh.

La cosa es que me puse a leer y estaba muy bueno. Encontré traducción al español del Capítulo 1 en http://juancarunbasic.wikispaces.com, y fue realizado por un colega Ingeniero, Juan Carlos Gutiérrez M. (correojuanca@gmail.com). Lo contacté y logramos un acuerdo donde la revisaría y publicaría la traducción integra acá y mejoraría si encontraba puntos que corregir.

Bueno, aquí vamos.

NOTA: advierto que el autor es algo cristiano, por lo que en un par de veces saca ejemplos relacionado con Dios, si eres medio ateo, omite dichos los ejemplos y sigue leyendo :P

The Mythical Man-Month : Essays on Software Engineering.

Esta es una traducción como ejercicio académico (también es un aporte a todos aquellos desarrolladores ultra-optimistas y líderes de desarrollo o JP que estiman con el viejo truco de tirar una moneda al aire) Traducción original: 22 de Febrero del 2009, por Ing. Juan Carlos Gutiérrez M. (correojuanca@gmail.com)
Revisado el 21/03/2013 por Ing. Hernaldo González Candia (hernaldog@gmail.com)

Está de más decir que todos los créditos son para el gurú (no me refiero al Bomba) y autor del libro Frederick Phillips Brooks.


Sobre el autor

Frederick P. Brooks, Jr., es un Kenan Professor de las Ciencias de la Computación en la Universidad de Carolina del Norte, en Chapel Hill. Es mejor conocido como el "padre de IBM System/360". Se desempeñó como Gerente de proyectos en su desarrollo y más tarde como Director del proyecto de software Operación System/360 durante su fase de diseño.
Por este trabajo, Bob Evans, y Erich Bloch fueron galardonados con la Medalla Nacional de Tecnología (National Medal of Technology) en 1985. Anteriormente, él era arquitecto de computadores IBM Stretch y Harvest.
En Chapel Hill, el Dr. Brooks fundó el Departamento de Ciencias de la Computación y lo presidió desde 1964 hasta 1984. Ha sido miembro de la National Science Board y Defense Science Board. Actualmente enseña e investiga en el área de arquitectura de computadores, gráficos moleculares y entornos virtuales.


Capítulo 1. El Pozo de Alquitrán

Een schip op het strand is een baken in zee.
(Un barco en la playa es como un faro en el mar)
DUTCH PROVERB
No hay una escena de la prehistoria tan vívida como la de las luchas mortales de grandes bestias en los pozos de alquitrán. Con la mente se pueden ver los dinosaurios, mamuts y tigres dientes de sable que luchan entre sí contra el alquitrán. Cuanto más feroz es la lucha, más se hunden en alquitrán y no hay bestia tan fuerte o tan experta por eso ya en la ultima instancia, se hunden.

La programación de grandes sistemas en la década pasada, ha sido como la historia del pozo de alquitrán ya que grandes y poderosas bestias cayeron violentamente dentro de él. La mayoría han emergido con sistemas funcionando, pocos han cumplido metas, horarios y presupuestos. Equipos tras equipos, ya sean grandes o medianos, masivos o de poca gente se ha hundido en el alquitrán. Nada parece causar alguna dificultad, cualquier molestia en particular puede ser superada. Pero la acumulación de factores simultáneos que interactúan entre sí hace lento y más lento movimiento. Todos parecen haber sido sorprendidos por lo contagioso del problema y es difícil discernir la naturaleza de este. Pero debemos intentar entenderlo si queremos a resolverlo.

Por lo tanto, permitámonos comenzar por identificar el arte de la programación de sistemas y luego las alegrías y penurias inherentes a este.

El Producto de Programación de Sistema

De vez en cuando, uno lee en el periódico crónicas de cómo dos programadores en un garaje remodelado han implementado un gran programa que sobrepasa con creces los esfuerzos de muchos grandes equipos. Y un programador está preparado para creer tales historias, ya que sabe que él puede construir cualquier programa mucho más rápido que las 1000 líneas de código al año que reportan los equipos de grandes empresas.

¿Por qué entonces no han sido reemplazados todos los miembros de los equipos grandes por esos "dúos de garaje"?, uno tiene que mirar "que" se está produciendo.

Fig. 1.1 Evolución del producto de Programación de Sistema

En la parte superior izquierda de la Figura 1.1 aparece un programa. Está terminado, listo para ser ejecutado por el autor en el sistema para el cual fue desarrollado. Eso es lo que se produce comúnmente en garajes y ése es el objeto que el programador individual utiliza en la estimación de la productividad.

Hay dos maneras en las que un programa puede convertirse en un objeto más útil, pero más costoso. Estas dos maneras están indicadas en los límites del diagrama.

Moviéndose abajo a través del límite horizontal, un programa se convierte en un Producto de Programación. Éste es un programa que se puede correr, está testeado, corregido y extendido. Es usable en muchos ambientes con muchos tipos de datos. Para convertirse en un producto de programación de uso general, el programa se debe escribir de una forma genérica. Particularmente tanto el rango como la forma de los inputs deben ser genéricos tanto como el algoritmo básico lo permita. A continuación, el programa debe ser probado exhaustivamente, así este puede ser dependiente. Esto significa que un conjunto sustancial de casos de prueba, con un gran rango de entradas y con casos de borde, debe ser preparado, ejecutado y registrado.
Finalmente, llevar un programa a un producto de programación requiere de una depurada documentación, de modo que cualquier persona pueda utilizarla, corregirla y extenderla. En general, estimo que un producto de programación cuesta por lo menos tres veces más que un simple programa que realice la misma función.

Moviéndose a través del límite vertical, un programa se convierte en un componente en un Sistema de Programación. Esto es una colección de programas que obran recíprocamente, coordinados en funcionamiento y disciplinados en formato, de modo que el ensamblaje constituya una ayuda de ítems unificados que sirvan para grandes tareas. Para convertirse en un componente de un sistema de programación, un programa debe ser escrito de modo que cada entrada y salida defina una sintaxis y semántica con interfaces definidas. El programa debe también ser diseñado de modo que utilice sólo un presupuesto estimado de recursos - espacio de memoria, dispositivos de entrada-salida, tiempo del computador. Finalmente el programa se debe testear con otros componentes del sistema, en todas las combinaciones previstas. Estas pruebas deben ser extensas para que el número de casos abarcados crezca de forma exponencial.

Se pierde tiempo con aquellos errores sutiles (bugs) que presentan interacciones inesperadas de componentes que han sido depuradas. Un componente de un Sistema de Programación cuesta al menos tres veces que un programa "Stand-alone" que realice las mismas funciones. El sistema es más costoso mientras mas componentes incluya.

En la esquina inferior derecha de la Fig. 1.1 se encuentra el Producto de Sistemas de Programación. Estos se diferencian de un programa simple en todo lo antes dicho. Tiene un costo nueve veces mayor, pero es el objeto verdaderamente útil, el producto previsto por la mayoría de los esfuerzos de programación de sistemas.

Las alegrías del arte

¿Por qué es la programación divertida? ¿Qué placeres puede su practicante recibir como recompensa?

Primero está la alegría de hacer cosas. Como aquel niño que se deleita con su torta de barro, el adulto disfruta construyendo cosas, especialmente cosas que el mismo diseña. Yo pienso que esta delicia debe ser como la imagen del placer de Dios haciendo las cosas, un placer visto en la distinción de cada hoja y cada copo de nieve.

Segundo, está el placer de hacer cosas que son útiles a otras personas. En nuestro interior queremos que otros utilicen nuestro trabajo y lo encuentren útil. A este respecto el sistema de programación no es esencialmente diferente del primer porta-lápiz de arcilla hecho por el niño "para la oficina del papá".

Tercero, es la fascinación de armar complejos rompecabezas, tal como interconectar partes móviles de objetos y viéndolas trabajar en sutiles ciclos, haciendo cosas que estaban afuera de los principios definidos en el inicio. El computador programado tiene toda la fascinación de una máquina de "pinball" o del mecanismo de una Rockola llevada al máximo.

El cuarto punto es la alegría de aprender, que deriva de la naturaleza no repetitiva de la tarea. De una u otra forma el problema es siempre nuevo y se aprende algo nuevo de su solución: algunas veces teórico, algunas veces algo práctico, y algunas veces ambos.

Finalmente, está el placer de trabajar en un medio tan manejable. El programador, como el poeta, trabaja ligeramente retirado de la naturaleza pura de las cosas. Él construye sus castillos en el aire, desde el aire, creando sólo con la imaginación. Pocos medios de creación son tan flexibles, fáciles de pulir y revisar, lo que permite la creación de grandes estructuras conceptuales (como veremos más tarde, esta flexibilidad tiene sus propios problemas).

Sin embargo la construcción del programa, a diferencia de las palabras de un poeta, es real en el sentido de que se mueve y trabaja, que produce resultados visibles fuera de la construcción del mismo. Este imprime resultados, dibuja figuras, produce sonidos o mueve brazos. Es como la magia del mito y la leyenda hechos realidad en nuestro tiempo. Uno escribe el hechizo correcto desde el teclado y en la pantalla cobra vida, mostrando cosas que nunca fueron ni podrían ser.

En resumen, la programación es divertida porque gratifica los anhelos construidos en el interior de nosotros y deleita las sensibilidades que nosotros tenemos en común con los demás.

Los penas del arte

No todo es placer, sin embargo, si se conocen las dificultades inherentes se hace más fácil manejarlas cuando aparecen.

Primero, hay que realizarlas perfectamente. La computadora se asemeja a una leyenda mágica en este aspecto. Si un carácter o una pausa del hechizo no está terminado en la forma apropiada, la magia no funciona. Los seres humanos no están acostumbrados a ser perfectos y pocas áreas de la actividad humana se lo exigen. Ajustar lo necesario para alcanzar esta perfección es, según mi opinión, la parte más difícil en el aprendizaje de la programación.

Luego, otras personas ajustan los objetivos, proveen recursos y proporcionan informaciones. Uno raramente controla las circunstancias de su trabajo o incluso de su objetivo. En términos de gestión, la autoridad de solo una persona no es suficiente para toda la responsabilidad que existe. También sucede que en muchos ámbitos, existen trabajos donde las cosas se terminan pero sin una autoridad formal que tenga responsabilidad. En la práctica, realmente (de manera no oficial o formal) la autoridad se hace presente desde el momento del levantamiento.

La dependencia sobre los demás tiene un caso particular que es especialmente doloroso para el programador de sistemas. Él depende de los programas de otras personas. Estos frecuentemente están mal diseñados, pobremente implementados, incompletos (sin código fuente ni casos de prueba) y pobremente documentados. Por lo que deben pasar horas estudiando y reparando cosas que en un mundo ideal deberían estar completas, disponibles y utilizables.

El siguiente dolor es que sabemos que el diseño de grandes conceptos fue divertido y encontrar pequeños errores es sólo una parte del trabajo. Pero con cualquier actividad creativa también atrás vienen monótonas horas de tedio, arduo trabajo y la programación no es excepción.

A continuación se observa que la depuración tiene una convergencia lineal, o a veces es peor ya que toma un crecimiento cuadrático en la parte final. Mientras las pruebas más se prolongan, el último error toma mucho más tiempo de encontrar que el primero.

Muchas veces se grita el último "ay", o se da el último "golpe", cuando se termina el producto sobre el cual se ha trabajado por mucho tiempo, pero este se hace obsoleto al momento de terminarlo (o antes). Esto es porque la competencia ya está en la búsqueda de nuevas y mejores ideas. A veces, el pensamiento del niño interno de la creación o del diseño del programa no se alcanza a poner en producción, pero al menos se alcanzó a planificar.

Esto siempre se ve peor de lo que realmente es. El nuevo y mejor producto generalmente no está disponible cuando uno completa el propio; sólo se ha hablado de el. Este nuevo producto también requiere de meses de desarrollo. El verdadero tigre nunca se asemeja al del papel de uno a menos que se requiera un real uso. Por lo tanto, las virtudes de la realidad tienen una satisfacción consigo misma.

Por supuesto, la base tecnológica sobre la que uno construye está "siempre" avanzando. Tan pronto como uno detiene un diseño, este ya se convierte en obsoleto en término de conceptos. Pero la implementación de productos reales requiere ajustes y cuantificación. La caída del uso de una implementación debe ser medida en función de otras implementaciones, no en contra de conceptos no realizados. El reto y la misión es encontrar soluciones reales para problemas reales, en el tiempo estimado, con los recursos disponibles.

Esta es entonces la programación, un pozo de alquitrán en el que muchos esfuerzos han fracasado y una actividad creativa con alegrías y penas propias. Para muchos, las alegrías son muy superiores a las penas y para ellos el resto de este libro intentará establecer algunas tablas que servirán como puente para cruzar los pozos de alquitrán.

Fin del capítulo 1.

Traducción revisada el 09-04-2013.