Fred Brooks citations célèbres

Vous pouvez apprendre plus de l'échec que du succès. En cas d'échec, vous êtes obligé de découvrir quelle partie n'a pas fonctionné. Mais dans le succès, vous pouvez croire que tout ce que vous avez fait était génial, alors qu'en fait certaines parties n'ont peut-être pas fonctionné du tout. L'échec vous oblige à faire face à la réalité.

Neuf personnes ne peuvent pas faire un bébé en un mois.

Comment un projet arrive-t-il à avoir un an de retard sur le calendrier? Un jour à la fois.

Montrez-moi vos organigrammes et cachez vos tableaux, et je continuerai à être mystifié. Montrez-moi vos tableaux, et je n'aurai généralement pas besoin de vos organigrammes; ils seront évidents.

Il est très difficile de faire une défense vigoureuse, plausible et risquée pour l'emploi d'une estimation qui n'est dérivée d'aucune méthode quantitative, étayée par peu de données et certifiée principalement par les intuitions des gestionnaires

L'ajout de main-d'œuvre à un projet logiciel en retard le rend plus tardif

Un scientifique construit pour apprendre; un ingénieur apprend pour construire.

La partie la plus difficile de la construction d'un système logiciel consiste à décider précisément quoi construire la fonction la plus importante que les constructeurs de logiciels effectuent pour leurs clients est l'extraction itérative et le raffinement des exigences du produit. Car la vérité est que les clients ne savent pas ce qu'ils veulent. Ils ne savent généralement pas à quelles questions il faut répondre et ils n'ont presque jamais réfléchi au problème dans les détails qui doivent être spécifiés.

La question de gestion n'est donc pas de savoir s'il faut construire un système pilote et le jeter. Tu feras ça. Par conséquent, prévoyez d'en jeter un; vous le ferez de toute façon.

Les scientifiques construisent pour apprendre; les ingénieurs apprennent à construire.

Porter un enfant prend neuf mois, quel que soit le nombre de femmes assignées.

Il n'y a pas de développement unique, ni dans la technologie ni dans la technique de gestion, qui à lui seul promet même une amélioration d'un ordre de grandeur en une décennie en productivité, en fiabilité, en simplicité.

Identifiez systématiquement les meilleurs designers le plus tôt possible. Les meilleurs ne sont souvent pas les plus expérimentés.

S'adapter à l'exigence de perfection est, je pense, la partie la plus difficile de l'apprentissage de la programmation.

Un principe de base du traitement des données enseigne la folie d'essayer de maintenir des fichiers indépendants en synchronisme.

Le programmeur, comme le poète, ne travaille que légèrement éloigné de la pensée pure. Il construit ses châteaux dans les airs, à partir des airs, créant par l'effort de l'imagination. Peu de médias de création sont si flexibles, si faciles à polir et à retravailler, si facilement capables de réaliser de grandes structures conceptuelles.

Le problème fondamental de la maintenance du programme est que la correction d'un défaut a une probabilité substantielle (20 à 50%) d'en introduire un autre. Ainsi, l'ensemble du processus fait deux pas en avant et un pas en arrière..

Le patron doit d'abord faire la distinction entre les informations d'action et les informations d'état. Il doit se discipliner pour ne pas agir sur les problèmes que ses gestionnaires peuvent résoudre, et ne jamais agir sur les problèmes lorsqu'il examine explicitement le statut.

Même la meilleure planification n'est pas assez omnisciente pour bien faire les choses du premier coup.

La partie la plus difficile de la tâche logicielle est d'arriver à une spécification complète et cohérente, et une grande partie de l'essence de la construction d'un programme est en fait le débogage de la spécification.

Tous les programmeurs sont optimistes. Peut-être que cette sorcellerie moderne attire particulièrement ceux qui croient aux fins heureuses et aux marraines fées. Peut-être que les centaines de petites frustrations éloignent tout sauf ceux qui se concentrent habituellement sur l'objectif final. Peut-être est-ce simplement que les ordinateurs sont jeunes, les programmeurs sont plus jeunes et les jeunes sont toujours optimistes.

La partie la plus difficile de la construction d'un système logiciel consiste à décider précisément quoi construire.

Einstein a soutenu qu'il devait y avoir des explications simplifiées de la nature, car Dieu n'est ni capricieux ni arbitraire. Aucune foi de ce genre ne réconforte l'ingénieur logiciel.

Prévoyez d'en jeter une (implémentation); vous le ferez de toute façon.

Un logiciel performant est toujours modifié.

L'intégrité conceptuelle est la considération la plus importante dans la conception du système.

Un peu de rétrospective montre que bien que de nombreux systèmes logiciels fins et utiles aient été conçus par des comités et construits dans le cadre de projets en plusieurs parties, les systèmes logiciels qui ont excité les fans passionnés sont ceux qui sont les produits d'un ou de quelques esprits concepteurs, de grands designers.

Étude après étude, il ressort que les meilleurs concepteurs produisent des structures plus rapides, plus petites, plus simples, plus claires et produites avec moins d'effort. Les différences entre le grand et le moyen s'approchent d'un ordre de grandeur.

La complexité des logiciels est une propriété essentielle et non accidentelle. Par conséquent, les descriptions d'une entité logicielle qui font abstraction de sa complexité font souvent abstraction de son essence.

L'essence d'une entité logicielle est une construction de concepts imbriqués: [...] Je crois que la partie difficile de la création de logiciels est la spécification, la conception et le test de cette construction conceptuelle, et non le travail de la représenter et de tester la fidélité de la représentation.

Un ancien adage met en garde: "Ne partez jamais en mer avec deux chronomètres; prenez-en un ou trois.

Le langage de contrôle des tâches est le pire langage de programmation jamais conçu par quiconque pour n'importe quel but.

L'arme principale du programmeur dans la bataille sans fin contre le système lent est de changer la structure intramodulaire. Notre première réponse devrait être de réorganiser les structures de données des modules.

Le terme architecture est utilisé ici pour décrire les attributs d'un système vus par le programmeur, c'est-à-dire la structure conceptuelle et le comportement fonctionnel, par opposition à l'organisation du flux de données et des contrôles, la conception logique et l'implémentation physique. i. Détails supplémentaires concernant l'architecture

Plus de projets logiciels ont mal tourné par manque de temps de calendrier que pour toutes les autres causes combinées.

La magie du mythe et de la légende est devenue réalité à notre époque. On tape l'incantation correcte sur un clavier, et un écran d'affichage prend vie, montrant des choses qui n'ont jamais été et ne pourraient jamais être.... L'ordinateur ressemble à la magie de la légende à cet égard aussi. Si un caractère, une pause, de l'incantation n'est pas strictement en forme, la magie ne fonctionne pas. Les êtres humains ne sont pas habitués à être parfaits, et peu de domaines de l'activité humaine l'exigent. S'adapter à l'exigence de perfection est, je pense, la partie la plus difficile de l'apprentissage de la programmation.