Fred Brooks berühmte Zitate

Zuletzt aktualisiert : 5. September 2024

other language: spanish | czech | german | french | italian | slovak | turkish | ukrainian | dutch | russian | portuguese

Fred Brooks
  • Sie können mehr aus Misserfolgen lernen als aus Erfolgen. Im Misserfolg sind Sie gezwungen herauszufinden, welcher Teil nicht funktioniert hat. Aber im Erfolg können Sie glauben, dass alles, was Sie getan haben, großartig war, obwohl tatsächlich einige Teile überhaupt nicht funktioniert haben. Misserfolg zwingt dich, dich der Realität zu stellen.

  • Neun Menschen können in einem Monat kein Baby bekommen.

  • Wie kommt es, dass ein Projekt ein Jahr hinter dem Zeitplan liegt? Ein Tag nach dem anderen.

  • Zeigen Sie mir Ihre Flussdiagramme und verbergen Sie Ihre Tabellen, und ich werde weiterhin verwirrt sein. Zeigen Sie mir Ihre Tabellen, und ich brauche Ihre Flussdiagramme normalerweise nicht. sie werden offensichtlich sein.

  • Es ist sehr schwierig, eine energische, plausible und arbeitsplatzgefährdende Verteidigung einer Schätzung vorzunehmen, die ohne quantitative Methode abgeleitet, durch wenige Daten gestützt und hauptsächlich durch die Ahnungen der Manager bestätigt wird

  • Das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt macht es später

  • Ein Wissenschaftler baut, um zu lernen; ein Ingenieur lernt, um zu bauen.

  • Der schwierigste Teil beim Aufbau eines Softwaresystems besteht darin, genau zu entscheiden, was gebaut werden soll.Die wichtigste Funktion, die Softwarehersteller für ihre Kunden ausführen, ist die iterative Extraktion und Verfeinerung der Produktanforderungen. Denn die Wahrheit ist, die Kunden wissen nicht, was sie wollen. Sie wissen normalerweise nicht, welche Fragen beantwortet werden müssen, und sie haben fast nie an das Problem im Detail gedacht, das spezifiziert werden muss.

  • Die Managementfrage lautet daher nicht, ob ein Pilotsystem aufgebaut und weggeworfen werden soll. Das wirst du tun. Planen Sie daher, einen wegzuwerfen; du wirst sowieso.

  • Wissenschaftler bauen, um zu lernen; Ingenieure lernen zu bauen.

  • Die Geburt eines Kindes dauert neun Monate, egal wie viele Frauen zugewiesen sind.

  • Es gibt keine einzige Entwicklung, weder in der Technologie noch in der Managementtechnik, die allein eine Verbesserung der Produktivität, der Zuverlässigkeit und der Einfachheit um eine Größenordnung innerhalb eines Jahrzehnts verspricht.

  • Identifizieren Sie systematisch Top-Designer so früh wie möglich. Die Besten sind oft nicht die Erfahrensten.

  • Sich an die Forderung nach Perfektion anzupassen, ist meiner Meinung nach der schwierigste Teil beim Programmieren lernen.

  • Ein Grundprinzip der Datenverarbeitung lehrt die Torheit, unabhängige Dateien synchron zu halten.

  • Der Programmierer arbeitet wie der Dichter nur wenig entfernt vom reinen Gedankenkram. Er baut seine Luftschlösser aus der Luft und schafft sie durch Anstrengung der Fantasie. Nur wenige Gestaltungsmittel sind so flexibel, so leicht zu polieren und zu überarbeiten, so leicht in der Lage, große konzeptuelle Strukturen zu realisieren.

  • Das grundlegende Problem bei der Programmwartung besteht darin, dass die Behebung eines Fehlers eine erhebliche Chance (20-50 Prozent) hat, einen anderen einzuführen. Der gesamte Prozess ist also zwei Schritte vorwärts und einen Schritt zurück..

  • Der Chef muss zuerst zwischen Aktionsinformationen und Statusinformationen unterscheiden. Er muss sich disziplinieren, nicht auf Probleme zu reagieren, die seine Manager lösen können, und niemals auf Probleme zu reagieren, wenn er den Status explizit überprüft.

  • Selbst die beste Planung ist nicht so allwissend, dass sie es beim ersten Mal richtig macht.

  • Der schwierigste Teil der Softwareaufgabe besteht darin, zu einer vollständigen und konsistenten Spezifikation zu gelangen, und ein Großteil der Essenz beim Erstellen eines Programms besteht tatsächlich im Debuggen der Spezifikation.

  • Alle Programmierer sind Optimisten. Vielleicht zieht diese moderne Zauberei besonders diejenigen an, die an Happy Ends und gute Feen glauben. Vielleicht vertreiben die Hunderte von kleinen Frustrationen alle außer denen, die sich gewöhnlich auf das Endziel konzentrieren. Vielleicht liegt es nur daran, dass Computer jung sind, Programmierer jünger sind und die Jungen immer Optimisten sind.

  • Der schwierigste Teil beim Aufbau eines Softwaresystems besteht darin, genau zu entscheiden, was gebaut werden soll.

  • Einstein argumentierte, dass es vereinfachte Erklärungen der Natur geben muss, weil Gott nicht launisch oder willkürlich ist. Kein solcher Glaube tröstet den Softwareentwickler.

  • Planen Sie, eine (Implementierung) wegzuwerfen; du wirst sowieso.

  • Erfolgreiche Software wird immer geändert.

  • Konzeptionelle Integrität ist die wichtigste Überlegung beim Systemdesign.

  • Ein kleiner Rückblick zeigt, dass zwar viele schöne, nützliche Softwaresysteme von Komitees entworfen und im Rahmen von mehrteiligen Projekten gebaut wurden, aber die Softwaresysteme, die leidenschaftliche Fans begeistert haben, die Produkte eines oder weniger designender Köpfe, großartiger Designer, sind.

  • Eine Studie nach der anderen zeigt, dass die allerbesten Designer Strukturen herstellen, die schneller, kleiner, einfacher, klarer und mit weniger Aufwand hergestellt werden. Die Unterschiede zwischen dem Großen und dem Durchschnitt nähern sich einer Größenordnung an.

  • Die Komplexität von Software ist eine wesentliche Eigenschaft, keine zufällige. Daher abstrahieren Beschreibungen einer Softwareentität, die ihre Komplexität abstrahieren, oft ihre Essenz.

  • Das Wesen einer Softwareentität ist ein Konstrukt ineinandergreifender Konzepte: [...] Ich glaube, dass der schwierige Teil beim Erstellen von Software die Spezifikation, das Design und das Testen dieses konzeptuellen Konstrukts ist, nicht die Arbeit, es darzustellen und die Wiedergabetreue der Darstellung zu testen.

  • Ein altes Sprichwort warnt: "Fahren Sie niemals mit zwei Chronometern zur See; nimm eins oder drei.

  • Jobsteuerungssprache ist die schlechteste Programmiersprache, die jemals von irgendjemandem für irgendeinen Zweck entwickelt wurde.

  • Die Hauptwaffe des Programmierers im endlosen Kampf gegen langsame Systeme besteht darin, die intramodulare Struktur zu ändern. Unsere erste Reaktion sollte darin bestehen, die Datenstrukturen der Module neu zu organisieren.

  • Der Begriff Architektur wird hier verwendet, um die Attribute eines Systems aus Sicht des Programmierers zu beschreiben, dh die konzeptionelle Struktur und das funktionale Verhalten, im Unterschied zur Organisation des Datenflusses und der Steuerelemente, dem logischen Design und der physischen Implementierung. i. Zusätzliche Angaben zur Architektur

  • Es sind mehr Softwareprojekte aus Mangel an Kalenderzeit schiefgegangen als aus allen anderen Gründen zusammen.

  • Die Magie von Mythen und Legenden ist in unserer Zeit wahr geworden. Man tippt die richtige Beschwörung auf einer Tastatur ein, und ein Bildschirm erwacht zum Leben und zeigt Dinge, die niemals waren oder sein könnten.... Auch in dieser Hinsicht ähnelt der Computer der Magie der Legende. Wenn ein Zeichen, eine Pause, der Beschwörung nicht genau in der richtigen Form ist, funktioniert die Magie nicht. Der Mensch ist es nicht gewohnt, perfekt zu sein, und nur wenige Bereiche menschlicher Tätigkeit verlangen dies. Sich an die Forderung nach Perfektion anzupassen, ist meiner Meinung nach der schwierigste Teil beim Programmieren lernen.