Raumschiffe entwerfen
Ich habe die urspünglichen Akins Laws of Spacecraft Design mit etwas Hilfe von OpenAI ins Deutsche übersetzt – diese sind auch gut auf Softwareprojekte anwendbar.
Ingenieursarbeit basiert auf Zahlen. Eine Analyse ohne Zahlen ist lediglich eine Meinung.
Ein Raumfahrzeug richtig zu entwerfen erfordert unendlich viel Aufwand. Deshalb ist es eine gute Idee, sie so zu gestalten, dass sie funktionieren, auch wenn einige Dinge nicht stimmen.
Design ist ein iterativer Prozess. Die notwendige Anzahl an Iterationen ist immer eine mehr als die Anzahl, die du bisher durchgeführt hast. Dies gilt zu jedem Zeitpunkt.
Deine besten Designbemühungen werden letztendlich im endgültigen Design unbrauchbar sein. Lerne, dich mit der Enttäuschung abzufinden.
(Miller’s Law) Drei Punkte bestimmen eine Kurve.
(Mar’s Law) Alles ist linear, wenn es mit einem dicken Marker logarithmisch-logarithmisch geplottet wird.
Zu Beginn eines Designprojekts ist die Person, die am meisten Teamleiter sein möchte, am wenigsten dazu geeignet.
In der Natur liegt das Optimum fast immer irgendwo in der Mitte. Misstraue Behauptungen, dass das Optimum an einem Extrempunkt liegt.
Das Fehlen aller benötigten Informationen ist niemals eine zufriedenstellende Entschuldigung, um die Analyse nicht zu starten.
Im Zweifelsfall schätze. In einem Notfall raten. Aber stelle sicher, dass du den Schlamassel aufräumst, wenn die realen Zahlen vorliegen.
Manchmal ist der schnellste Weg zum Ziel, alles wegzuwerfen und von vorne anzufangen.
Es gibt nie eine einzige richtige Lösung. Es gibt immer mehrere falsche.
Design basiert auf Anforderungen. Es gibt keine Rechtfertigung dafür, etwas ein bisschen “besser” zu gestalten, als die Anforderungen es verlangen.
(Edison’s Law) “Besser” ist der Feind von “gut”.
(Shea’s Law) Die Fähigkeit, ein Design zu verbessern, tritt hauptsächlich an den Schnittstellen auf. Hier liegt auch der Hauptort, um es zu ruinieren.
Die vorherigen Personen, die eine ähnliche Analyse durchgeführt haben, hatten keinen direkten Zugang zur Weisheit der Zeitalter. Es gibt daher keinen Grund, ihre Analyse über deine zu stellen. Insbesondere gibt es keinen Grund, ihre Analyse als deine auszugeben.
Die Tatsache, dass eine Analyse gedruckt wird, hat keine Beziehung zur Wahrscheinlichkeit ihrer Richtigkeit.
Die Vergangenheit ist hervorragend geeignet, um eine Realitätsprüfung durchzuführen. Zu viel Realität kann jedoch ein sonst lohnendes Design verderben.
Die Chancen stehen stark gegen dich, dass du in deinem Fachgebiet enorm intelligenter bist als alle anderen. Wenn deine Analyse besagt, dass deine Termingeschwindigkeit doppelt so hoch ist wie die Lichtgeschwindigkeit, hast du vielleicht den Warp-Antrieb erfunden, aber die Chancen stehen viel besser, dass du etwas vermasselt hast.
Ein schlechtes Design mit einer guten Präsentation ist letztendlich dem Untergang geweiht. Ein gutes Design mit einer schlechten Präsentation ist sofort dem Untergang geweiht.
(Larrabee’s Law) Die Hälfte von allem, was du im Unterricht hörst, ist Unsinn. Bildung besteht darin, herauszufinden, welche Hälfte welche ist.
Im Zweifelsfall dokumentiere. (Die Dokumentationsanforderungen erreichen kurz nach dem Ende eines Programms ihr Maximum.)
Der Zeitplan, den du erstellst, wird bis zum Zeitpunkt, an dem dein Kunde dich feuert, weil du ihn nicht eingehalten hast, wie eine vollständige Fiktion erscheinen.
Es heißt “Work Breakdown Structure”, weil die verbleibende Arbeit wachsen wird, bis du einen Zusammenbruch hast, es sei denn, du legst eine Struktur darauf.
(Bowden’s Law) Nach einem Testfehler ist es immer möglich, die Analyse zu verfeinern, um zu zeigen, dass du tatsächlich die ganze Zeit negative Margen hattest.
(Montemerlo’s Law) Mach nichts Dummes.
(Varsi’s Law) Zeitpläne bewegen sich nur in eine Richtung.
(Ranger’s Law) Es gibt keine kostenlose Raketenstarts.
(von Tiesenhausen’s Law of Program Management) Um eine genaue Schätzung der endgültigen Programm Anforderungen zu erhalten, multipliziere die ursprünglichen Zeitabschätzungen mit Pi und verschiebe das Komma bei den Kostenschätzungen um eine Stelle nach rechts.
(von Tiesenhausen’s Law of Engineering Design) Wenn du einen maximalen Effekt auf das Design eines neuen Engineering-Systems haben möchtest, lerne zu zeichnen. Ingenieure gestalten immer das Fahrzeug so, dass es dem ursprünglichen Konzept des Künstlers ähnelt.
(Mo’s Law of Evolutionary Development) Du kommst nicht zum Mond, indem du sukzessive höhere Bäume erklimmst.
(Atkin’s Law of Demonstrations) Wenn die Hardware perfekt funktioniert, erscheinen die wirklich wichtigen Besucher nicht.
(Patton’s Law of Program Planning) Ein guter Plan, der jetzt gewaltsam umgesetzt wird, ist besser als ein perfekter Plan nächste Woche.
(Roosevelt’s Law of Task Planning) Tu, was du kannst, wo du bist, mit dem, was du hast.
(de Saint-Exupery’s Law of Design) Ein Designer weiß, dass Perfektion erreicht ist, wenn nichts mehr hinzugefügt werden muss, sondern wenn nichts mehr weggenommen werden kann.
Jeder gewöhnliche Ingenieur kann etwas entwerfen, das elegant ist. Ein guter Ingenieur entwirft Systeme, um effizient zu sein. Ein großartiger Ingenieur entwirft sie, um effektiv zu sein.
(Henshaw’s Law) Ein Schlüssel zum Erfolg in einer Mission ist das Festlegen klarer Schuldlinien.
Fähigkeiten bestimmen Anforderungen, unabhängig von dem, was die Lehrbücher für Systemtechnik sagen.
Jedes Erkundungsprogramm, das zufällig ein neues Startfahrzeug einschließt, ist de facto ein Startfahrzeugprogramm