¡Hola habitantes! Pocos libros sobre gestión de proyectos son tan importantes como The Mythical Man-Month. Una mezcla de ejemplos, opiniones y pensamientos reales de desarrollo de software crea una imagen vívida de la gestión de proyectos complejos. Estos ensayos se basan en los cincuenta años de experiencia de Brooks como director de proyectos en IBM System / 360 y luego en OS / 360. La primera edición del libro se publicó hace 45 años, la segunda hace 25 años. Están surgiendo nuevas metodologías, están surgiendo nuevos lenguajes de programación, el número de procesadores está creciendo, pero este libro sigue siendo relevante. ¿Por qué? Medio siglo después, seguimos repitiendo los errores que describió Brooks. Algunos de los temas tratados en el libro parecen obsoletos, pero esto es solo una apariencia. Los problemas fundamentales detrás de ellos siguen siendo relevantes hoy. Es importante conocer su pasado para comprenderdonde se desarrolla la industria del desarrollo de software. Por lo tanto, después de 45 años estamos leyendo Brooks. Mucho ha cambiado en el mundo, pero nueve mujeres aún no pueden tener un bebé en un mes.
. ,
. , , , …
, , , , .
, ', , , . .
La mayoría de las catedrales europeas se construyeron gradualmente y las partes construidas por constructores de diferentes generaciones difieren en términos de estilo arquitectónico. Los constructores posteriores se vieron tentados a "refinar" el diseño de los anteriores, centrándose en los cambios en la "moda" arquitectónica y el gusto personal. Por lo tanto, el pacífico transepto normando * linda y contradice la enorme nave gótica, y el resultado es tanto para alabar la gloria de Dios como para el orgullo de los constructores.
En su contexto, la unidad arquitectónica de Reims contrasta enormemente. El deleite que emociona al espectador proviene tanto de la integridad del diseño como de los méritos individuales. Como se indica en la guía, esta integridad se logró mediante la abnegación de ocho generaciones de constructores, cada uno de los cuales sacrificó algunas de sus ideas en aras de la pureza del diseño general. El resultado proclama no solo la gloria del Señor, sino también su poder para salvar a los pecadores de su orgullo.
Si bien la mayoría de los sistemas de programación no tardaron siglos en construirse, exhiben una desunión conceptual mucho peor que las catedrales. Esto generalmente ocurre no por un cambio de diseñadores, sino por la división del proyecto en numerosas tareas realizadas por muchas personas.
Insisto en que la integridad conceptual es la consideración más importante en el diseño de un sistema. Es mejor tener un sistema que carece de algunas características y mejoras, pero que refleja un conjunto de ideas de diseño, que tener un sistema que contiene muchas ideas buenas pero independientes e inconsistentes. En este capítulo y en los dos siguientes veremos las implicaciones de este tema para el diseño de sistemas de programación:
- ¿Cómo lograr la integridad conceptual?
- ¿No justifica este argumento el elitismo o la aristocracia de los arquitectos frente a una horda de implementadores plebeyos, cuyos talentos e ideas creativas son reprimidos?
- ¿Cómo evitar que los arquitectos se vayan a la deriva con especificaciones costosas o no implementadas?
- ¿Cómo asegurarse de que cada detalle menor de la especificación arquitectónica se llame la atención del implementador, se entienda correctamente y esté integrado con precisión en el producto?
Lograr la integridad conceptual
El propósito del sistema de programación es hacer que la computadora sea fácil de usar. Para hacer esto, proporciona lenguajes y varias herramientas de soporte, que en realidad son programas llamados e impulsados por capacidades de lenguaje. Pero estas herramientas tienen un precio: la descripción externa del sistema de programación es de 10 a 20 veces mayor que la descripción externa del propio sistema informático. Es mucho más fácil para el usuario configurar una sola función, pero su elección es amplia y hay muchas más opciones y formatos a tener en cuenta.
El uso solo se simplifica si el tiempo ganado en la especificación funcional es mayor que el tiempo perdido en asimilar, memorizar y buscar el manual de referencia. En los sistemas de programación modernos, esta ganancia excede el costo, pero en los últimos años, la relación entre la ganancia y el costo parece haber disminuido a medida que se agregan características cada vez más complejas. Me atormenta el recuerdo de la facilidad de uso de la IBM 650, incluso sin lenguaje ensamblador ni ningún otro software.
Dado que el objetivo es la facilidad de uso, esta relación entre la funcionalidad y la integridad conceptual es la prueba definitiva del diseño del sistema. La funcionalidad y la simplicidad por sí solas no definen un buen diseño.
Esta tesis está muy mal entendida. OS / 360 es aclamado por sus creadores como el sistema operativo más hermoso jamás diseñado porque es, sin duda, el más funcional. Es la funcionalidad, no la simplicidad, lo que siempre ha sido la medida de excelencia para sus diseñadores. Por otro lado, el sistema de tiempo compartido del PDP-10 es aclamado por sus creadores como el mejor debido a la simplicidad y moderación de los conceptos. Sin embargo, en cualquier medida, su funcionalidad ni siquiera pertenece a la misma clase que la de OS / 360. Una vez que se toma la facilidad de uso como criterio, cada uno de estos enfoques se desequilibra, solo a mitad de camino hacia la meta.
Sin embargo, para un nivel dado de funcionalidad, el mejor sistema es aquel en el que las cosas se pueden especificar con la mayor simplicidad y sencillez. La sencillez por sí sola no es suficiente. Los lenguajes TRAC Mooers y Algol 68 logran simplicidad, medida por el número de conceptos elementales distintos. La inmediatez, sin embargo, no es característica de ellos. Expresar sus intenciones a menudo requiere combinar herramientas básicas de formas complejas e inesperadas. No basta con estudiar los elementos y las reglas para su combinación; también es necesario estudiar el uso idiomático, para asimilar todo un cuerpo de conocimientos sobre cómo se combinan los elementos en la realidad. La sencillez y la sencillez provienen de la integridad conceptual. Cada pieza debe reflejar la misma filosofía y el mismo acto de equilibrio.Cada parte debe utilizar incluso la misma técnica en sintaxis y conceptos similares en semántica. Por lo tanto, la facilidad de uso dicta la unidad del diseño, la integridad conceptual.
Aristocracia y democracia
La integridad conceptual, a su vez, requiere que el proyecto provenga de un desarrollador o de un pequeño número de ellos, actuando en concierto y al unísono.
La presión del horario, a su vez, requiere la participación de más trabajadores. Hay dos métodos para resolver este problema. El primero es la cuidadosa división del trabajo entre arquitectura e implementación. El segundo es una nueva forma de estructurar las instrucciones de implementación de la programación, discutida en el capítulo anterior.
Separar el esfuerzo arquitectónico de la implementación es una forma poderosa de lograr la integridad conceptual en proyectos grandes. Yo mismo lo he visto utilizado con gran éxito en la línea de productos IBM Stretch y System / 360 de computadoras. Y fui testigo de cómo no funcionó en el desarrollo de Operating System / 360 porque no se usó lo suficiente.
Por arquitectura del sistema, me refiero a una especificación completa y detallada de la interfaz de usuario. Para una computadora, se incluye en el manual de referencia de programación. Para el compilador, en el manual de referencia del lenguaje. Para un programa de control, el manual de referencia del idioma o idiomas utilizados para llamar a sus funciones. Para todo el sistema, es una colección de guías de referencia para ayudar al usuario a lograr su objetivo.
El arquitecto del sistema, como el arquitecto del edificio, es el agente de usuario. Sus responsabilidades incluyen el uso de los conocimientos profesionales y técnicos en interés del consumidor, y no en el interés del vendedor, fabricante, etc. La
arquitectura debe distinguirse claramente de la implementación. Como señaló Blaauw, "donde la arquitectura habla de lo que sucede, la implementación habla de cómo se hace para que suceda". Como ejemplo sencillo, cita un reloj cuya arquitectura consta de esfera, agujas y corona. Cuando un niño haya dominado esta arquitectura, podrá decir la hora con la misma facilidad tanto con su reloj de pulsera como con el reloj de la torre de la iglesia. La implementación y su implementación describen lo que sucede internamente: la transferencia de esfuerzo y el control de precisión por cada uno de los muchos mecanismos.
Por ejemplo, en System / 360, una arquitectura de computadora separada se implementa de manera muy diferente en cada uno de los nueve modelos. A su vez, la implementación separada, el flujo de datos, la memoria y el microcódigo del sistema Modelo 30 en diferentes momentos sirven a cuatro arquitecturas diferentes: la computadora System / 360, el canal multiplexado con 224 subcanales lógicamente independientes, el canal selector y la computadora 1401.
La misma distinción se aplica igualmente a los sistemas de programación. Estados Unidos ha adoptado el estándar Fortran IV. Es la arquitectura de muchos compiladores. Dentro de esta arquitectura, son posibles diferentes implementaciones: texto en memoria o compilador, rápido u optimizador, sintáctico o ad hoc. Asimismo, cualquier lenguaje de ensamblaje o control de trabajos permite muchas implementaciones de ensamblado o planificador. Ahora podemos abordar el tema profundamente emocional de la aristocracia y la democracia. ¿No son los arquitectos la nueva aristocracia, la élite intelectual, creada para decirles a los implementadores pobres y estúpidos qué hacer? ¿No se ha apoderado esta élite de toda la actividad creativa, haciendo que los artistas solo sean engranajes del mecanismo? ¿No puedes conseguir un producto mejor?¿Implementando buenas ideas de todo el equipo, siguiendo una filosofía democrática, en lugar de limitar el desarrollo de especificaciones a unos pocos elegidos?
En cuanto a la última pregunta, es la más sencilla. No estoy sugiriendo que solo los arquitectos tengan buenas ideas arquitectónicas. A menudo, un nuevo concepto proviene del implementador o del usuario. Sin embargo, toda mi experiencia me convence, y traté de demostrarlo, que la integridad conceptual de un sistema determina su facilidad de uso. Es mejor dejar de lado las buenas características e ideas que no se integran con los conceptos subyacentes del sistema. Si hay muchas ideas tan importantes pero incompatibles, entonces todo el sistema se descarta como un todo y se comienza de nuevo a trabajar en un sistema integrado con otros conceptos básicos.
En cuanto a la acusación de aristocracia, la respuesta debe ser “sí” y “no”. Sí, en el sentido de que debería haber pocos arquitectos, su producto debería durar más que el producto del implementador, y el arquitecto está en el centro de las fuerzas que, en última instancia, debe dirigir en interés del usuario. Para que el sistema tenga integridad conceptual, una persona debe tomar la iniciativa. Esta es la aristocracia que no necesita disculpas.
Desarrollar especificaciones externas es un trabajo tan creativo como diseñar implementaciones. Es creatividad, solo de otro tipo. El diseño de implementación consciente de la arquitectura requiere y permite tanta creatividad de diseño, tantas nuevas ideas y tanta brillantez técnica como el diseño para especificaciones externas. De hecho, la relación costo-rendimiento de un producto dependerá en gran medida del implementador, al igual que la facilidad de uso depende principalmente del arquitecto.
Hay muchos ejemplos de artes y oficios que llevan a la creencia de que la disciplina mejora la artesanía. De hecho, el aforismo del artista dice: "la forma libera". Las peores estructuras son aquellas cuyo presupuesto era demasiado grande para el servicio. La actividad creativa de Bach apenas fue reprimida por la necesidad de publicar una cantata semanal de forma limitada. Estoy seguro de que la computadora Stretch tendría una mejor arquitectura si fuera más restrictiva; En mi opinión, las limitaciones presupuestarias del System / 360 Model 30 han sido beneficiosas para la arquitectura del Model 75 en todos los aspectos.
Del mismo modo, encuentro que la subcontratación de la arquitectura mejora, en lugar de anular, el estilo creativo del equipo de implementación. Inmediatamente se enfocan en la parte de la tarea que nadie resolvió, y los inventos comienzan a fluir como un río. En un grupo de implementación sin restricciones, la mayor parte del pensamiento y la discusión se centra en soluciones arquitectónicas, con plazos de implementación cortos.
Este efecto, que he visto muchas veces, lo confirma RW Conway, cuyo grupo en Cornell construyó un compilador PL / C para PL / 1. Señala lo siguiente: "Al final, decidimos implementar el lenguaje sin cambios ni mejoras, ya que la discusión del lenguaje tomaría toda nuestra energía".
¿Qué debe hacer el implementador mientras espera?
Es humillante cometer un error de un millón de dólares, pero es tan memorable. Recuerdo vívidamente la noche en que decidimos cómo organizar la redacción real de las especificaciones externas para OS / 360. El gerente de arquitectura y el gerente del programa de control y yo elaboramos el plan, cronograma y asignación de responsabilidades.
El director de arquitectura tenía 10 personas con talento. Argumentó que pueden escribir especificaciones y hacerlo bien. Esto llevará 10 meses, tres más de lo que permite el cronograma.
El gerente para la implementación del programa de control contó con 150 personas. Argumentó que podrían preparar especificaciones en coordinación con el equipo de arquitectura; estaría bien hecho y sería práctico, y encajaría en el programa. Además, si el equipo de arquitectura lo hiciera, sus 150 personas se quedarían sin hacer nada durante 10 meses.
A esto, el gerente de arquitectura respondió que si transfiero la responsabilidad al equipo del programa de control, de hecho, el resultado se recibirá 3 meses después y con una calidad mucho menor. Entregué la responsabilidad al equipo de implementación del programa de control y resultó como él dijo. Tenía razón en ambos casos. Además, la falta de integridad conceptual hizo que el sistema fuera mucho más caro de construir y cambiar, y estimo que retrasó la depuración en un año.
Por supuesto, muchos factores influyeron en esta decisión errónea; pero los abrumadores fueron las limitaciones de tiempo en el cronograma y un llamamiento para que todos estos 150 implementadores trabajaran. Es este canto de sirenas, cargado de peligros mortales, lo que ahora haré visible.
A la propuesta de que un pequeño equipo de arquitectura redacte todas las especificaciones externas de una computadora o sistema de programación, los implementadores plantean tres objeciones:
- Las especificaciones tendrán demasiadas funciones y no reflejarán el costo práctico.
- Los arquitectos tendrán todo el placer creativo y abandonarán el ingenio de los implementadores.
- Numerosos artistas tendrán que quedarse de brazos cruzados mientras las especificaciones pasan por el cuello de botella del equipo de arquitectura.
El primero es un peligro real y lo veremos en el próximo capítulo. Los otros dos son ilusiones, puras y simples. Como vimos anteriormente, la implementación también es una actividad creativa de primer orden. La capacidad de ser creativo e inventivo en el diseño está marginalmente limitada por la necesidad de trabajar dentro de especificaciones externas dadas, y esta disciplina puede incluso mejorar la creatividad. Esto es indudablemente cierto para el proyecto en su conjunto.
La última objeción se refiere al tiempo y las fases. La respuesta rápida es no contratar implementadores hasta que se completen las especificaciones. En construcción, operan según el mismo principio.
En el negocio de los sistemas informáticos, sin embargo, el ritmo es más rápido y todo el mundo quiere exprimir el horario tanto como sea posible. ¿Hasta qué punto se pueden superponer la especificación y el desarrollo?
Como señala Blaau, el esfuerzo creativo general incluye tres fases distintas: arquitectura, implementación e implementación. Resulta que de hecho pueden comenzar en paralelo y continuar al mismo tiempo.
Por ejemplo, en el diseño de computadoras, el implementador puede comenzar tan pronto como tenga suposiciones relativamente vagas sobre el manual de referencia, ideas más o menos claras sobre la tecnología y objetivos bien definidos de costo y desempeño. Puede diseñar flujos de datos, secuencias de control, conceptos de empaquetado aproximado, etc. Desarrolla o adapta las herramientas que necesita, especialmente un sistema de contabilidad, incluido un sistema de automatización de diseño.
Al mismo tiempo, a nivel de implementación, se deben redactar, mejorar y documentar los diseños de circuitos, tarjetas, cables, marcos, fuentes de alimentación y memoria. Este trabajo va en paralelo con la arquitectura y la implementación.
Lo mismo ocurre con el diseño de sistemas de programación. Mucho antes de que se finalicen las especificaciones externas, el implementador tiene mucho que hacer. Con algunas simplificaciones excesivas de la funcionalidad del sistema, que eventualmente se incorporará en especificaciones externas, puede continuar trabajando. Debería tener criterios de focalización espacial y temporal claramente definidos. Debe conocer la configuración del sistema en el que se ejecutará su producto. Luego, puede comenzar a diseñar límites de módulos, estructuras de tablas, desgloses de paso y fase, algoritmos y todo tipo de herramientas. También debería dedicar algún tiempo a comunicarse con el arquitecto.
Todavía queda mucho trabajo por hacer a nivel de implementación. La programación también tiene tecnología. Si la máquina es nueva, queda mucho por hacer con respecto a las convenciones de llamadas a subrutinas, la tecnología del supervisor, los algoritmos de búsqueda y clasificación.
La integridad conceptual requiere que el sistema refleje una única filosofía y que varias personas escriban una especificación visible para el usuario. Sin embargo, debido a la división real del trabajo en arquitectura, implementación e implementación, de esto no se sigue en absoluto que el montaje de un sistema planeado de esta manera lleve más tiempo. La experiencia muestra lo contrario: que todo el sistema converge cada vez más rápido y lleva menos tiempo probarlo. De hecho, la división horizontal generalizada del trabajo se ha visto drásticamente restringida por la división vertical del trabajo, y el resultado ha sido una simplificación radical de la comunicación y una mayor integridad conceptual.
»Se pueden encontrar más detalles sobre el libro en el sitio web de la editorial
» Tabla de contenido
» Extracto
para los habitantes un 25% de descuento en el cupón - Brooks
Tras el pago de la versión impresa del libro, se envía un libro electrónico al correo electrónico.