Fred Brooks Citas famosas

Puedes aprender más del fracaso que del éxito. En caso de fracaso, te ves obligado a averiguar qué parte no funcionó. Pero en el éxito puedes creer que todo lo que hiciste fue genial, cuando en realidad algunas partes pueden no haber funcionado en absoluto. El fracaso te obliga a enfrentar la realidad.

Nueve personas no pueden tener un bebé en un mes.

¿Cómo llega un proyecto a retrasarse un año? Un día a la vez.

Muéstrame tus diagramas de flujo y oculta tus tablas, y continuaré desconcertado. Muéstrame tus tablas, y normalmente no necesitaré tus diagramas de flujo; serán obvios.

Es muy difícil hacer una defensa vigorosa, plausible y arriesgada de una estimación que no se deriva de ningún método cuantitativo, respaldada por pocos datos y certificada principalmente por las corazonadas de los gerentes.

Agregar mano de obra a un proyecto de software tardío lo hace más tardío

Un científico construye para aprender; un ingeniero aprende para construir.

La parte más difícil de crear un sistema de software es decidir con precisión qué construir la función más importante que los creadores de software hacen por sus clientes es la extracción iterativa y el refinamiento de los requisitos del producto. Porque la verdad es que los clientes no saben lo que quieren. Por lo general, no saben qué preguntas deben responderse y casi nunca han pensado en el problema con el detalle que debe especificarse.

La cuestión de gestión, por lo tanto, no es si construir un sistema piloto y tirarlo a la basura. Tú harás eso. Por lo tanto, planea tirar uno; de todos modos, lo harás.

Los científicos construyen para aprender; los ingenieros aprenden a construir.

Tener un hijo lleva nueve meses, sin importar cuántas mujeres se asignen.

No existe un desarrollo único, ni en tecnología ni en técnica de gestión, que por sí solo prometa una mejora de un orden de magnitud en una década en productividad, confiabilidad y simplicidad.

Identifique sistemáticamente a los mejores diseñadores lo antes posible. Los mejores a menudo no son los más experimentados.

Adaptarme al requisito de perfección es, creo, la parte más difícil de aprender a programar.

Un principio básico del procesamiento de datos enseña la locura de tratar de mantener archivos independientes en sincronía.

El programador, como el poeta, trabaja solo un poco alejado de las cosas puras del pensamiento. Él construye sus castillos en el aire, desde el aire, creando mediante el esfuerzo de la imaginación. Pocos medios de creación son tan flexibles, tan fáciles de pulir y reelaborar, tan fácilmente capaces de realizar grandes estructuras conceptuales.

El problema fundamental con el mantenimiento del programa es que corregir un defecto tiene una probabilidad sustancial (20-50 por ciento) de introducir otro. Entonces, todo el proceso es dos pasos hacia adelante y un paso hacia atrás..

El jefe primero debe distinguir entre información de acción e información de estado. Debe disciplinarse a sí mismo para no actuar sobre los problemas que sus gerentes pueden resolver, y nunca actuar sobre los problemas cuando está revisando explícitamente el estado.

Incluso la mejor planificación no es tan omnisciente como para hacerlo bien la primera vez.

La parte más difícil de la tarea del software es llegar a una especificación completa y consistente, y gran parte de la esencia de la creación de un programa es, de hecho, la depuración de la especificación.

Todos los programadores son optimistas. Quizás esta brujería moderna atraiga especialmente a aquellos que creen en finales felices y hadas madrinas. Quizás los cientos de frustraciones esenciales alejen a todos, excepto a aquellos que habitualmente se enfocan en el objetivo final. Quizás sea simplemente que las computadoras son jóvenes, los programadores son más jóvenes y los jóvenes siempre son optimistas.

La parte más difícil de construir un sistema de software es decidir con precisión qué construir.

Einstein argumentó que debe haber explicaciones simplificadas de la naturaleza, porque Dios no es caprichoso ni arbitrario. Ninguna fe así consuela al ingeniero de software.

Planea desechar una (implementación); de todos modos, lo harás.

El software exitoso siempre se cambia.

La integridad conceptual es la consideración más importante en el diseño de sistemas.

Una pequeña retrospección muestra que, aunque muchos sistemas de software buenos y útiles han sido diseñados por comités y construidos como parte de proyectos de varias partes, aquellos sistemas de software que han entusiasmado a los fanáticos apasionados son los productos de una o algunas mentes diseñadoras, grandes diseñadores.

Estudio tras estudio muestra que los mejores diseñadores producen estructuras que son más rápidas, más pequeñas, más simples, más claras y producidas con menos esfuerzo. Las diferencias entre lo grande y lo promedio se acercan a un orden de magnitud.

La complejidad del software es una propiedad esencial, no accidental. Por lo tanto, las descripciones de una entidad de software que abstraen su complejidad a menudo abstraen su esencia.

La esencia de una entidad de software es una construcción de conceptos entrelazados: [...] Creo que la parte difícil de crear software es la especificación, el diseño y la prueba de esta construcción conceptual, no el trabajo de representarla y probar la fidelidad de la representación .

Un antiguo adagio advierte: "Nunca vayas al mar con dos cronómetros; toma uno o tres.

El lenguaje de control de trabajos es el peor lenguaje de programación jamás diseñado por nadie para ningún propósito.

El arma principal del programador en la batalla interminable contra el sistema lento es cambiar la estructura intramodular. Nuestra primera respuesta debería ser reorganizar las estructuras de datos de los módulos.

El término arquitectura se usa aquí para describir los atributos de un sistema según lo visto por el programador, es decir, la estructura conceptual y el comportamiento funcional, a diferencia de la organización del flujo de datos y los controles, el diseño lógico y la implementación física. i. Detalles adicionales sobre la arquitectura

Más proyectos de software han salido mal por falta de tiempo en el calendario que por todas las demás causas combinadas.

La magia del mito y la leyenda se ha hecho realidad en nuestro tiempo. Uno escribe el encantamiento correcto en un teclado, y una pantalla cobra vida, mostrando cosas que nunca fueron ni pudieron ser.... La computadora también se asemeja a la magia de la leyenda en este sentido. Si un carácter, una pausa, del encantamiento no está estrictamente en la forma adecuada, la magia no funciona. Los seres humanos no están acostumbrados a ser perfectos, y pocas áreas de la actividad humana lo exigen. Adaptarme al requisito de perfección es, creo, la parte más difícil de aprender a programar.