martes, 6 de junio de 2017

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.